Clearing Up the Myths of CMDB

“You can’t achieve value from your investment in IT service management (ITSM) – ITIL processes, training and tools – if you haven’t got a fully functional integrated, single-source of truth Configuration Management Database (CMDB).” This has long been trumpeted out at meetings and events, generally (although not always) by people who have no idea what this is or how to achieve it.

If there’s one element that has been used (deliberately or otherwise) to slow down and scupper ITSM projects then it’s been this – the impenetrable world of CMDB, or Configuration Management System (CMS), which is part of Service Asset and Configuration Management (SACM).

CMDB can be a convenient way of grinding a project to a halt, often by technicians trying to achieve the unachievable with unnecessarily high expectations regarding quality and levels of detail (which cannot be easily defined and maintained). What better way is there to ensure that nothing will change by spending time on an impossible task that no one understands?! Often it is not clear to organizations what the point of Configuration Management (CM) is, and this therefore can lead to failed expectations on all sides. Certainly it is a topic that most agree is important and useful (somehow), but few actually have a clear vision of what CMDB looks like, what is needed to make it work and how to get there. Owing to this, several ‘myths’ of CMDB have evolved over the years, including:

• As a CMDB is seen as a central pillar of IT service management (ITSM), it will somehow magically fix all other issues related to ITSM.
• A CMDB must include all IT assets/components linked together in one single database.
• CMDB has to be a ‘big’ project.
• A CMDB needs to be built by technical people.

Here’s some simple points of advice to clear up these myths and fantasies (plus others):

1. Configuration Management is a way of mapping and storing information on the IT landscape – to support risk assessment, change management, fault/incident diagnosis, service design and service level management, financial and asset management, capacity, etc. In essence, it is an integral underpinning element for most ITSM processes. However this doesn’t mean that CM will fix all other ITSM issues – if it’s not applied at the right level then it can actually do the opposite.
2. Defining, building, and mandating a CMDB requires thought and ongoing effort. However, it’s debatable whether this is actually a process in itself, or simply an element of it (i.e. the CM element) that is required in all other processes. This is a key point and often the cause of misunderstanding and failure, as organisations embark on CM projects without any clarity about what it is trying to achieve and deliver.
3. The classic definition of CM is “to provide a logical model of the infrastructure.” The objective of CM, as stated in Service Transition, is “to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.” However, every organisation that embarks on CM should be transparently clear on what is expected from CM, in what form, and to what level of detail – otherwise there will be very little chance of success.
4. The single database idea that sees all Configuration Items (CIs) and service components in one single repository – hardware, software, applications – does NOT exist. There are few, if any, organisations where this works, i.e. where there is one single, large central database containing all the CI information linked together. IT inventory and application metadata are different entities and we need to recognize this. Also the logistics of a single database are often impossible. So we need to think of the ‘CMS’ as a federation rather than a unitary body.
5. Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). Implementation of the CMDB has been interpreted as meaning “one huge data repository”. There is no need for this, your CMDB should federate and not replicate, a key distinction.
6. It’s important to be clear on the level of CI that you store and maintain. There’s no need to identify every conceivable CI you can think of, plus you will not be able to capture all the data at once. You probably won’t ever be able to have the database 100% accurate all the time – nobody does. So be clear on what is good enough. Sometimes this is challenging for more technical people and that’s why it’s important to be clear on the business outcomes that are needed from this.
7. If you need to have a CM owner, then it’s probably best to give this responsibility to someone with more of a business focus than technical, as technical people may have a different internal IT focus on what is needed, which may not fit with business goals. Clearly there is a strong technical element in the delivery of CM, but if technical focus is the driver it can lead to issues, such as waste of time and resources.
8. CM Is a fundamental ‘under the hood’ activity. Under our streets and cities are cables and pipes and other infrastructure that we need in order to keep our society functioning. There are different authorities and utilities that keep maps of these cables/pipes/infrastructure, so that these systems can be maintained. However there’s no need for most citizens to see these records and the process of mapping and maintaining them is not a separate activity for these companies, rather it’s just an essential part of what they do. CM is similar. We don’t need to make it something separate with its own value set, or try to turn it into a process that it doesn’t need to be.
9. CMDB isn’t overly complicated – it’s simpler than it seems. We tend to over-engineer it when really all it needs is just to provide some helpful information – nothing more complicated than that.

What Should You Watch Out For?

Avoid the common pitfalls of CMDB by watching out for the following:

• A lack of shared understanding of the purpose of the CMDB; it’s not a panacea.
• Making the goal of CM too narrowly defined – don’t make it too technical or operationally focused.
• Inputting poor quality data – this can invalidate CM as a basis for making good decisions.
• Letting your CMDB become out of date – it must be kept up-to-date at an appropriate level to maintain its value.
• Unclear CM goals – this can damage your attempts to gain funding and approval as it can be difficult to justify the expense in isolation. Be sure to clearly define your CM goals.

Ultimately the CM concept can be very difficult to define and clarify to management and people both in and beyond IT. The question often asked is ‘what’s the point?’ This is a good and difficult question.

It may be better to be honest and say it’s simply a fundamental requirement for ITSM, rather than trying to separate it out as a distinct activity with its own value proposition.

The bottom line is that you just need to have accurate and relevant information on hand to make decisions in change and release management, to support analysis and diagnosis in incident and problem management.

No mythology is needed. CM is a tool to support other aspects of service management, which requires clarity, simplicity, and business focus in order to keep it relevant and useful. If it starts to become a ‘mythological monster’ that no one understands and that is eating up loads of resources, then it’s time to stop and review.

Image credit

Like this article? You may also like: How Long Should an ITSM Project Take?.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.