How to Scale IT Automation With Consistency and Confidence
Understanding the different parts of an IT platform will help you choose the right places to employ automation when developing software.
Join the DZone community and get the full member experience.Join For Free
When I first started thinking about IT automation and all the opportunities to improve processes at scale, I figured out that it would be a problem better tackled if broken in two, the first one being what and the second being how. For the first piece, as outlined here, I tried to articulate the importance of understanding the pros and cons of IT automation and, maybe more relevant, of building a decision process to define where to put your bets. I truly believe that mapping the most important value streams in IT delivery, putting special focus on the hand-offs between processes, is where you should be and where the gold pot lays, waiting to be taken.
After realizing that automation is a must-do, enterprises tend to map, hopefully through VSM (Value Stream Mapping), as many automation opportunities as possible, either to replace manual labor or to supplement it at a large scale. While doing this, it might be really tempting to start capturing the benefits of such “opportunities" sooner rather than later. Some will capture some early benefits through the development of ad-hoc code to automate tasks, and others will capture some benefits by choosing the first tool on sight, automating a handful of manual tasks. My humble opinion is that, although there’s nothing wrong in getting your feet wet with those early-phase “projects,” to really implement a sustainable automation program capable of scaling fast with plug-and-play capabilities such as AI and machine learning, a platform must be defined and implemented as soon as possible.
A platform appears to be the logical answer, with a very nice fit, to the second piece of the problem: the how. Although everybody seems to label everything as a platform these days, a designation that is, very often, interchangeably used with quite a few products, in my mind, a platform is the sole description of the capabilities a technical framework must have. Some software products deliver a platform, but a platform is something that can also be composed of capabilities delivered by several different software components, and the associated processes that enable the alignment of its operation, outcomes, and business needs. The platform definition should survive the myriad of tools and technologies that arise every day and should enable organizations to predict, with some level of confidence, what can be produced, how much time it will take to produce, how much it will cost, and how the production pipeline can be controlled and optimized over time.
"Platforms are structures that allow multiple products to be built within the same technical framework. Companies invest in platforms in the hope that future products can be developed faster and cheaper, than if they built them stand-alone…” ( Jonathan Clark)
I personally like the analogy of a platform with a factory. In our illustrative factory, there is an assembly line, and as such, on the manufacturing floor, a well thought-out and coordinated workflow is executed, transforming raw material, moving through several specialized machines, into processed goods. For this same assembly line, there’s the control room, where product specialists supervise the efficacy and efficiency of the production line through the careful inspection of online dashboards and reports, looking for opportunities to improve the overall workflow. Our factory also has docks, where raw material comes in to be processed, and from which goods are delivered to the customers. Last but not least, there is the workforce, a very talented and skilled group of people responsible for operating, maintaining, and improving the machinery on a continuous cycle, enabling our model factory to thrive and our customers to be very happy with the quality of the goods we deliver and the speed at which we are able to fulfill their requests.
This analogy, when applied to an automation platform, means that, for the manufacturing floor, a set of capabilities or specialized machines would need to be available to transform the inputs in the desired outcomes and ensure that the designed workflow will be followed, over and over, making the outcomes predictable, consistent, and compliant with existing standards. The manufacturing floor would be the execution layer and would be composed with, at least, the following capabilities:
- Capture: The ability to capture inputs from different data sources;
- Content: The ability to store, retrieve, classify and version content, regardless if structured or unstructured;
- Workflows: The ability to document and execute pre-defined workflows, control their states and ensure they are documented according to open standards. This ensures the automated flows are well understood and not lost over time;
- Decisions: The ability to make automated decisions, based on flexible criteria, throughout the workflow;
- Robotic Automation: The ability to deploy robotic workforce to replace or supplement human workforce and enable the automation of a wide spectrum of use cases at a large scale.
The control room, in this conceptual automation platform, translates to the governance layer and would be composed of the following capabilities:
Policies: The set of rules an policies to how the automation of IT processes should be handled, enabling the organization to learn and sustain its use at scale;
Monitoring: The ability to monitor automation execution, assuring outcomes are met when needed and how planned;
Dashboard and Reports: The ability to view the current state of the platform as well as the historical performance of key metrics;
Artificial Intelligence and Machine Learning: The ability to apply mechanisms to learn from previous executions to get insights on what and how to improve the execution of existing workflows.
Our factory docks translate to the platform's user interfaces, that should provide a unified experience to workers, partners, and customers alike, and should be extensible and based on open standards. The workforce translates to the group of people responsible for maintaining the platform health state, reviewing its policies and rules and ensuring capabilities are plugged in and out as needed to achieve the desired results of IT delivery.
The definition of the essential capabilities of the platform is the key enabler for organizations to scale IT processes automation with consistency and confidence.
The platform technical framework should be generic enough to survive the emergence of new technology, but specific enough to enable the deployment of the right set of tools and get the job done.
Although the platform, as well as its core definitions, will change as organizations learn what and how to automate, maybe more importantly, as they learn what is worth automating to achieve greater scalability and efficiency, and what not to automate, having the platform defined and established is a no brainer. Organizations will be better positioned to capture sustainable benefits of IT process automation with one than with Ad-Hoc, first of a kind, initiatives.
Published at DZone with permission of Ricardo Coelho de Sousa. See the original article here.
Opinions expressed by DZone contributors are their own.