Chris Boos on Automation

000080;">Warning: This post contains just as much sarcasm as it contains serious content.

In many discussions I have founds that grasping the concept of automation is alien to most people´s mindset. Are you one of them? Do you really prefer to work your butt off doing seriously dull stuff than sitting in an arm chair with a cocktail? Or if you are not that lazy, do you really prefer mind numbing repetitive tasks to trying out thrilling new things or finding an elegant solution to a tricky problem? (Well, if you answered yes to any of these, please go and visit some soap opera or sitcom blog instead and never ask yourself why your life is soooo boring that you need to tune into life somewhere else….)

So you are still reading? 000080;">Glad to meet you. I do believe that most great inventions were made because we are a lazy kind of animal. The only thing that can get us out of our laziness is something stimulating to our brains. Everything else we try to get rid of. Usually we start out with the low hanging fruits and move on to more complex problems from there. E.g. inventing the wheel meant getting rid of the need to carry everything on our backs, using many people to transport a heavy item or it meant using fewer people or animals to do the same job (ancient form of cost cutting and let us not talk about the invention of sliced bread here). An example of a more complex problem would be managing a Web Portal with 1.2 Million transactions a day that is connected to three different ERP Systems using two different SOA approaches and so on…

Corporate Culture without Automation

Are we back to the point where you say “that cannot or should not be automated”? Yes it can, and yes it should be automated, because once you know how to handle the everyday hick-ups of even this complex IT environment you become very bored with it. Well you might say, if that really is automated then the job of administrating this stuff will be gone – so what? So were the jobs of the people who used to carry the bricks to the pyramids when they all of a sudden started using wheels and carts. And guess what…. Since then the population and average wealth of people has increased greatly. And one more interesting piece of information… The people who started using the wheels right away got much richer or at least had much more fun that those “traditionalists” who said carrying bricks is supposed to be done manually. Why is that? Well because management liked to get things done quicker and cheaper… Sound familiar? Well, management has much fancier titles today than “just” pharaoh.
Well back to serious business, I guess you get the point – progress in IT administration is on its way and stopping it is not an option – especially not in the current economic situation.
So what do all these great inventions that really took work off our backs do? They conserve knowledge collected by hard work and experience and apply and reapply them. 

So conserving knowledge on how complex IT environments are managed is what we set out to dowhen developing the arago Automation Engine (ff0000;">aAE). Looking back at our operations we have done quite well. We are now able to handle roughly 68% of all issues coming up during the day automatically and only deal with the interesting ones manually. This is also why our administrators actually have an interesting job compared to the ones who do the same thing over and over and over again – just to keep busy.

So what do we do? We take a model of the IT environment and collect all the tiny steps necessary to keep this environment up and running at all times. These tiny steps are then generalized, so they can be applied and reapplied as needed. The big invention behind this is the algorithm that actually analyzes incoming issues and finds out which of the tiny administrative steps need to be combined in order to resolve these issues. So automated IT operation is the conservation of IT experience and knowledge as well as a fairly smart machine (not quite as cool as the wheel, but getting there) which knows how and when to apply these experiences.

PS: Downloaded and actually licensed that cartoon from www.CartoonStock.com… Really love it.

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.