When you see the word “automation,” it makes you think of doing things automatically. But when it comes to technology it’s a misnomer in that you won’t make things happen automatically, at least not the way a human would do it. Automation in technology entails finding a more efficient and convenient way to do things without the use of a person. So, yes, things happen “automatically” and without a human needing to do anything, but getting from point A to point B will be done in vastly different and generally more efficient way than if a person were doing it.

Let’s take the example of elevators. Before we had elevators, the only way to get to a higher level was using stairs or a ladder. Functionally, both get the job done, but neither is really efficient or convenient, especially when it’s 300ft up to were you want to be. Then the elevator came along, which works in a completely different way than a ladder or stairs. It allows you to easily go up 30 stories (300ft give or take), and even get something really heavy up with you, but it’s limited in the number of people and items it can carry at once. So it creates a different inefficiency, a bottleneck of people waiting for it. This bottleneck resulted in the advent of the escalator, something you see in malls and subway systems. While less convenient than an elevator, it has the ability to move more people through at once. Each avenue of getting up higher has it’s pros and cons, which one you use depends on what your end goal is.

Isn’t this article about automation in business? Why the elevators and stairs? Because looking at the he pros and cons while focusing on your end goal is precisely they way to look at automating technology in business. What is the end goal? How are you currently solving this problem? What works and what doesn’t? How can you get the same job done without using a person? Asking these questions will help you eliminate unnecessary steps in current process and help carve the problem down to it’s fundamental essence and needs.

Once you have carved the problem down, you can then look at what tooling and methods you should adopt. What technologies are already out there that you can leverage? It’s possible that there’s already a software tool out there doing what you need. But often you’ll be pulling in pieces of many software tools, open source scripts and code snippets and abstracting, configuring and editing them for use in the specific business process you’re building.

Once the tools and pieces are ready, it’s important to abstract those away with a layer of orchestration. The orchestration layer is where tools are put to work and the automation begins. This is where you convert human workflows like, “I need to use tool X and I need to give tool X’s output to tool Y. I need to give tool Y’s output to tool Z and then I will get my final output that I need to digital workflows.” The orchestration layer implements the tools’ methods in a sequence that gets the final output you’re looking for. And if you realize during this process that actually Y needs to happen before X, then you simply go into the orchestration layer and reorganize the steps in the process. This avoids changing the tools and how they are abstracted away. The only reason to adjust the abstraction layer is if a better version of tool X is found or it needs to be replaced. Abstraction and orchestration build a functional, flexible system.

Another addition benefit is that if a new problem arises that can be solved by essentially marrying Y and X together or just X and Z, it can be written just at the orchestration layer. So now there is a fundamental toolbox that can solve problems. Automating a system is similar to designing a new product or machine in that you’re creating something to solve a problem. In turn, that creation can also be used to solve other problems you didn’t even know existed.

An important element to note about automation is that it takes a certain level of expertise that is often misunderstood. Experts in DevOps who are very infrastructure and IT oriented are often erroneously sourced for business automation. There is an assumption that because there is automation in both focuses the skills are interchangeable, but the reality is that it is often not the case. Business process automation runs on machines, likely gives out alerts, it might even do things that used to be more systems/IT oriented. But the truth is, when you get down to it, your programming and inventing a new product. Product creation and IT orchestration are not the same. And even beyond the skills of product creation and process analysis, there’s an extra layer of expertise involved in gluing together many software tools, especially esoteric tools.

Remember, automation is inventing something new, like the escalator or elevator. You’re creating a new product to accomplish a goal, so you should shy away from getting stuck in how you currently do things. The worst possible outcome is building a Rube Goldberg Machine. You don’t want to replace a current process that is clunky and slow but functions with new automated technology that is fragile and breaks down because it just glued together the existing pieces at hand. Automation is an engineering problem that requires experience and expertise to analyze and build a solution to achieve an existing goal in a new streamlined way. Don’t stack ladders, invent the elevator.