Chris Boos on Automation

The history of delivering IT Services is certainly an evolutionary process. This is not even considering the huge evolution that has taken place in the technology available to deliver such services. The evolution in IT delivery or IT operation is more or less an evolution of tools. It began with the host operating systems where much of the software that came with the computer was only used to manage the machine itself. Skipping many steps, these tools went through the various stages of network and system management to business service management or business transaction management tools. The latter’s claim to fame is actually achieving what business service management set out to do – making IT manageable from a business point of view.

Automation Auto Pilot

Speaking abstractly all these tools are automation tools. They automate several steps of work that an IT operator, administrator or delivery manager previously had to perform manually. But they are still just tools. They make life easier for the one who is doing the job, but would you call an industrial hammer an automation tool? Therefore I think it is time to take a look into the fish tank of (IT-)tools and approaches available today and show how evolution points towards engines (not so much the tools) that actually decide what to do and then take the action autonomously – only asking for permission, reassurance or assistance if required by process or if no solution is available to them. Such an engine could be called an automation auto pilot and is sitting on top of all the tools available to IT experts today.

We have been developing and using such an engine for more than ten years now and have achieved very good results in quality improvement, availability of documentation as part of compliance and cost cutting. But why do I most strongly believe that this is not an exotic idea, but the logical next step?

If we focus on the two dimensions IT management tool that can takes actions automatically or facilitate taking complex actions on a complex IT and application landscape, we end up with a trigger axis and an approach axis. The trigger axis describes under what conditions an action or tool invocation is triggered. The approach axis describes what kind of action will be taken and how flexible these actions can be taking the trigger conditions into account.

At the left of the trigger axis (x) we place “scheduled”, in the middle “event triggered” and at the right automated. This means that a tool positioned to the far left of the trigger axis will take action at a predefined time. Tools placed in the middle will take action if certain events occur and tools to the far right will take action as they become necessary. On the approach axis we placed “standardized” at the bottom, “rationalized” in the middle and “dynamic” at the top. This means that tools that perform predefined actions without reacting to any information gathered while executing (e.g. cron scripts), would be placed on the bottom, tools following a predefined process but building branches into the process that take current conditions into account would be placed in the middle and tools that combine the best process to be taken for the given situation out of a pool of possible actions are placed on top.

Tool Classification Dimensions

Placing the tools and concepts currently on the market onto these axes will show a clear evolutionary development from a scheduled standardized batch process to an engine that combines possible actions to a solution as the situation requires. The auto pilot function that I was talking about earlier is such a tool that would be placed up and to the right on our chart of automation evolution.

In the chart presented below, the placement of “hot” topics such as data center automation, work load automation and even run book automation are much more “old school” in their approaches and are therefore placed accordingly. Our auto pilot engine clearly takes up the “new approach” position – with a very notable difference – we have been running a successful business on this model for a long time. Thus this is not a fancy idea, but a valid approach and current trends in management software are pointing to exactly this approach.

Automation Auto Pilot as Trend

Maybe this “sorting of the tools” article has helped a little to place other thoughts on automation published here. It will certainly be necessary when we look at why dynamic automation becomes more and more unavoidable as complexity and change rate increase. E.g. following the current discussions on cloud computing from the Atlanta cloud camp organized by John Willis or even the dynamically evolving enterprise clouds as described by Mark Masterson, an automation auto pilot is the only way to keep track of an IT landscape that is fully distributed and dynamic. Just solving the problem of distributed computing and dynamic resources from an OS point of view by creating good cloud managers or VMs does not solve the problem of keeping business applications alive and available with proper execution quality and correct business results. If any of you have ever configured e.g. the Tivoli Correlation Engine in an Enterprise console successfully you know how much work that is. Putting your environment in a cloud would essentially mean you would have to review all correlation rues every time the cloud manager changes your environment. Not possible you say – well that was only the correlation engine. No other system management, IT service management or business service management tool or visualization was even touched. So you see, something will have to be done in order to keep the actual delivery of business services up and running when moving to a fully dynamic environment – this something is an autonomous automation engine or an automation auto pilot.

The terms 000080;">003366;">tool and 003366;">automation do not go well together. Taking a look at other more mature sectors a tool is an item used by either a human or a machine and automation in this context it means that work is done by a machine rather than by a human.

Still the IT industry is lively talking about automation tools and a great many to start with. For a long time I could not get a grip on what all these tools were good for and why so many categories are around. This is why you find a map of the classes of tools around. I chose 003366;">two 003366;">dimensions to lay out the map of tools. Since we are talking about a 003366;">map of tools naturally the users of these tools are the first dimension. The second dimension is the part of IT the tool in question is focused upon.

The user dimension starts at actual IT administrator, continues with business users and ends at managers. The IT dimension starts at the facility level going on to infrastructure, network, systems, services, applications and ending in business processes. You will find this map in the figure included below.

Automation Tool Map

Looking at this map, I have come to the following conclusions:

1.       NSM covers the smallest piece of the map while being the oldest toolset around. When NSM tools came out they were supposed to be used by everyone and save the world. Becoming a mature setup of tools they have clearly found their niche and will definitely stay and important piece in the big IT puzzle. Not much revolution is to be expected here, but some continuous refinement can still bring big steps in effectiveness of these tools.

2.       BSM on the contrary covers the biggest part of the map and surely is one of the newer approaches. I think BSM is a great idea but it has to go though some iterations of focusing in order to be applicable to an average IT and business landscape. Introducing BSM not – the way in should be – means turning everything inside out and even though the economic crises does put a lot of pressure on companies businesses have more important things to focus on that having themselves turned inside out by a changing IT.

