What is configuration management?
People (at least some people) have always been aware that knowing where things are and how things work together are good things to be mindful of. It’s why some have always been attracted to maps and puzzles (which are sometimes the same thing), and have that urge to disassemble and reassemble things. Of course, not everyone feels that way – which is why when you mention “configuration management”, many still conjure up images in their head of shadowy people deep in the back rooms and basements of organizations, performing mysterious tasks related to knowing “what is out there” for reasons beyond comprehension.
It can be argued that part of this is due to the fact that if one asks “What is configuration management?”, the answer one gets depends on who one asks, as there is not a single concept anymore (if there ever truly was). As with many things in the distant past, configuration management and CI ownership was once simpler, along the lines of “This my mastodon. You touch I club you but good!” Sadly (okay, maybe not so sadly) we have long left such simple times behind.
Scope and Direction
Defining the scope for the direction of configuration management gets complex pretty quickly, for example, just in beginning with what ‘configuration’ may refer to. Even restricted to usage within operational ITSM, it can mean:
- The thresholds and settings of IT components
- The ‘build’ of a component
- The way a system (parts working as a whole) functions
- A plan for configuration management
- A standard desired state for IT components
- The attributes and relationships of a configuration item (CI) captured in a configuration record
All of these are a part of configuration management, and all are applicable and accurate, depending upon what one is discussing in regard to a particular facet of this topic. Also, there is overlap with other areas, such as availability and capacity and event management that adds to possible confusion. These are just some of the reasons configuration management tends to be challenging; it is a bit like three individuals – one British, one Australian, and one American – having a conversation. While they can converse, there are many terms and phrases that may have to be interpreted and explained, since while they may all speak the “same” language, it does not mean they are effectively communicating.
This issue also extends into how one defines a configuration item. Unfortunately, if you want to cover the right aspects, a short definition for a CI is also often challenging.
A Definition
My own definition for a configuration item is “any component that has the potential to affect anything (a service, other CIs, etc.) in your service delivery infrastructure (i.e., what you utilize to provide service for internal and external customers), regardless of its status or designation (including Test, sandbox, development or any “non-production” or “pre-production” states)”. This means that a component (of any kind) should be considered a CI – and require SACM and Change Management control – the first time it is connected in any way that would allow any activity on that component to impact business services (and hence internal or external customers).
The reason for this should be apparent: if a component has the potential to affect service delivery or anything that supports that delivery, it represents a potential for risk that must be mitigated. This is why any component representing such risk must be recognized as a CI – even before it is considered “in production”, as the “status” of the component has no bearing if that component can effect anything that is supporting or delivering in-use services. Put another way, a “test” component that interrupts services does not interrupt them any less so by being labeled “Test”. If adding, modifying or removing something can cause an incident, you should be tracking that ‘something’ as a CI.
SACM Principles
Because many organization’s ITSM processes are adapted from ITIL, the concept of a CI would not be complete without a mention of some principal SACM concepts within that framework:
- Every CI is a service asset, but many service assets are not CIs.
- A CI is a service asset that needs to be managed in order to deliver an IT service.
- Every CI must be under the control of change management.
All of the aforementioned concepts – or rather, bringing all of these concepts together to enable successful customer services – are part of the goal I encourage in this space: making configuration management and the rest of the ITSM processes you utilize the true basis for operational actions. To do this involves reimagining how most perceive configuration management – that “back-office maintainer of CI records that supply data points for required fields in records used by other (incident, problem, change) processes”. Instead, configuration management should be embedded in the day-to-day operational activities performed by everyone involved in supporting or delivering services to your customers, by becoming the baseline for those operational activities. Rather than trying to build Enterprise Configuration Management, you should be seeking to build a Configuration Enterprise.
The Configuration Enterprise
I took a moment to google this term when I thought of it, and was actually surprised not to find it, so it seems I am introducing it here. I define the term ‘configuration enterprise’ as an organization that is continually aware of its actual operational state because it uses its planned desired state to drive the way it operates.
Certain of you are no doubt already protesting that you have metrics and reporting and ‘critical success factors’ and ‘key performance indicators’ that do this for you – however, those things are centered around your results driving your behavior (assuming of course you can trust the data behind those results). I am suggesting you turn that on its head, and instead make your goal to ensure your behavior drives your desired results.
To enable that goal, the organization needs to identify (enable, mitigate, etc.) all the elements required to deliver a given desired state or outcome – not just for a given process, but by accounting for every action that enables that outcome, regardless of how many processes or organizations are required. The intent is to build a system (really, a system made up of systems) that is designed to be a closed loop, self-checking configuration, similar to what DevOps calls a feedback loop. Each system (people, processes, technology, etc.), from the macro of the organization itself to the micro of a single CI, must recognize the dependency it has on any others, and those it provides to others. In this way, any deviation from the desired state should be immediately recognized as not fulfilling something, and appropriately mitigated to return to the desired state. Note that I am not telling you that you don’t need to measure results – you do. What I am telling you is that what you measure must show you if your ‘systems’ are behaving as required.
You might think you are doing this!
The issue most organizations have is in thinking they already do this, when in reality they have ‘targets’ that each process/system seeks to meet that often are not dependent on the system before it (or sometimes, even reality), or do not adequately provide for those after it, because they are planned in isolation. The key to building a configuration enterprise is in each component understanding what it needs to be successful, as well as what it provides others to be successful – and planning, configuring and delivering to enable that.
This kind of planning and configuration is well beyond what most indulge in. Many will have to rethink the way they view the business of IT provision, as when it comes to providing IT services it is common to ‘contract’ ITSM processes as if they are services, when in reality, operational ITSM processes (and SACM is one, make no mistake) are simply a necessary requirement of being an IT services provider. Put another way, you should not “do” configuration management (or other ITSM processes) because you signed up to do so in a contract – you need to perform these processes by virtue of being an IT services provider in the first place.
This is of course a more operational view of ITSM, considering the execution of the activities required to ensure services are available and operate as expected – in other words, the view that is all too often not considered when customers are being readied for inclusion in the existing ITSM organizational structure. This typically leads to a dissatisfied customer, when what is agreed to on paper – and ultimately must be provided in terms of IT and ITSM services – is far (sometimes really far) removed from the reality of what can actually be provided.
It isn’t easy
Of course, none of this is easy, even with modern tools such as Chef and Puppet, since there is always planning to account for. Still, the better your business is configured to know about how things work, what relies on what, and how a change to one thing affects other things, the more likely you are to avoid issues. After all, you don’t want to accidentally eat someone else’s mastodon – people get really touchy about things like that, trust me!
