A CMDB Can Be Done But Why Would You Want ToITILs configuration management database should never be fully realized because its just not worth it, writes ITSM Watch columnist Rob England.
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.
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.
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 wont. 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 failingthey think technology solves problems, that solutions are made with technology. They arent. 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 doesnt 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 worlds ITIL shops dont 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 years hot topic. Dont fall for the hype.