Automation: From Repetition to Engineering

I often realize I’m doing repetitive tasks that could easily be automated. Money transfers, reminders, invoices-these are simple, low-effort activities that don’t deserve to consume my time. Every time this happens, I tell myself, “I should automate this to save time and mental effort.” And yet, somehow, I don’t. I tell myself I have no time to automate.

In IT, especially when automating mainframe processes, we encounter the same hesitation:

“We don’t need to automate this; once it’s done, we’ll never do it again.”

Which almost never turns out to be true.

Repetitive tasks-whether personal or IT-related-are often simple to automate but remain manual due to perceived time constraints.

In IT, automation is critical. It reduces manual errors, improves consistency, and frees up time for more strategic work.

A Shift in Mindset

Automation requires a different engineering mindset. Instead of the familiar cycle:

Do → Fix → Fix → Fix

We move to:

Engineer process → Run process / Fix process → Run process → Run process

Once engineered, automated processes run with minimal intervention, saving both time and effort.

When to Automate

If you find yourself performing a task more than twice, consider automating it. Whether through shell scripting, JCL, utilities, or tools like Ansible, automation quickly pays off.

Automation is not optional-it’s essential for efficient IT operations and professional growth. Start automating today to work smarter, not harder.

Don’t waste time doing things more than twice. If you do something for the third time, automate it-you’ll likely have to do it a fourth or fifth time as well.

Automate everything.

The 4 Eyes Principle

  • Post category:Principles

Another principle today.

In the realm of software development, the four-eyes principle dictates that an action can only be executed when it is approved by two individuals, each providing a unique perspective and oversight. This principle is designed to safeguard against errors and misuse, ensuring the integrity and quality of the software.

The four eyes principle can help during the construction of software systems by finding weaknesses in architecture, design or code and can help to improve the quality. In every phase of the software development cycle, this principle can be applied, from the requirements analysis phase to the detailed coding phase.

Software architecture, design, and code could be co-developed by two people or peer-reviewed.

In the design of software systems, the four-eye principle applies to the process of validating design decisions on various levels. Pair programming is a software development technique in which two programmers work together on code, one usually doing the coding and the other doing the validation. In other engineering industries, dual or duplicate inspection is a common practice.

In regulated environments such as Financial Institutions, compliance requirements may dictate that code is always peer-reviewed to prevent backdoors in code.

In software systems itself, the four-eyes principles may be implemented when supporting business processes requiring this for security or quality validation reasons.

Change management, a critical aspect of software development, often relies on the four-eyes principle. When code changes are transitioned into production, a formal change board may mandate a signed-off peer review, ensuring that all changes meet the required standards. Change and Configuration Management tools for software systems are often designed to support this four-eyes principle process, further enhancing the quality and security of the production environment.

Further assurance can be added by adding a (random) rotation scheme of authorized individuals to serve as the second pair of eyes. This may provide additional assurance as it will not be known beforehand which two individuals will be dealing with a given decision.

Related / similar: Dual Inspection, Code Review.

Noise reduction

  • Post category:Principles

The principle of noise reduction in software systems improves software systems by removing inessential parts and options and/or making them invisible or only visible to selected users.

Reducing the options in a software solution increases usability. This goes for user interfaces as well as technical interfaces. We decide what an interface looks like and stick to it. All-too-famous examples of noise reduction are the Apple iPod and the Google search page.

Adding features for selected users means adding features and under-the-hood complexities for all clients.

Reducing options also makes the software more robust. If we build fewer interfaces, we can improve them. We can focus on really doing well with the limited set of interfaces.

In practice, we see hardware and software tools have many options and features. That is not because software suppliers desperately want to give their customers all the options but because we, their customers, are requesting these options. Software suppliers may view all these requests more critically. Some do.

Let’s aim to settle for less. We shouldn’t build more every time we can do with less just because we can. Also, we shouldn’t ask our suppliers to create features that are nice to have.

There are always more options, but let’s limit the options to 4 or better: 1.

Hypes

  • Post category:Principles

Some companies have made a business model out of technology hypes. These are the same companies that tell the market what it needs by asking the market. Of course, this comes with an invoice mentioning generous compensation. These companies write classy reports with colorful graphics in which they advise organizations to do what the organizations tell them to do.

But hypes are for techies. Techies may feast on technology, but for organizations, jumping on hypes can be a risky and costly pastime.

