Chris Boos on Automation

Talking and thinking about automation so much can be like sitting in a forest and not seeing the wood from the trees. Only recently I have discovered that some of the ideas we are already applying at arago are a step beyond what is generally called IT automation. Therefore I want to give a clear picture of what is possible compared to what is widely known to be top of the pops automation technology.

Automation Tools for Stressed out Admins

As you have seen in previous posts, there are many buzzwords describing automation technology and they are all more or less cool and more or less useful approaches towards making the process of maintaining ever more dynamic IT and application landscapes. But this is not where it stops. All of these tools just take a part of the work process, wrap it into a nice user interface and hopefully standardized configuration. None of these tools actually does the maintenance work, takes the necessary decisions or finds solutions to upcoming problems or adequate answers to imminent questions. But that is what we want, isn´t it? So what we want is something to automatically use all these automation tools to “just do the job”, something to automate the automation.
The best way to explain these different automation tools and their application in IT is comparing IT maintenance to flying an aircraft. In order to keep the plane up and running there are many different tools and technologies that automate the actual flying process. There are also many systems that automate the task of executing all the commands that originate from the flight support systems. These commands are transported to the actual aircraft mechanics where changes in the wing positions, thrust, flaps etc are executed.  All these systems themselves automate manual tasks. A pilot flying a modern aircraft no longer has to manually move parts but uses automation tools to do the job for him. Still he is flying the plane. For tedious standard situations our pilot has another tool, called the autopilot. This system does the job of the pilot in such standard situations. The autopilot uses all the other automation tools aboard the aircraft to perform the task of keeping the plane up in the skies. Theoretically the autopilot would only call for assistance when it cannot cope with the situation at hand and that is when the pilot has to step in.

Autopilot Approach to IT Maintenance

It is exactly the same in IT. With all the automation tools around, you should use an auto pilot that can handle all kinds of standard situations when managing incidents, problems, changes, IT capacity and overall availability. At the core of this auto pilot for IT operations is an autopilot engine. A large set of possible actions is stored within this engine. The job of the engine is to combine and recombine these possible actions to resolve any upcoming issues automatically. Only when it encounters a situation it cannot resolve after applying possible actions should it contact the IT experts and ask for their assistance.
This approach changes an IT expert from someone who has all kinds of good automation tools at his fingertips but is constantly battered and chased by important and urgent issues to an expert who is contacted only when his expertise is required.

003366;">This auto pilot approach minimizes the probability of human error (which is constantly high in IT operations, as there is always more than one task that needs attention in a normal environment), guarantees short reaction time, relieves the IT experts of tedious standard tasks and give them time to concentrate on important and interesting issues. An autopilot in IT operations pushes the job of an IT expert up the value chain and improves service quality at the same time.

Talking about automation on the way to IBM PULSE 2009 got me some interesting insights. I did know that most people do not really feel comfortable, when a machine actually acts autonomically. But that most people would expect to actually get a tool that forces them to click though their whole IT infrastructure and application landscape in order to DO something was really astonishing to me.

Why? Well because we have been working so differently for many years now. Thus I feel obliged to give some examples of automating tasks in an environment like the one I have been writing about for almost a year now. Maybe some of the things you found quite interesting will become clearer after reading this practical example.

Ok, let us think you would want to automate the task of deleting a user across your IT landscape. A rule we have entered years ago and have been using ever since. In an automated environment like ours all you would have to do is set an „issue“ onto the automation engine bus that says „delete user XYZ‘. This issue will be set upon the graph of the IT dependency model and look for any node that has rules attached to it that know how to handle „something“ with the data „user“ and the action „delete“. For this issue the graph of the IT dependency model will reduce itself to these nodes that know how to handle it. The issue will then map out a road though the nodes –this is what the engine does and this is the real secret behind automation. Each node the issue visits will perform some action – in accordance with the rules – and will return some input to the engine. The engine can  make out whether it needs to add additional nodes onto the issue’s travel list, remove nodes – because some other action has already taken care of the demands of the issue requesting action, or whether the issue in resolved, because there are not more actions to be taken. If the latter is the case the engine will look for any other issue that may be able to use or issue’s data and if that isn‘t the case, dismiss the task as completed.

So what does this mean practically?

For every OS you have to write one action rule that specifies how to delete a user. For every kind of directory or IAM application you have running you will have to write a rule respectively. That‘s it! These are probably scripts you have anyway and you simply upload them into the engine with the rules. The engine will determine what nodes the rule should attach itself to and will execute the rule for any issue that seems suitable.

So compared to a system where you actually have to define what to do where before it will delete a user across your infrastructure this is remarkably simple. Not only the time for deleting a user will go down from 40 minutes to 1 as some other vendors say, but the time for installing this neat gadget will go down from 2 days to 0 because the rule is already there for most OS and IAM solutions. If you really want to add some exotic system, then you will probably need 10 mins to do so.

So the next logical step in automation is not just improving the tool that lets you execute some commands, maybe remotely or maybe with a good archive of scripts, but to have an intelligent tool that will actually work for you. You tell it the result you want, in this case remove user, and it will find out how to go about to achieve this result.

Deleting a user is a change and most likely an unplanned one as such. The same technology can also be applied when reacting to incidents, problems or user error reports. Then you can tell the engine that the desired end result is that you want the problem to go away. It will find out what to do where in your IT infrastructure by itself and it will do it – well maybe it will go and ask you for permission though integration into a process management system, (that is the way we do it) for some critical actions, but other than that it actually goes on and does the job – it actually figures out what to do, follows through and documents all actions taken.

So there is not much difference between what you use as automation today and what AUTOMATION can actually do from a „do I have to be afraid“ point of view. But there is a great difference in result. An automation technology, that will actually figure things out will much better align to business requests, work with a changing IT landscape and will integrate into all the ITIL operating processes.

000080;">Got you interested? See some examples at IBM PULSE 2009 tomorrow. Conference Center 123, 3:30-4:40pm. See you there….