A CMDB Can Be Done But Why Would You Want To

OK, OK, quiet please. Put the tar and feathers down. Wait until we define our terms. If you call something you already have a CMDB, it can be done. If you take the first steps towards an ITIL CMDB and call it a CMDB, it can be done.

But, a CMDB fully implemented as it is defined in the ITIL v2 Service Delivery blue book or the ITIL v3 peas book (Service Transition) cannot be done within the normal business constraint of the return exceeding the investment required.

To meet the ITIL definition, a CMDB must contain all items controlled by change management, and it must contain all items that contribute to the end-to-end delivery of a service. It must contain the relationships between those items. It must be able to take snapshots or checkpoints of its entire state at a point in time, etc.

An asset database, no matter how full, is not a CMDB. It does not relate items. An auto-discovered database is not a CMDB. Application, system, service, owner, supplier and SLA are conceptual entities that cannot be auto-discovered or auto-related.

No ROI

To build a CMDB requires two enormous tasks that simply do not repay the investment for most organisations: they must be populated and they must be maintained.

Auto-discovery is a useful tool to assist in the initial population of a CMDB, but it only goes part of the way. There is a great deal of further work to capture all the information about assets that cannot be auto-discovered, and then to capture and relate all the conceptual objects as well.

Once we get to this point, the investment has only just begun. We require meticulous change management to protect the integrity of the CMDB data. This is a good investment. But we also need extensive manual work to keep the data related and audited. Auto-discovery assists with audit, but it does not assist with relating data to conceptual objects.

All of a CMDB is technically feasible. It is also technically feasible for me to walk on the moon. But I do not have the resources to achieve it. Bill Gates does, but he won’t. He spends his money on eliminating disease. CMDB is beyond the means of most organisations. For those who can afford it, it is seldom the best use of funds.

To embark on the journey towards a CMDB is a good thing for any organisation. It is useful to capture our services, key applications, and main servers, and link them. This is enough for organisations that want to achieve maturity II or III in their Service Support processes. This gets us into the foothills of the CMDB Himalayas on a challenging but achievable trek.

For the NASAs and IBMs of the world who need to get to maturity V, this is not enough. They must mount a complex, risky and expensive expedition to scale the heights towards the peak of true CMDB implementation. Some of them will make it, and boy will it cost all of them to try.

Technical people have a common failing—they think technology solves problems, that solutions are made with technology. They aren’t. IT solutions are made up of people, process and technology. The successful ones change the people, focus on process, and then select the technology to enable or improve the outcome. ITIL v2 is very good in this regard. It focuses almost entirely on cultural change and process.

The only lapse into technical geek-speak is CMDB and it doesn’t carry it off at all well. ITIL v3 seems to have yielded to vendor pressure and talks a lot more about technology as an enabler of process, but it still does not rely on technology as a solution except, once again, in CMDB. Good process works without a CMDB (over 90% of the world’s ITIL shops don’t have one). A CMDB will not fix bad process.

Vendors, Hype & Fads

Speaking of vendor pressure, the IT software industry runs on fads. The vendors and their parasites, the analysts, find something new every few years to talk up into the latest must-have “Big Thing”. CMDB is this year’s hot topic. Don’t fall for the hype.