In my first post, we talked about the first layer of the automation stack. We discussed how Embedded Automation (e.g Server or Database Automation), provides the domain knowledge to accurately provision and manage the devices and applications in the data center. Enterprise Job Scheduling provides the business-driven automation for scheduling tasks and tackling massive workloads like invoice processing or an end-to-end supply chain process. These are the building blocks upon which successful automation platforms are built.
IT Orchestration combines two automation disciplines that are often confused with each; Run Book Automation (RBA) and IT Operations Process Automation (both represented by BMC Atrium Orchestrator). While they go by many different names, the distinction is relatively easy to make. The original mission of most RBA tools was to take the almost simple, but highly repetitive, tasks that service desk engineers would spend so much time on and automate them. These tasks were often outline, step-by-tedious-step, in a Run Book. And example of RBA would simply pinging any server tied to a new incident ticket, and putting the results in the ticket. Another example would be constructing an end-of-shift report for a service desk manager by extracting incident and problem status information and summarizing it. The bottom line was that RBA tools needed to be highly flexible and also be able to connect easily with different IT tools.
Once RBA started interacting with ITSM process automation, IT Operations Process Automation was born. It was one thing to automatically generate incident tickets from a failure event. RBA was already adept at integrating with ITSM and acting on the behalf of ticket generators like event management systems. It is quite another to generate a change ticket for the fix and then request the embedded automation tool to actually execute the change. This kind of integration was an inevitable demand out of the more mature ITIL process automation domain. The achilles heel of any change management system was always the ability to actually verify that changes were made according to change policies, and what the change request specified was truly enacted. Now I could clearly associate a change with the actual action taken, and even roll-back the change, if necessary. This also empowers the Service Catalog to be clearly attached to a real automated process, like provisioning a server or a database. This is the genesis of Cloud Lifecycle Management, but we will get to that in another blog post.
The converse, and often overlooked, problem was ensuring that all changes were properly documented. Now the RBA tools really came into their own. A server administrator can now automatically create a Request for Change (RFC) from BMC Server Automation, and follow change policies, all without spending hours writing up the steps manual in Remedy Change Management. The perfect example of this is Closed-Loop compliance. When my embedded automation tools scans the system against a policy, and finds an issue, it can automatically attach the remediation for the security finding to a change request.
So, we come to the end of another walk through automation. I would appreciate your thoughts are your comments. How have you seen Orchestration used, or used it yourself? Where do you see the future of orchestration?
Next time we explore Dynamic Workload Management...