Most IT shops just starting their ITIL journey, including smaller ones, need to get past the idea that they can “do IT” without a CMDB.
If you take a close look at configuration management, and what a well implemented CMDB offers you can conclude that (with apologies to Norman Maclean) the river that flows through IT Service Management is the CMDB. Good IT Service Management is simply not possible without one.
If your organization is starting to “grow-up” and considering IT Service Management based on the ITIL, then it might be time for a maturity assessment and benchmark against the ITIL. The purpose of an assessment is to determine what you do well, where your greatest pain points are, and hence what you should tackle first.
Most maturity assessments result in the usual suspects of what to do first: Service Desk, Incident, Change, etc. But Configuration Management and the CMDB itself directly pops up in every ITIL process and function. In a recent survey configuration management and CMDB expertise was identified as one of the top skills requirements for practitioners.
Let’s take a quick look at how a CMDB is used by each of the IT Service Management functions and processes, and how it can help any IT group growing up with ITIL.
When we make a call to the Service Desk, the Service Desk Analyst starts to ask some questions on who we are, and then confirms via further questioning where we sit, our phone number, the details about what we use (laptop, PC, etc.). To do so they are accessing a CMDB. If our question, about a specific application for example, they may need to check the SLA hours to see whether the time of our call falls within the support time window based on the SLA. When they open an incident based on our call they need to associate it to a specific CI (our desktop, our laptop, an application, etc.).
For the user the ability of the Service Desk to know how to handle their call is almost directly attributable to the accuracy of the CMDB and the other IT Service Management processes that rely on it such as Incident Management, Problem Management, Change Management, Service Level Management, etc.
The real value of Incident Management is only realized when we have an accurate CMDB and when we can associate incidents to the appropriate CI’s. This enables faster first contact resolution in the future by other Service Desk analysts as they will be able to find similar incidents and their resolutions. It also makes incident trend analysis infinitely more valuable as knowing which CI’s (or CI types) are causing the most incidents can help us determined if we problem management ought to be involved.
As incidents begin to look more like problems whereby we begin to realize that if we could find the underlying root cause we can make a lot of incidents go away in the future, the Problem Management teams first line of inquiry starts with the CMDB – they need to understand the components involved and their context which can only be gotten from querying the CMDB. Sometimes the symptoms of a problem can point you in the wrong direction. For example, an application that is hanging can be caused by the database server, by a network connection, etc. Unless you know the CI relationships involved, you can spend a great deal of time investigating the wrong problem. An accurate CMDB can help you avoid solving or expending to many resources on the wrong problem.
This is perhaps the easiest one to connect to an accurate CMDB. An RFC can only be issued against a known and authorized CI. We cannot do a true change impact analysis without an accurate CMDB. Without some form of a CMDB Change Management is extremely difficult to do as we cannot necessarily identify what it is we are changing or what the implications of those changes will be. That’s one of the reasons we see statistics change induced incidents run as high as 87%. Changes are there is no CMDB of note in use in these circumstances.
Proper Release Management is critically dependent on the CMDB to know the “last known good state” of the CI in production in order to execute back-out plans or to determine the correct version of the CI in the DSL or the DHS.
Resource Capacity Management is all about the CI’s that make up the IT Infrastructure – what is their total capacity and how much of it is being used. Knowing which applications are resident where, how much compute, memory, and storage the servers have, the network zones, network connections, the SANs and how they are used, which COTS products are installed where, etc. are all needed for proper resource capacity management. With a CMDB the capacity utilization information that is collected is made useful by being able to view it in the context of CI relationships that a CMDB provides. The Capacity Database (CDB) loses its value without an associated CMDB that enables meaningful analysis and reporting.
Likewise for Service Capacity Management; without a CMDB we would not know the IT Infrastructure and all its sundry components that support the IT Services that we sell to our clients. Just as with Change Management, Service Capacity Management would literally be impossible to do without an accurate CMDB as its undercarriage.
Business Capacity Management is also far less effective without a CMDB. The reality is that most business users often don’t even know what IT hosts for them or in some cases which IT group. A good CMDB with good reporting can help educate them rather nicely.
An Availability Management Database (AMDB) without an associated CMDB, just as with the CDB, is somewhat useless without the CMDB that allows availability reporting at meaningful levels such as database services, applications, or IT Services. No matter how much availability data you collect, without a CMDB to tie it all together, you cannot easily obtain much real value from it.
IT Service Continuity is another process that is heavily reliant on an accurate CMDB. With one, doing a BIA of Vital Business Functions (VBF) is infinitely easier when an accurate CMDB is present – it literally becomes a push-button exercise of generating an impact analysis report using the VBF as the initiating CI. It also becomes, when combined with Change and Release Management, the mechanism by which the IT Service Continuity plan is kept current and relevant.
Within IT Service Management the operative word is “Service”. Which services do we offer, how are they configured, what are their support hours, which parts of the IT Infrastructure do they rely on, etc.? The IT Service Catalogue as well as the key attributes of signed Service Level Agreements (service level targets, support hours, capacity requirements, and so on) are critical pieces of knowledge that need to be reflected in the CMDB such that proper Service Level Reporting can occur. Of course Service Level Reporting is also tied to other service management data sources such as the AMDB, the CDB, etc. via the CMDB.
The interaction with the business customer and the ability of IT to move from a Technology and Cost discussion to one of Service and Value is also directly supported by the CMDB where the relationships between the IT Services the client has purchased or pays for and how they are supported by the IT Infrastructure components have been fully mapped out.
IT must also manage its vendors that provide hardware and software maintenance for the COTS portions of the IT Infrastructure. A simple Contracts CI within the CMDB can allow IT to associate which Underpinning Contract supports which hardware or software as well as the basic terms of that support such as support hours, response times, etc. Likewise, IT can also use the CMDB to document its own internal OLA’s key terms just as they can do for Underpinning Contracts.
If an organization wants to be become ISO 20000 compliant, along with the all the other mandatory requirements, the presence of an accurate CMDB can be a significant enabler in demonstrating that management has control over its IT Service Management processes as the remaining service management areas will be able use its CI relationships augmented by selected reporting to demonstrate many ISO 20000 mandatory requirements. For example, one of the mandatory ISO 20000 criteria for certification under Service Reporting is that “Service reporting shall include…performance against service level targets”. As noted above, SLM and hence service level reporting is directly supported by the CMDB.
During the course of normal activities within IT operations and support, the CMDB is an invaluable tool for making everyday decisions as well as supporting operational inquiries. For example, knowing where excess compute capacity may exist can be done if you choose to track it in the CMDB via the use of a single attribute associated to a set of carefully chosen CI’s such as the server (whether virtual or physical) and the application.
Another little known fact is that a well designed and maintained CMDB will likely contain more logical CI’s than physical ones, which will not only signal that your IT Service Management processes and practices are becoming more mature, but also that it has moved from being simply a database full of data and perhaps even information but also a source of knowledge about your organization.
As we have seen a CMDB does indeed run through IT Service Management. In a few paragraphs we have established just how dependent not only are all other aspects of service management are dependent on the CMDB but also daily operations, how it helps facilitate management of maintenance contracts, and even how it can help with validating mandatory requirements for an ISO 20000 certification.