Automation

(Part of my collection of Universal Principles of Software System Design)

Automation is a principle that applies to the operational side of software construction.

The principle of automation states that every repetitive process in the process of designing and constructing software systems itself should be automated. The principle applicaties to all functional areas, from infrastructure provisioning, application construction and deployment, through to the coding itself where possible (think about low-code solutions, and machine learning applications).

Automation of processes in needed to make software construction faster and more predictable, improve the quality, reduce dependency on people and address regulatory requirements.

Abstraction

(Part of my collection of Universal Principles of Software System Design)

The principle of abstraction in software systems allows us to create more generally usable software components. We do this by replacing specific attributes or functions with more general counterparts. The abstract components can be made specific through parameters or made more specific through inheritance.

Also, abstraction removes some detail from the problem space and thus makes it easier to think about problems and solutions.

Abstraction is also a software design technique. Abstraction in software design aggregates specific functions and attributes into general classes. Through this grouping, a complex software solution in methodically chopped up into smaller pieces that can be handled and reused better in all phases of a software system lifecycle.

Generalization is a term for the same.

Examples of abstraction in software systems:

  • The well known OSI model abstracts communication protocols in functional layers.
  • Messaging middleware solutions abstract the connectivity logic from the application.
  • Payment interfaces abstract the payment logic from commerce applications

Software Efficiency, or how long is a nanosecond

I heard Marc Andreessen predict that programmers need to get very efficient on programming again (at about 17:30 minutes) in this generally very interesting interview with Kevin Kelly.

If we do not get more efficient in programming, things might get stuck.

Another interesting perspective on the same issue was already shown in the 60s, by Grace Hopper, the lady that invested COBOL, amongst other things.See this video: How long is a nanosecond.

This all reminds me of a small test we did recently to check resource consumption of programming languages, by writing just a very small Hello World program. One program is written in COBOL, one in Java and one in Groovy. The following summarizes the huge difference in efficieny and shows how many CPU seconds these programs needed to run:

  • COBOL 0,01 msec (basically it was unmeasurable)
  • Java 1 second.
  • Groovy: 3 seconds.

And then we are only looking at very inefficient programming languages. Even more could be gained when looking at application architectures. Microservices architectures, especially when applied radically, are way more inefficient than traditional tightly coupled applications in C, COBOL or even Java.Of course I do not want to advertise stovepipe applications, history has proven the maintenance issues to be insurmountable, but we should aim at a more balanced architecture with more eye for efficiency.

A mini case for IT Architecture

Organizations heavily depend on software. Millions, billions of lines of code are produced every year.

This only accelerates in the future. This may even be a self-accelerating process. (I tried to find an estimate for the number of lines of code produced every year, but could not find firm figures. Nevertheless who would doubt the number software based solutions is growing.)

Architecture provide a sense of how all the software pieces fit together.For organisations this means (enterprise, business, IT)  architecture define and assure the organization’s ability the serve customer needs.

Architecture is the organizing mechanism. 

You can survive for sometime without an explicit architecture, but at some point you will hit a wall. Inefficiencies in business processes and the supporting software systems will bring an organization to a halt. Problems with functional alignment, business process and application integration, application support, scalability, changeability and what have you (yes I am being lazy now) will need to be addressed to get back on track. 

It is better to get things organized.

Reseize control over your mainframe (invest or retire, and get it done)

In many mainframe shops – organizations using applications that run on the mainframe – senior management struggle with their isolated, expensive, complicated mainframe environment.

  • The mainframe investment is a significant part of your IT budget, needing to board-level decision making
  • It is unclear if the value of your mainframe investment is in line with its value
  • Mainframe applications are often core applications, deeply rooted in organisational processes
  • Business innovation capacity is limited by legacy applications and technology
  • Too much is spent on maintenance and continuity, too little on innovation

At the same time, the disalignment increases.

  • The organisation moves to a cloud model for their IT – what is the mainframe position in that respect?
  • The mismatch between Enterprise Architecture and mainframe landscape is increasing
  • Organisational and technical debt is building up in the mainframe environment, maintenance and modernization is postponed and staff is ageing

A decision must decide whether to throw out the mainframe legacy or revitalize the environment, but they have far from complete information to make a good judgement.

The divestment options

Let’s look at the divestment options you have when your are stuck in this situation.

Rehost the platform, meaning, move the infrastructure to another platform or to a vendor. This solves a small part of the problem, namely the infrastructure management part. Everything else remains the same. So this is of little help to your problem. 

Retire all applications on the mainframe platform. Probably the cleanest solution in the divestment strategy. However this option is only viable if replacing applications are available and speedy migration to these applications is possible.

Replace through repurchase, meaning replace your custom solution with another off the shelf solution, whether on-premise or in a SaaS model. This is only an option if from a business perspective you can live with the standard functionality of the package solution. 

Replace through refactoring is an option for application where special functionality support distinguishing business features that can not be supported in off-the-shelf applications. Significant development and migration efforts may be needed for this approach.

A total solution will likely be a combination of these options, depending on application characteristics and business needs.

The investment option

The Investment option is an stepwise improvement process, in multiple areas, depending on the state of the mainframe applications and platform. Areas include application portfolio readjustments, architecture alignments, application and infrastructure technology updates, and processes and tools modernization.

Depending on the state of the environment, investments may be significant. Some organization have neglected their mainframe environment for a decade or longer, and have a massive backlog to address. In some cases the backlog is so big, that divestment is the only realistic option. (As an example, one organization needed to support multiple languages, including Chinese and Russian, in their business applications. After 10 years of maintenance neglect of the middleware, the only option they had was to abandon their strategic application platform. This clear brings excessive costs, but more important for the organisation competitiveness, technical debt hits at the most inconvenient moments.)

A program to reseize control over your mainframe platform

To find the best option for your organisation you should consider at least the following aspects:

  • Cost of value
  • Alignment of business goals, enterprise architecture and mainframe landscape
  • Position of the mainframe landscape in your application portfolio
  • Mainframe application portfolio lifecycle status and functional and strategic fit
  • Technical vitality of your mainframe environment
  • Operational effectiveness of DevOps and infra teams
  • Cloud strategy and mainframe alignment

A thorough analysis of these aspects funnels into a comprehensive improvement plan for business alignment, architectural adjustments and operational fit. Execution of this plan must be not just agreed, but actively controlled by senior business and IT management. A steering body is needed to address challenges quickly. Senior business and IT management and controlling business and enterprise architects should be represented in the steering body to make sure agreed goals remain on target.

Thus, you reseize control over your mainframe.

Close Menu