3.       BTM is a practical approach to achieve some of the goals – especially in the accounts of visualization and quality management – set by BSM without having to turn over every stone in our IT.

4.       I really do not understand the hype around DCA and Run Book Automation. While DCA seems a logical step (is not IT centralization itself, so its management should be centralized) Run Book Automation actually solves the “problem of missing documentation” – maybe. Other industries would never start their processes without having a clear set of procedures in place how to handle foreseeable situations. Imagine what we would tell an energy provider running a nuclear power planed if they came up and says “sure, we develop best practices how to react to glitches in the systems we go”. No way Hose! So the big buzzword of Run Book Automation is just a fancy way to get the sometimes anarchic IT guys to document what they are doing…

5.       All these tools claim to be focused on automation and most of them may carry some minor seeds of automation in them, but they are in the end clearly focused to be tools. They want to be used by someone (or something) to perform their tasks and they do not act by themselves. So in this map of software used in IT delivery or IT operations the actual automation engine is still missing.

003366;">Part of the latter conclusion makes me happy, because this means we are one of the few people who actually have a machine that operates It by itself and does it automatically at that part. On the other hand this give me the creeps, because this means a lot of people and companies are not ready yet to have IT delivery run in large part autonomously. Looking at al other industries this is the way they have gone and I do think it is about time we get the noting in the IT world.. Let´s get rid of all the boring tasks and let them be handled by the machines. Yes this means giving some control to an engine but on the other hand it means your business is much more in control because reaction becomes predictable and is documented, as well as IT jobs become more interesting since the everyday stuff is nothing IT gurus have to deal with.

For those of you not quite so familiar with IT delivery buzzword bingo here is the elaboration of the abbreviations: NSM = Network and Systems Management – tools aimed at facilitating tasks performed by network and system administrators. ITSM = IT Service Management – tools aimed at supporting the ITIL Service management processes from a delivery point of view. RBA = Run Book Automation – tools aimed at giving staff the proper procedure for handling a given situation. DCA = Data Center Automation – tools used to perform tasks from a central point of administration rather than having to connect to all servers or services involved. ITPM = IT Process Management – tools used to track and escalate processes and communication between the silos of It delivery and also business users. WLA = Work Load Automation – a much spoken set of tools to automatically provision IT resources and distributing workload across these systems as required. BPM = Business Process Management – tools used to improve IT´s alignment with business processes though modeling It from a business point of view. BSM = Business Service Management – a set of tools used to manage IT services from a pure business point of view. BTM = Business transaction Management – a quite new approach to tools created to manage IT with business transaction as the controlling parameter. This seems to be a practical approach to narrow down the too broad view of BSM as you can read at Doug McClure´s blog.

I wish you all a happy new year. This may sound hollow as the upcoming year is starting out with immeasurable uncertainties. A recession is unavoidable as the economic mechanisms are working their way through the different economic sectors and into everyday life. Given the origin of this recession – the financial industry with capital being one of three pillars of our economic system– even systematic change may be in store. The greatest problem is decisions being held back due to these uncertainties thereby creating an even greater economical impact. Thus what we definitely are feeling as a crisis is a powerful well of change. This well will flood through economy, society and of course technology. We will need strong decision makers and innovators – real entrepreneurs – to embrace change and make use of its power to tackle some of the grand challenges built up during the last 50 years.

For those of us promoting new technologies the willingness to embrace change is often the biggest obstacle in putting these new technologies to use. Think about the argument of how cloud computing cannot be a good thing because it changes the relationship between our data and our computations we are so much used to. Or think about bringing the concept of automatic system operation to the administrators who will no longer be just operators but turn into system experts. All these high tech concepts require a dramatically changed way of approaching everyday problems and those of us implementing these new technologies know that inventing the technology is less than 50% of the way. The biggest challenge is attracting enough interest in all players the new technology touches, in order to make them embrace the required change to effectively make use of the new technology. The current situation may prove to be one of the most potent accelerators for technological change possible. So to all of you – those who invent, implement, decide upon or just make use of new technologies – make wise, well thought of and brave decisions embracing change. You will be the ones who will contribute towards a speedy way out of the current uncertain situation.

After giving you so much leeway ( ) by posting a few personal stories from the past summer to past autumn we are all back to business and I want to share some of the reading and thinking that I have done during the quiet time between Christmas and New Year´s Eve in the articles coming up this week. I will start out with a little catching up on the “clouds are bad discussion” started by Richard Stallman with an interview given to the Guardian in September 2008. I do believe there was a good deal of stubbornness and corporate mistrust behind condemning the cloud concept as you will read. I will then continue with a post on integrating the concept of automation – rather than just tools – into IT operation processes and tool infrastructure. After you have read Roland´s post on “Automating What?” in November you may be interested in how the concept of automation is integrated into everyday IT service management and how our concept of e.g. an automated incident management is incorporated into a working IT environment. Following this post I will try to show a landscape of technology and tools and the way the ongoing development is focusing in on automation as a concept. This process was started when tools were used to ease the manual process of maintaining system functionality (e.g. system management tools) and continued by the automation tools that enable complex changes to be performed by entering a simple command (e.g. change automation or run book automation tools). The process is now at a point where actually decisions are taken by the automation software (e.g. what hardware is used to do what tasks by which is decided by workload automation tools) and will finally come to tools that make use of all the experience of system administrators in order to automatically decide how to keep systems alive. Thus automating incident- problem- capacity- and availability management. This kind of tool is what we have been using and developing for quite some time now ( see the aAE) and the post will show how this kind of tool integrates with the whole landscape of tasks and tools involved in IT service management.