Automation has been a reality since the Jacquard loom of the early nineteenth century. And just as its punch card technology inspired Charles Babbage and later Herman Hollerith, automation has itself evolved over the years as technology innovations hit the market.

We could even argue that the point of the first digital computers was to perform automations – albeit mostly of calculation tasks. Be that as it may, even in the early days, there was a distinct difference between the calculation, which the computers performed automatically, and the automation, which humans programmed manually.

For those of us gray hairs who remember manually operating a punch card machine, it’s not difficult to imagine wanting a way to automate that mind-numbing and error-prone process. If only we could automate the process of automation itself, we’d reach a new level of computing power and versatility.

What about RPA?

Techies, of course, have been automating automation tasks since at least the early days of UNIX, as the point to writing shell scripts was to automate interactions with programs that themselves automated various tasks. Shell programming is still a powerful tool, but it requires more or less the same hardcore technical skills it did in the 1970s.

Today, however, one trend has emerged that promises to bring the automation of automated tasks to the average organization: robotic process automation (RPA).

Just one problem: RPA isn’t particularly good at automating the task of automation – largely because the vendors of such products didn’t work through the use cases for such capability.

However, if we step back and consider the situations where we’d like to perform such ‘meta-automations,’ it soon becomes clear that something is missing.

Macros on Steroids

In addition to the techies’ shell scripts, business users have had the ability to code their own automations for decades using macros. I remember scripting computer and app behavior on a Macintosh back in the 1980s, and programs like Microsoft Excel have had macros for about as long.

If you look at how macros work, you’ll see a basic “do this then do that” structure. Sure, you might have if-then options or loops of various kinds, but at that point, you’re really writing a computer program – something that the average business user isn’t particularly interested in bothering with.

Macros, in fact, are similar to RPA, with the end-user playing the role of the robot. At its core, RPA observes and mimics users’ behavior as they navigate through some user interface and ends up with a macro-type automation much the same as what I came up with on my Macintosh all those years ago.

RPA, however, goes well beyond creating simple macros that mimic human behavior. In reality, today’s enterprise RPA platforms require extensive programming to build out the behavior of the robots – leading to code that is brittle and difficult to maintain.

In other words, RPA platforms aren’t particularly good at automating the automation tasks. Rather, these products leave the creation of those ‘meta-automations’ to human coders in an attempt to create workable automations of human tasks.

Uncovering Other Examples of the ‘Meta-Automation’ Pattern

If you want to discover the bleeding edge of meta-automation — what I’m calling the automation of automation tasks — look no further than the tools techies build for themselves.

Case in point: what’s happening now in the DevOps world. There are two sides to DevOps: the cultural and organizational shift that breaks down silos and fosters greater collaboration on one hand and a collection of tools that automate software life cycle tasks on the other.

Such tooling has been on the market for several years now, and if anything, we have far too many DevOps tools available to us. Responding to this profusion, some vendors sought to roll out the Tolkienesque ‘one tool to rule them all,’ seeking to integrate or replace many other tools.

The response from the DevOps community, true to the Lord of the Rings metaphor, is to throw those overbearing tools directly into the volcano.

Instead, DevOps professionals prefer tools that help them automate the DevOps processes that consist in large part of the actions of individual tools. In other words, automating the automations is the best path toward the goals of DevOps tooling.

A similar pattern is occurring in the operations world, especially in organizations adopting cloud-native computing and, in particular, tools for observability (see my recent SiliconANGLE article on observability).

For these professionals, there are a plethora of monitoring, analytics, and management tools they must work with every day to do their jobs, which boil down to resolving any number of different kinds of problems in the production environment.

However, looking at these tools’ dashboards isn’t enough. Finding one tool that integrates all the other tools is a step in the right direction but also falls short. Instead, operators are looking for tools that help them automate the interactions with each of the other tools’ automation capabilities.

Here’s how they think about solving the problems they face: If they need to do something only once, they do it manually. If they need to do it more than once, they create a script to handle the task, but they write the script manually.

But in the cloud-native context, where everything is both extraordinarily dynamic and runs at scale, they don’t have time to write all those scripts. Instead, they want to work with tools that automatically create the scripts – in other words, the automations – that in turn execute on the tasks at hand.

The Intellyx Take

If the point to automation were to replace human activities with computer-driven ones, thus taking humans out of the loop, then automating those automations would certainly lead to ‘zero touch’ or ‘lights out’ situations (‘lights out’ referring to a room with no people and thus no need to turn the lights on).

However, it’s important to note that the opposite is happening. In both the DevOps and cloud-native operations examples, automating the automations empowers professionals to be more effective with their efforts rather than reducing the need for such people.

This empowerment benefit of automation, in fact, is one of the main reasons why DevOps makes sense. How can we expect automation to drive a cultural shift toward greater collaboration? Not by eliminating people but by empowering them.

What, then, do we do with RPA? Nobody wants an RPA project to amount to an expensive consulting engagement that leads to a brittle solution (except, perhaps, the consultants).

Instead, RPA vendors must rise to the challenge of automating the automations. They must replace the work of those throngs of consultants with automation capabilities that give their customers the ability to build and run sophisticated robots worthy of the name.

It’s unclear, however, how much progress these vendors have made on this front. AI may certainly help at some point in the future, but the RPA vendors aren’t using AI to automate the automations at this point.

Instead, they should go back to the drawing board and follow the examples of DevOps and cloud-native operations. Whichever RPA vendor solves this problem first could be extraordinarily successful.