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. 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.
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.
Let us consider another attribute of technical folk which is not a failing but a weakness if not controlled: the desire for correctness, completeness and perfection. It is hard for may IT people to accept that good enough is OK; that a few gaps can be lived with; that the world functions on imperfect information; that pragmatic considerations mean we have to stop at some point; that business is all about taking considered risks over known exposures; and about prioritising to make best use of limited resources.

I don’t for a moment deny that having a CMDB would be an excellent thing, would make processes better, and would be very cool. It is just that in most cases it is not cost effective and it is not the best use of funds. It would also be cool to hold all CAB meetings in a Lear jet.

Nobody trusts the CMDB anyway. Even after it is built, it is never perfect. Nobody can be as dumb as a computer can, so after a few howler mistakes, people go and check with the expert human: “The CMDB says this change will only impact Service A. Is that true?” There is no substitute for a CMDB called Sue, so why not get over it, and allocate a tiny fraction of the CMDB costs to make sure Sue is well paid and has an understudy or three.

One object in the ITIL environment that barely gets a mention in ITIL v2 and still does not get the priority it deserves in ITIL v3 is the Service Catalogue. The Service Catalogue is the centre of the ITIL universe, the hub around which it all revolves. Once we record what services are, their SLAs, and the applications, servers and networks that deliver them, then we have gone a long way towards satisfying most of the configuration data requirements of the majority of organisations.

So, start with a Service Catalogue, add an asset database, auto-discover your network, and if possible make this data linkable from the Service Desk tool. Many vendors already provided an integrated solution for all that. Most of you will never need to do any more towards CMDB. Settle for good enough so you can move on to something else.