Harri Kallioniemi

This post is part of a series of Hybrid Cloud ‘cookbook’ blogs that discuss the key concepts of building and running a true hybrid cloud environment and delivering IT-as-a-Service.

Automation is critical and necessary for any digitalized business for DevOps, etc. It’s all about speed, avoiding human error and excess costs. Automation is the non-visible, below-the-line part of ITaaS.

Automation is usually done with dedicated tools that range from BPM tools to infrastructure automation tools such as VMware vRealize Automation (vRA). There are also dedicated tools for specific tasks (DevOps tools, etc.), and then there is good old scripting. The newest category of automation tools are robotic process automation tools. This wide variety of choices leads to organizations having multiple automation tools and needing to define which to use for different things. The overall automation tool is often called an orchestration tool, which commands task specific automation tools. For example, VMware vRA writes commands to EMC ViPR for storage provisioning, Puppet for configuration management, etc.

Regardless of which tool and approach you take, there are a few key considerations.

Value of Automation

Automation is a foremost requirement for delivering ITaaS, and it requires a business commitment to achieve. Often times, organizations aren’t always initially thrilled by automation. The most common objection I hear is, “it takes only 3 minutes, there is no sense automating it.” While this could be true in some cases, the decision to automate needs to be based on a few key concepts:

• Volume of the task
• Length and complexity of the end-to-end process
• Time sensitivity of the task (how valuable is immediate completion?)
• Avoidable human error and improvement of traceability
• Most importantly, whether or not the service needs to be provided to a non-technical user, such as an end user

An individual usually only sees a small part of the overall process and from that point of view, automation only makes sense if the transaction volume is large. An extreme example of this dilemma was at a pharma company I worked with. We mapped the entire process of provisioning one VM. While the technical provisioning only took minutes, the end-to-end process took 30 days due to the heavy quality assurance processes. In this case, automation would enable them to have pre-approved VMs using a pre-approved automated process, thus significantly reducing the need for Q&A control and dramatically minimizing the process time.

Also, when you start to break up the technical tasks of provisioning a VM, you quickly learn that it’s not just about the VM, but it is about all the services needed around it, including network, security, data protection, etc. Typically these are done inside separate delivery towers, leading to hand offs, which in turn lead to wasted time and money.

Exception Management and Roll Back

While automation is necessary in many cases, there are a couple of areas to watch in order to achieve the optimal economic benefits. First is the biggest dilemma of automation: exception handling. While the human brain is super quick to adapt to changes and utilize logical problem solving, the automation engine does nothing without explicit instructions. Automating normal processes is simple and straightforward, but automating all the associated exceptions and issues is totally another matter. Essentially every single step of your process can fail, and the sources of failure are numerous (wrong input, unknown response in return, timeout, etc.). Robotic automation tools aim to solve this issue through machine learning so that over time, your automation tools will be better at handling the normal exceptions. But the real killer here is the roll back. You don’t just need to automate processes for successful execution, but also for roll back from any point of the process. So, how do you undo the parts you already did?

Maintaining Automation

Another very important component of automation to consider is the maintainability. You have to be able to maintain the process description as the process evolves or as connected IT services change. A poorly designed process description can become your new monolith (you don’t need mainframe and COBOL to achieve that), and you might need an A0 size plotter just to print out the process description. With that size of process description, it is very hard to understand it or debug issues.

Life Cycle View

If you execute a process to implement/provision something, you probably should also do a correlated reverse process for the same. No IT service lives forever, so you need a way to decommission it. This means that a decision to automate something means that you also need to build two separate processes for it, thus making maintenance and execution costs nearly double.

Approaching How to Automate

All of these considerations can lead to an over-engineered solution. Sometimes, a simple quick and dirty solution is the preferred route. In many cases, just getting a process documented into the automation tool is value in itself. However, you most likely will need an iterative approach that includes an initial simple implementation that can be built upon once the task volume increases.

What to automate and how to do it should be based on facts about demand. You need a way to catch the demand signals and that means that you should consider how you organize your IT. You also need to have a process to keep a backlog of requests and decide which ones to implement next. It’s not realistic to aim for 100% automation, so consider where you will still use manual human processes as the service integrators and equip those people with tools, skills, and resources to properly do so.

Summary: Back to Basics

Overall, the basic principles of any application development also apply to automation:

• Build only for need
• Break the process into small and manageable parts (microservices principles)
• Consider the life cycle of the automated process, in addition to the associated decommissioning
• Avoid over-engineering the solution

Implementing robust automation is not a trivial task. You need to consider and justify the investment before jumping into it. It will be a process where you will make mistakes, throw away old automations which cannot keep up with the changes, and face strong change resistance.  But in today’s world of ITaaS, you have no other option but to master automation.

As a last final thought, here are some very true phrases about automation:

• “A bad process is still a bad process after you have automated it.”
• “There is nothing so useless as doing efficiently that which should not be done at all.”
• “The more complex your infrastructure is, the more complex your automation is, and the more complex problem solving is.”

In my next blog, I will write about different aspects and definition of Service Catalog.

Hybrid Cloud Cookbook: Avoiding Automation Pitfalls
Harri Kallioniemi