Configuration Management: the Human-Atomic angle

I once did an assessment and implementation of enterprise Configuration Management for a customer. They started with Configuration Management only after finishing with few other processes. Until then, I had always believed that Configuration Management was kind of the nucleus of IT Service Management suite of processes. And, guess what, after delivering the process to the client, my belief was only further reinforced! We had to eventually do quite an amount of re-work to streamline functional handshakes between Configuration Management and other processes. That of course meant more time and money.

Configuration Management often is thought of as complicated. But then, what is not? Several years and a few subsequent successful implementation experiences later, I can perhaps point out some areas that are critical for the success of the Configuration Management process.

1 Enterprise Configuration Policy? Say that again please?

Don’t be surprised if you walk into an enterprise that does not have a Configuration Management Policy. Or, one that does have one but does not know that it has one! So what? It’s not a big deal. Look around and find out how these guys manage their physical or virtual ‘assets’ at a local and/or a global level. It’s often a great starting point to know how assets are being managed currently and what policies that is bound by. The situation could feel worse if you discover that they manage assets in a rather primitive way (maybe they track assets through an excel spreadsheet, stored locally or centrally). That, once again, is not a bad point to start from. With the help of these ‘local’ methods/policies and inputs from relevant stakeholders who matter to the organisation, you could draft or enhance a Configuration Management policy. Remember, everything you’ll ever do within the four walls of Configuration Management will roll up to the policy document(s). The policy will need to have process, guideline and technology flavours, and it must also make it clearly understood as to what it is that the enterprise seeks out to be with their IT Service Management landscape. Off you go!

2 Too many CMDBs but not one?

Exactly like any other ITSM processes, what good is a robust procedure without a vehicle to implement it and hold it together? That is the Configuration Management Database (CMDB) or the Configuration Management System (CMS). If your customer already has a smart CMDB (optimally or otherwise utilised) like ServiceNow or Remedy, you simply need to make it talk freely to the process that you’ll develop or improve. If they do not already use a standard CMDB feature, figure out how they currently manage Configuration Items. I’ve worked with customers who limitedly survived with only a centrally accessible database; that was their CMDB. Today’s CMDBs are exceptionally powerful, and you could make use of them to manage your CIs to the level and degree of simplicity or complexity as per your requirement or appetite. Some organisations choose to use highly capable CMDBs to just load a flat layer of basic CI attributes. Whilst this is severe under-utilisation of some of today’s CMDBs’ capabilities, it is not a bad place to start. And then, augment. If you remember the first few chapters of the ITIL V2 books, they differentiated between Asset Management and Configuration Management with how the later defined CI relationships while the other did not. What is important is to make a decision to use a smart CMDB, and build layers into it over time.

 3 Defined Relationships for a Happy Marriage?

Yes! We all know how important forging relationships is. Like humans, CIs too work best when their relationships are clear as water. There are broadly two types of linear relationship between two CIs: horizontal and vertical. Horizontal relationship is more like a peer-to-peer arrangement, although some CMDBs treat them as ‘Parent-Child’ relationship. An example of a parent in this case could be a router, while an interface could be the child. The vertical relationship, on the other hand, is a closer reflection of the ‘Parent-Child’ arrangement. Example: a server may be a parent CI to a child Application CI. Relationships are very critical to perform Incident/Change/Service/System impact assessments. If a server is down (and if its secondary peer is either not available or not working), then all applications hosted on it could be considered unavailable. An application outage however may not make its parent server unavailable.

4 Why should I define Service CIs?

CIs could broadly be considered at two layers: component and service. Component level CIs could be physical (e.g. hardware or network switch) or virtual (e.g. virtual server or application). The service layer CIs are neither physical nor virtual; they are logical entities. An example of a Service CI may be Voicemail service. Due to the unavailability of certain key component CIs that constitute the Voicemail service, the service CI may experience an outage. Clearly, the service CIs act as Parent CIs to the component CIs. Each component CI will roll up to be vertically related to at least one service CI. Service CIs assume critical importance not only for Configuration Management, but also for Service Level Management, SLA calculation and Availability Management, as well as Performance Reporting. While defining the service CIs, you need to look at all of these areas and on-board their requirements. A Service CI being unavailable usually means large scale outage and potential penalties for the service provider.

5 A handshake well done?

I have said before in this article that I consider CMDB as the nucleus of the ITSM grand picture. It’s common knowledge that the electrons and protons need to behave amicably with the nucleus for a stable existence of any object. The same analogy is true for ITSM as well. For example, most of the reporting requirements for various processes are around assets and CIs. That’s the layer where most of the reporting calculations take place. These processes cannot sign off on their respective reporting requirements unless they look at how granularly component attributes are stored in the CMDB and how they are related to each other. Another example that would emphasise on the need for a truly warm handshake is when Change Management plans to make modifications to an existing CI in the CMDB. If the change implementation is not reflected as an update in the CMDB, that would create chaos when the next change is planned on the same CI.

6 Whose job is it by the way?

This one is not specific to Configuration Management, but applies to all areas. You would want to get the standard Configuration Management roles and their responsibilities defined. As a minimum, organisations must have at least one role: that of a Configuration Manager. Depending on the size of the enterprise, you may want this as a dedicated role or a shared one with the IT Change Manager. Combining these two roles makes the functional interactions between the two processes easy. But, this model may encourage bypassing certain policies and standards as both functions are controlled by one individual.

Happy configuring!