There are two types of hypes. Hypes can be about something new. Other hypes are just reformulations of existing things, recycled ideas.

But hypes are hypes: they will go away. The vast majority of hypes disappear into thin air. The techie may have learned from them. Some remain. It might be valuable if a technology is still around after a few years. But usually, the stuff will not be as groundbreaking and revolutionary as predicted when announced by the hype cycle company, that is, by the market itself.

Blockchain, anyone?

Some hypes are recycled ideas. We have no memory, and we don’t read textbooks. SOA, AI, microservices, and technical advancements are wrapped in shiny new names and gift papers, so they appear to be a gift from your software supplier or consultancy company.

Think Globally, Act Locally applied to IT

  • Post category:Principles

Solution architects should consider the enterprise impact of architectural decisions.

Solution architects must ignore enterprise directions if these lead to local inefficiencies or have other predominantly negative local effects.

There is a significant difference between the clean 30000-foot view (sometimes referred to as the air castle) and the muddy reality on sea level.

Gear Acquisition Syndrome

Photographers tend to suffer from Gear Acquisition Syndrome. They believe they will make better pictures with new gear and buy new lenses, cameras, and flashlights.

Then they find their work does not improve.

In IT, we do the same.

We have our old relational database management system.

But now we have this great Spark, MongoDB, CouchDB, or what have you. (I’m just taking a not-so-random example.) So now everything must be converted to Spark or Mongo.

We even forget that this old technology, the relational DBMS in this example, was so good at reliably processing transactions. It worked!

The new database is massively scalable, which is great. Unfortunately, it does not improve the reliability of processing our transactions.

But it’s hot, so we want it—because Google has it. Errr, but will you also use it to process web page indexes? Ah, no. You want to store your customer records in it. So, is it reliable? No. But it is satisfying our GAS.

Abstraction

  • Post category:Principles

The abstraction principle in software systems allows us to create more generically usable software components.

Abstraction removes details from the problem space and thus makes it easier to think about problems and solutions. This principle lets us focus on problems by reducing complexity.

Abstraction makes software components more reusable: code for specific problems is abstracted to code that applies to a broader class of problems.

The process of abstraction, or generalization, removes specific attributes or functions and replaces these with general counterparts. The abstract components can be made specific through parameters or inheritance.

Abstraction is also a modeling technique that allows logical grouping of software structures so they can be better designed, realized, and maintained. Through this grouping, a complex software solution is methodically chopped up into smaller pieces that can be handled better in all phases of a software system lifecycle.

Examples of abstraction in software systems:

The OSI networking model abstracts communication protocols in functional layers.

Messaging middleware solutions abstract the connectivity logic from the application.

Picasso’s bull

The 80/20 principle

  • Post category:Principles

The 80/20 principle also known as the Pareto principle applies to many areas.

The most common application of the principle is in the assessment of a project effort: 20% of the effort produces 80% of the job to be do done. Or the other way around, the last 20% of the work to be done will take 80% of the effort.

In IT, the principle applies also similarly to requirements versus functionality: 20% of the requirements determine 80 procent of the architecture. 20% of the requirements are the important ones for the core construction of a solution.

The principe thus tells you to focus on the 20% important requirements that determine the architecture. It helps you shrink the options you need to consider and prioritize and focus on the important parts of the solution.

The question is of course: which of the requirements are the important ones. The experience of the architect helps here. But in general you will realize while analysing requirements, if a requirement will need a significant change or addition to the solution.

A good book about the 80/20 principle is the book with the same name: The 80/20 Principle, by Richard Koch.

An example from an practitioner architecting an airline reservation system.

“The first time I (unconsciously) applied the 80/20 rule was in my early days as an architect. I was working with a team of architects on application infrastructure for completely new web applications. A wide variety of applications were planned to run on this infrastructure. However, it was not clear yet what the characteristics, the volumes, response time needs, concurrent users et cetera were for these applications, and that made it uncertain what we needed to cater for in this generic hosting solution.

So we decided to walk through the known use cases for the different applications.

We worked our way through four of the tens of applications. During the fourth we somehow could not come up with additional requirements for the application infrastructure. We realized that the rest of the set of applications would ‘only’ be a variety of one of the apps wealready looked at. So we had our 80% from looking at just 20%.”