Why CMDB projects fail by focusing on the tool

The Configuration Management Database (CMDB) has been part of the methodical foundation of IT Service Management since the early versions of ITIL. On paper, its task sounds straightforward: a CMDB records which Configuration Items exist and how they relate to one another.

In everyday practice, exactly this quickly becomes demanding. IT landscapes undergo continuous change. Applications are expanded, platforms are replaced, cloud resources are provisioned, and services are redesigned. At the same time, relevant information is rarely kept in one place and is scattered across other tools and systems.

Consequently, while the required information is available, it is not reliable enough for decisions in day-to-day operations. Especially when changes occur, there is a lack of a dependable overview of which services or components might be affected.

Therefore, before selecting a solution, it should be clarified what purpose the CMDB is intended to fulfil. Only when it is established whether it should support change impact assessments, ITOM, security, procurement, or other processes can a decision be made on how it should be structured and operated. This article marks the launch of a planned blog series on CMDB best practices. First and foremost, the focus is on the question of why the specific purpose of a CMDB should be clarified before selecting a tool.

Our experience of CMDB projects shows that many initiatives are treated as purely tool-related questions too soon. A CMDB only becomes sustainable when its purpose in everyday operations is clear. This has led us to identify five key principles.

From our experience of working on projects, we are all too familiar with this situation. As soon as a CMDB initiative begins, the first question that arises is often which tool should be deployed. Is an open-source solution sufficient? Do we need a large enterprise platform? Or might the existing office file be adequate after all?

While these questions are understandable, they distract from the essentials at the outset. Before discussing a solution, it is important to establish what the CMDB is intended to achieve.

Typical objectives can include:

The structure of the CMDB depends on the objective. For example, a CMDB used for change impact assessments requires different relationships between configuration items than a CMDB whose primary purpose is to make asset information usable. Therefore, the objectives should be documented or visualised before defining the tool, data model and interfaces.

CMDB projects usually do not start from scratch, as relevant information is already available in other systems. These include ITSM tools, monitoring systems, asset management, purchasing data, security systems, cloud platforms, and manually maintained lists.

Accordingly, existing information must be prepared in such a way that it can be used for the CMDB and its associated processes.

Core concepts here are federation, population, and interfaces. With population, data from other systems is imported into the CMDB. In contrast, with federation, the information remains in its source systems but can be utilised within the CMDB context. Interfaces connect the relevant systems and prevent information from remaining isolated. These concepts should be considered at an early stage, before the structure and tool selection are finalised. Otherwise, a CMDB quickly emerges that duplicates data or fails to integrate important sources properly.

The question of the suitable tool can only be answered significantly better once requirements and data sources have been clarified. There is no single correct path. Ultimately, the most important thing is which solution best supports the previously defined objectives.

Fundamentally, none of these options is inherently right or wrong. Depending on the situation, the right choice could be a dedicated solution, an existing platform, a managed service or a simple office tool. The deciding factor is whether the objectives from the previous steps are fulfilled. Therefore, the tool selection should not be based on the range of functions, but on suitability. Anything that does not contribute to achieving the objective quickly creates effort without offering any clear benefit.

A CMDB cannot resolve organisational ambiguities. If it is unclear who is responsible for maintaining which information and how it is used, acceptance of the CMDB will quickly decline.

Therefore, the participating departments must understand the role of the CMDB in their respective processes. For example, change managers require different information to asset managers or security officers. Everyone must understand their contribution to data quality.

Training sessions are important for this, but they are not enough. The tasks must be embedded in the processes. It must be clearly regulated who creates Configuration Items, verifies relationships or corrects outdated data. CMDBs must not become an additional administrative burden whose benefit to everyday work remains unclear. They must be operated in such a way that the information they contain is reliable enough for the defined objectives.

Introducing a Configuration Management Database does not mean that the project is finished. Requirements change, and the CMDB must be able to respond to these changes.

However, it must not lose sight of its core purpose: the configuration items and their relationships must remain traceable. Everything else should serve this defined purpose. If the CMDB becomes too complex, its usability decreases. If it remains too superficial, however, it is of little help in everyday operations. Crucially, it must remain adaptable without losing its practical benefit.

A CMDB creates value when it is not understood as a pure tool project. It must support concrete operational decisions in daily business and provide reliable information for this purpose.

The most important step therefore lies before the tool selection. First, the intended purpose of the CMDB must be clear. Subsequently, the structure and operation can be sensibly determined.

A good CMDB establishes meaningful connections and does not merely gather data.

A follow-up article is planned that will deal with Automatic Discovery. It will address the question of when discovered data becomes reliable CMDB data.