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.

Chris Boos is attenting the IT Automation Summit on BrightTALK.com on 7th of April 14:00 CET. All webcasts will be recorded and are available for download afterwards.

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.

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….

I finally find the time to write to you on the integration of automated IT operating into today´s working environment. One should think that automation means that just some other tool will be installed into the void of the IT service management jungle and maybe some administrators use this tool and become a lot better and a lot faster. Actually that is exactly what I am NOT talking about. If you are interested in my opinion on the “Automation Market” you will read an article here soon. So what I am talking about is more of an auto pilot – a machine that actually looks at problems and chooses to take action.

The question I am always beeing asked is ‘does this integrate with an established working environment and established processes e.g. ITIL?’ Yes it does. Indeed it needs established processes to function properly. An automation engine like ours (ff0000;">aAE) basically replaces the initial contact to IT experts.

Fig 1 - classic ITIL incident management

Let us look at the ITIL V2 and V3 incident management process for example. As you probably know (see figure 1) a normal ITIL incident management process is either initiated by an alarm from some monitoring system or by a user contacting the helpdesk. The helpdesk handles all the bureaucracy and then passes the incident on to the IT experts who will perform further analysis – if required collect additional data and perform additional analysis – and then either take immediate action to produce a solution or initiate a change process to take this action. As you can see in figure 2 in an automated incident management process the automation engine takes the place of these IT experts. This also includes the engine communicating with the helpdesk, performing additional analysis, requesting additional data, documenting its actions and so forth. When the automation engine cannot find a solution it will contact the IT experts and ask them to step in. Only this time the experts will get a well analyzed incident with most of the boring work and analysis already done and well documented so they can actually work on something new and interesting.

fig. 2 - ITIL incident management with automation

This is how we introduced this auto pilot into our own ITIL compliant IT service management unit. We promised the real technical experts that they would never be bored to death by everyday tasks and tedious busywork. Instead the engine puts only these problems on their desk where an expert as such is actually required and can use his or her talent instead of just keeping mindlessly occupied. If you want to read some more on the human element and concerns connected with the introduction of automation you might want to look at the article “Plays Well with Others” written by Ellen Fussell Policastro last August. In this Article automation is looked upon not in an IT sense but in an industrial sense. This environment deals with change more practically than just IT and therefore it is probably an early adopter for the automation change on its way now.

So you can see that in an environment with well defined processes it is very easy to place an automation engine or an IT operating auto pilot. In an organization that does not have IT operating processes in place yet, just finding the proper interfaces for the automation engine and redefining the roles of the IT experts is probably a piece of work for Sisyphus.

fig. 3 - ITIL integration of automation

Incident management is just one example of how an automation engine that actually acts like an auto pilot can be integrated to dramatically reduce cost in IT operation while simultaneously increasing quality and making the jobs of IT experts much more interesting. As can be seen from figure 3 the automation engine places itself between CMDB with enterprise monitoring system and the process layer actually involving IT experts. This is not only valid for the reactive ITIL processes like incident or problem management but also for proactive processes such as availability or capacity management where our autopilot engine will itself invoke work load automation tools in order to up- or downscale an IT environment according to predicted usage and demand.

This level of integration into established processes and behavioral patterns of technical advanced staff is very rare for a tool that radically changes the workload of IT operating teams, service managers. So this approach is one of the few roads available to actually move one step ahead in an environment that produces ever more complex IT applications, interdependencies between IT services and speed of change within the environment. Just think about the kind of pressure a fully cloud computing based banking data center would put on administrators…

They would have to cope with a dynamically changing environment, changing dependencies and rapidly changing communication matrixes. Automation could handle the ordinary tasks in such an environment without being pressurized by speed and changing preconditions and contact IT experts with exact and well documented information when an unknown issue occurs – relieving them of the pressure generated by the dynamic IT environment and making much more use of their actual expertise. If that is not what we want (I could not really see a reason) it is certainly what we need to keep up with a changing world without further demolishing the image of the IT-Crowd.

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.

Reading and writing about IT automation, I keep on learning about the subject. Lately I found that there are so many flavors of automation around the operating processes of IT, that misunderstanding seems inevitable. So I try to make a point here to talk about the different kinds of automation one can use all around maintaining a high quality IT environment.

1. 003366;">Incident-, Problem-, Capacity- and Availability Management
   Automation engines specialized on analyzing and handling events that occur in a IT environment that may lead to or themselves represent malfunctions, loss of quality and the like. Both reactive (automated reaction to an incoming event) and proactive (automated actions taken to prevent events from occurring) are target of these engines. Automation engines that handle the “fault operating” are either embedded into the ITIL processes (see blog entry on extending ITIL with automation) like our automation engine (003366;">aAe) or are embedded into system components or management systems with a narrow scope e.g. on redundancy activation.
2. 003366;">Change Management
   Automation engines specialized on performing changes that modify or extend an IT environment automatically. Either these engines are Inserting an abstracted layer above tasks that need to be performed (like adding users, restarting a component and the like) these engines allow an administrator to perform tasks on many machines or on different platforms without by interacting with the automation engine. An example for this kind of engine is the Puppet framework with a very structured approach to abstraction. Or these engines focus on scaling an IT environment by dynamically adding resources or automatically installing or modifying a system like the Tivoli Provisioning Manager or VMWare Virtual Center does.

I really do hope (not just to save you some consulting fees) to have helped avoid misunderstandings, when you are talking to others about automation and even better maybe I could point out some additional techniques you can look at to make life easier.

Some time ago I published an article on the future of IT operation after we are through with all the ITIL implementations (still) taking place. Assuming that all the nice failure handling, proactive failure avoiding and communication processes like Incident, Problem, Capacity and Availability Management are in place, implementing automation is the logical way to move ahead. Compared to implementing ITIL automation actually changes the things that are done and the way they are done. As you may have guessed this statement alone was fertile ground for interesting and heated debating.

Generally the article concluded that implementing the ITIL processes concentrates on the interfaces between IT experts, clients, business requirements and the like where automation concentrates on the way IT operation is actually “produced” (in an industrial meaning of the word). Even though these two may be viewed separately the article shows how an automation environment highly depends on monitoring and IT component data. An ITIL environment puts forth a valid definition of both data sources for a complete IT environment and is therefore a good foundation to start implementing automation.

An IT operations environment with implemented ITIL processes also has common interfaces to the acting staff members. This makes it very easy to “inject” a new entity – like an automation engine – into the whole system. In such an approach the automation engine wraps itself around the data sources of CMDB and monitoring systems. All communication that would today be directed towards human recipients is handled by the automation engine first. Only if the automation engine is not able to complete the task the IT experts are involved.

This short description reveals how well an ITIL implementation prepares an IT organization for implementing automation.  It also shows how automation is made completely transparent to the business using the IT – as the automation engine acts like any human entity taking part in the ITIL processes.

The article itself gives a short overview of the “operational” ITIL processes and how their implementation builds the foundation for automation. If you are interested you may read the whole text here.

You have seen a number of abstract articles talking about the “interdependency model” of an IT environment that is necessary to actually automate across operational silos on this blog. Building this model actually is the main challenge in implementing automation.

I have seen customer situations, where building the dependency model was such an extensive effort, that the focus for the goal of implementing automation was completely lost. An interdependency model is supposed to answer the question “how does one entity in a IT environment depend upon or influence other objects” or “Why the ff0000;">@)!(/Q$§ doesn´t it work anymore after someone I don´t even know changed something I don´t even care about?”.

Though simple answering these questions without having a good CMDB in place and being able to query that CMDB on an expert level, leaves a long trail across an IT organization. Since these key questions are asked for every failure and should be asked for every change an interdependency model is obviously something one REALLY wants to have.

As this model is also one of the key input streams to an automation engine that actually operates IT across silo and competency boundaries we have put quite some thought into the art of modeling. Typical techies we are, our first approach was to build THE BEST of all possible models. We started to build our methodology on the basis of economic dependency models. Well, what can I say… We got a great model and maintaining it just for fun would have cost us an arm and a leg plus maintenance would never have been possible from our technical teams.

So we went back to the think tank with the preliminary assumption, that we would be willing to simplify the model – if we could produce one that could and would be maintained by the technical staff themselves (acceptance is an important factor).

We arrived at something we call the arago M-A-R-S model.

003366;">The “M” is for “Machine”

A machine (real or virtual, cloud compartment or actual operating system) is still the basic component of any IT application. Machines can be servers, network components and anything else. Administrators tasked with keeping the infrastructure alive do normally not know much about the business applications running on their “machines” but they know their machines on a first name basis. So a machine is a basic building block of IT infrastructure as well as a component very close to the technical staff. Thus the entity of a machine fulfills both our pre requirements (simple to understand and maintainable by the IT staff)

003366;">The “A” is for “Application”

An application is something that is used in a business process. Or technically speaking an application is the “thing” a “user” complains about when interfacing (talking to) the IT department. An application is therefore the basic building block from “the other side”. Where a machine is the basic building block of the technical view of IT, applications are the basic building blocks of the business view of IT.
Naturally an application uses machines or much better “-S-ervices” offered by these.

003366;">The “R” is for “Resource”

As you may imagine building up a dependency model by listing all the services offered by a number of machines and then listing all the services used by an application may leave you with very long lists. So we decided to introduce one layer of abstraction into our approach to dependency modeling. This is called the “resource” layer. A resource combines a number of services with a 100% dependency (e.g. an SAP service will never run without a database service, thus there would be an SAP resource combining the two services into one entity and thereby reducing the complexity of the dependency tree of an application).

003366;">The “S” is for “Service”

Service defines some functionality that is offered by a machine or a cluster of machines (for redundancy and availability reasons). A service in this case is an IT term that describes a simple building block of software running on a machine. A service can be anything ranging from an operating system or a network connection though a simple application such as a web server or database all the way up to an SAP system or an individually programmed piece of software. A service is something often talked about in the IT organization and usually something that has developers or vendors attached to it.

As simple as this may sound: this four-layer model allows for a real connection of all silos within technology and organization. This model can be maintained manually or – better – can be imported from a good CMDB.

Combining monitoring information with this model (i.e. hooking up monitoring and master data with the nodes of the model) is the basic input for an automated environment (also see input stream and naming convention articles on this blog). You can read the full article on “Measurement as the Prerequisite for Automation” here.

I am sure you will find other good applications for a simple model – or even better maybe you do have some suggestions on how to improve and/or further simplify this model.