In this post, we’re trying to achieve clarity. Specifically, clarity between a pair of common IT terms, the definitions of which can sometimes seem to overlap: automation and integration. We think it’s time to reach consensus on how these two critical IT concepts are used, and in the process detail how they work together.
Automation can basically take one of two paths. It can be script-based or it can be an end-to-end solution (let’s call it “workflow”). Scripting in the context of automation is task oriented. You can spot script-based automation because it takes place once there is a discrete trigger. A certain threshold is hit, certain intel is received — the system reaches a pre-determined level or circumstance and the automation task is launched accordingly. Script-based automation, in short, is proactively prompted by an alert and implements the task without manual intervention.
End-to-end workflow automation, however, specifically accounts for a complete workflow process — and workflow automation, more intricate and robust, is what requiresintegrationacross systems. When you start to layer in tools, that’s when data can really be modified and acted upon. Integration allows me to speak multiple languages, manage multiple workflows, and to more seamlessly move through processes. If there’s an alert, I only need one translation to respond, to interact with data between two technologies.
At the end of the day, however, integration is just getting two systems to talk. What I really want is the application of business logic to transform that data in to something with intrinsic business value. That’s the objective of effective workflow automation, which lets me do “bigger, better, faster” with less risk.
Now we see the importance of how we, or a prospective client, might distinguish between automation, especially workflow automation, and integration. Workflow automation requires a considerable amount of integration, but that doesn’t accurately describe the desired end state. When a client or prospective client says they want to “integrate,” they probably have a good sense of the business need they want to solve, but they are not following through on what the best solution will entail.
For example, let’s say you want to “integrate” a fault-management system with your trouble ticket system. Is that valuable to your organization? Maybe, but you don’t need a heavyweight IT consultant to do that; you can get a college intern and save a ton of time and money. But when you’re done, all you have (as I mentioned above) are two systems talking to each other.
What’s going to deliver real business value? How about a more fully formed vision of how the systems interact? Perhaps you only want to open up a trouble ticket under certain circumstances. You want fields in certain documents pre-populated. You want the right response teams notified so there’s less lag time. You want to query database details, run tests to determine type of server or details on a device, etc., and put the test results into the ticket?
Now, you’re applying business logic to integration! Now systems aren’t just communicating, they are cooperating.You can open your trouble ticket with very specific parameters that will accelerate resolution. That’s thinking in terms of overall organizational benefit.
Why is this high-level understanding of integration and automation essential? For me, it boils down to control data. Most of us are familiar with the Gartner-supported adage that a full 75% of any organization’s information exists outside its main data centers; only a quarter is at the core. People are using that data, often doing things they shouldn’t do with it (unintentionally or not), and generally just wreaking havoc.
We also know that humans cause 75% of all problems that take networks down; take humans out of the equation and you minimize problems. The alignment of those factors is almost eerie — but it can’t be denied. The right balance of automation and integration, implemented with an understanding of their differences, can slash data network problems.
The most frequently leveled critique against integration and subsequent workflow automation is that it’s costly and resource intensive. We fall into a Band-Aid mentality, thinking, and “let’s just write a script” for a quick fix. That might work for the near term, but there are organizations with thousands, even tens of thousands of scripts now holding their network together. Why not find a smarter way to streamline the entire process, align platforms and systems, factor out more potential human error, and truly optimize performance?That is the straightest path to achieving “bigger, better, faster” with less risk.
Knowing that this is a topic of some debate in the IT community, I definitely welcome your thoughts on the distinctions I’ve drawn — and I’m definitely going to have further conversations along similar lines. Next, I want to examine script-flow vs. workflow, and invite insight on that topic as well!