Configuration Management Database: The New Kid on the ITIL Block

Actually, the concept of a CMDB should be thought of more as a set of federated databases that together make up the required information. That's because ITIL v3 defines a CMDB as "a database used to store configuration records throughout their life cycle. The configuration management system maintains one or more CMDBs, and each CMDB stores attributes of configuration items, and relationships with other configuration items." (A configuration item is any IT component, including software, hardware, documentation and staff.)

Forrester Research suggests a CMDB contain, at a bare minimum, the following elements:

• Discovery information about infrastructure components, such as servers, storage, desktops and other workstations, as well as relevant information about their nature and configuration
• Collected information about the location and configuration of applications, services and business processes
• Representations showing the links between the applications and services, and the infrastructure components needed to run them, which must be updated dynamically

Before we go any further, it must be said that creating a CMDB is no small task. For all but the smallest of organizations, creating a complete one is likely to be a mammoth project whose completion will be measured in years, if ever. But we'll come to that in a minute.

To create a CMDB, all kinds of problems must be overcome, from deciding who will lead the project (without the necessary seniority, any attempt to garner knowledge from different departments is likely to be seen simply as a nuisance and ignored) to working out how best to compile the necessary information (auto-discovery tools can be useful, but only up to a point — much of the information will have to be compiled and checked manually, and duplicate entries removed).

In fact, many people believe the cost of creating a complete CMDB is far too high to be worthwhile. "A CMDB can't be created sensibly within normal business constraints," says Rob England, a New Zealand based ITIL consultant. "ITIL is focused on maturity levels for processes, so you don't just do configuration management, you do it to a particular maturity level. Most companies need a maturity level of two or three, and at that level a CMDB is not economic."

In fact, England said, only a very few exceptional companies can justify creating a CMDB. And even these are unlikely to be able to justify one on the grounds of cost and economic benefit. More likely, they will be the sorts of organizations that require one as a condition of being in their chosen business.

"A good analogy is that of an outsourcer or hosting company. They have to build a secure bunker with biometric security measures and so on. Do they get a return on their investment in security? No, but if they didn't invest in these measures, then no one would do business with them," England said.

So is the concept of a CMDB dead in the water? Not necessarily, according to Forrester Research. It suggests a "just enough" top-down approach. Rather than trying to create a complete CMDB, organizations should start by choosing just two or three important IT services or applications, listing the 50 or 100 most important infrastructure components they require, and mapping the relationships between them. Forrester believes it is possible to do this in about six to nine weeks.

England sees a number of problems with this approach, although he agrees that it's the only sensible way to go. "Top-down is definitely the correct approach, but what you get is not a CMDB. ITIL defines a CMDB as a system that tracks all the configuration items under management, not just the most important ones."

Perhaps a more fundamental problem is what England terms the boundary problem: Where do you stop? Many, perhaps most, configuration items are linked to others, and particular applications or services do not use configuration items linked only to each other — they are also linked to configuration items that other applications or services use. In other words, if everything is ultimately linked to everything else, how do you choose which configuration items to include in your "just enough" CMDB and which ones to ignore? Include too many and the CMDB will be too expensive and may never be completed; include too few and the CMDB will not be worth anything at all.

Ultimately, the whole point of ITIL and the concept of CMDBs hinges on business considerations. No one embarks on ITIL-related projects for fun, and there must be a good, solid reason for implementing a CMDB. England concludes: "For 90 percent of companies, a CMDB fails the business case."

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment