We are often asked by clients about orchestration and automation, it is a critical component in our transformation target state operating model, cloud governance and cloud migration projects. It is both a cost and efficiency gain and a security / governance mitigation which should not be understated or under invested. The return is not only immediate in the provisioning but it flows through the entire environment life cycle, software development life cycle through to release and support. Automation, if done right, creates predictability, consistency and combined with configuration drift / management should reduce support effort once critical mass of coverage is achieved.
So where do you start with automation? You can approach it from multiple points at the same time or you can align it to the demand pipeline of the projects. It depends on what the key business benefit is that you are trying to achieve? If to reduce tickets to the help desk, visualise / quantify what the volume of tickets is, look for things that can be automated to triage, perform the resolution or if the root cause is inconsistency in implementation, process map what it is that you want to automate.
Quite often though the reason for looking at automation and orchestration comes back to “reduce the mean time to production”, be it via enabling DevOPS continuous deployment, testing and integration or just getting standard builds to the project team quicker. Then be able to get the environments to the testing team quicker and finally, get the production release done, quicker.
How do you best go about this?
We map the process holistically, start with request to IT from the project team and map the steps by request, responsible team, completion checks, average time to complete, SLA to complete, types and rates of failure and escalations. Map it in a spreadsheet first, though to the point where the project team is actually able to start deploying or coding the application. With this data then perform a lean or business value chain optimisation process across it, look at the errors, escalations, hand offs and see if there is a different way to address the problem e.g. expand the SOE to be a purpose built SOE such as a .Net or Java development SOE. Consider the customer of the request to be the project team, not the next team in the process e.g. backup, database or security team and streamline the process to the customer’s needs.
Finally optimise the process looking at elements that can be automated and then orchestrated. Consider the acceptance of the outcome being not only something that the project team can consume on the first attempt but that is also verified (automatically) as being operationally accepted by the companies’ respective risk, security and operational control gates. Oh and don’t forget to break the end to end process down to metrics that can be measured and reported on, a bunch of “mean time to’s”. Little use automating if you can’t then promote the benefits and enter a cycle of continuous improvement!
Finally, you get to cutting the code, automate to the process, do it in reusable blocks which you can then promote out to others to reuse where / when applicable. But what about orchestration we continually get asked, is it not where we will get the most benefit? The answer ultimately is yes, but are you ready for orchestration and before you can orchestrate you need the foundation of automation in place! It is a journey.