Everyone loves automation, and it can be easy to assume that the more you automate, the better. Indeed, falling short of achieving fully autonomous processes can feel like a defeat. If you don’t automate completely, you’re the one falling behind, right?
Well, not exactly. Although automation is, in general, a good thing, there is such a thing as too much automation. And blindly striving to automate everything under the sun is not necessarily the best strategy.
Instead, you should be strategic about what you do and don’t automate. Even if you have the tools and resources to automate certain parts of a process, you may not actually want to automate them.
The Benefits of Automation
To understand the argument for being selective about the processes you automate, let’s go over the key benefits that teams are usually trying to achieve when they automate something. Typically, those benefits include:
- Faster results.
- Less time spent by engineers on manual processes.
- Greater consistency and a lower rate of errors.
- Repeatability.
We could go on, but these bullet points summarize the main goals of most automation projects.
When to Automate and When Not to Automate
Now, if you think critically about how best to pursue the goals we’ve just described, you’ll realize that fully autonomous processes aren’t always the best ways to achieve the goals. Let’s go through each one carefully.
Faster Results
Automation can speed up processes by allowing operations to proceed without waiting on humans to sign off.
The caveat, however, is that if your automation tools run into a situation where they can’t make a decision about how to achieve something – which happens when a variable is introduced that your automation workflow didn’t anticipate – you can end up with more of a delay than you would face if you had a human in the loop to oversee things. You’ll probably get results much more slowly from a fully autonomous process that goes awry than you will from a process where you have a human in the loop to react to unexpected conditions.
Less Engineer Time
By a similar token, the total time that engineers have to invest in operations work may be lower if not all of your processes are completely automated.
The reason why is that if something goes wrong within a fully autonomous process, the response is likely to be highly distracting and time-consuming for your team. But, if you had a human in the loop to begin with, you’d face a lower risk of a disruption that would require an extensive manual response.
Greater Consistency
Automation is a good way to keep processes consistent — so long as those processes are 100 percent predictable and reliable.
But, when there are variables, or when you are dealing with a process where each use case is unique, automation won’t always breed consistency — at least, not the kind of consistency you want. It would be better to keep a human in the loop so that the human could react as needed to special circumstances.
Repeatability
It may be easier to reuse automation tooling, too, when you keep humans plugged into your automated processes.
The reason why is that — once again — each process may be unique, and so you can’t simply lift and shift the automations you’ve created for one process and apply them to a different one. But, if you leave some responsibility to humans, it becomes easier to keep your workflow adaptable enough so that you can use the same automations repeatedly, leaving it to the human to interpret the unique variables within each process and adapt the automations as required.
Using Partial Automation
To illustrate the points above, let’s consider a common process that might seem like a candidate for total automation, but actually is not.
The process is Just In Time (JIT) permissions granting. The goal of JIT permissions is to grant access rights when a user needs them, and revoke them when they are no longer necessary. Having humans configure these permissions each time in a totally manual way is not scalable, so you may think that you would want to automate the process as fully as possible.
But, in reality, it would make more sense to automate only part of your JIT permissions operations. You could automatically collect account and user information, for example, and use these to generate updated access control policies automatically.
But if you actually apply the policies automatically, you run the risk of something unexpected happening with highly negative security consequences. Maybe a user is requesting a JIT permissions update to access a system that was recently moved from testing to production, and that therefore has stricter access requirements. But your automation tooling isn’t aware of that change, so it will grant the permissions without considering the unique circumstances of the request in question.
If you require a human to sign off on the permissions change, however, there is a higher chance that the oversight will be caught. Manual sign-off could delay the process slightly, but the delay should not be significant if the rest of the process is well-automated.
Conclusion: The Limits of Automation
To be clear, we’re not saying automation is a bad thing, by any means.
What we are saying is that there are points within processes where full automation doesn’t always make sense. Although it may seem counterintuitive, there’s value in requiring human participation, even if making processes fully autonomous is a possibility.
