CMDB

Definition of CMDB

CMDB stands for Configuration Management Database. It is a centralised repository describing all the configuration items (CIs) of an information system and the relationships between them.

The concept originates from the ITIL framework (Information Technology Infrastructure Library), first published in the 1980s by the UK's CCTA agency, later taken over by AXELOS. ITIL defines the CMDB as the central component of the Service Asset and Configuration Management process, one of the processes of the Service Transition phase.

What does a CMDB contain?

A CMDB lists configuration items, which can be physical or logical assets. Physical assets include servers, workstations, network equipment and IoT sensors. Logical assets include applications, business services, databases, virtual machines, containers and Kubernetes namespaces.

Each CI carries attributes: unique ID, name, type, owner, environment (production, staging, development), criticality, status (live, maintenance, retired), version, acquisition date, attached support contract.

The added value of a CMDB lies not just in the list of assets, but in the modelling of relationships between them: which app runs on which server, which business service depends on which app, which data flow circulates between which components. These relationships are what makes impact analysis possible during an incident or change.

What is the difference between a CMDB and an inventory?

Confusion between CMDB and inventory is common. The distinction is about modelling depth and purpose.

An inventory is a flat list of assets: how many servers you have, in which datacenters, on which OS version. Useful for budget management, support contract tracking or license compliance. But an inventory says nothing about how assets interact.

A CMDB adds the relationships: this server hosts these three apps, consumed by this HR service, itself critical to the payroll process. This modelling makes the CMDB usable for impact analysis, change management, business continuity planning and regulatory compliance (notably NIS2 and ISO 27001).

Why legacy CMDBs often fail

The idea of an exhaustive, up-to-date CMDB has been appealing for thirty years, but the failure rate of CMDB projects remains high. Causes are structural.

First cause: manual maintenance. A CMDB fed by hand by operations teams quickly drifts towards obsolescence. Daily infrastructure changes (cloud provisioning, CI/CD deployments, updates) saturate any human entry capacity.

Second cause: scope too broad. Trying to inventory every asset down to network cables drowns useful information and demobilises teams. Modern CMDBs adopt a federation approach: dynamically pull CIs from source-of-truth tools (application CMDB from monitoring, infrastructure CMDB from IaC, application CMDB from source code).

Third cause: no clear business use. A CMDB that only serves itself is never maintained. Linking the CMDB to concrete use cases — incident impact analysis, change simulation, compliance audit — is what justifies its upkeep.

CMDB and IT mapping: the new generation

Since the 2020s, the concept of CMDB tends to merge with dynamic application mapping. Modern platforms no longer require teams to manually feed a database: they plug into existing sources of truth (legacy CMDBs, monitoring such as Datadog or Prometheus, IaC such as Terraform, cloud configurations such as AWS Config) and reconstruct the application map continuously.

This approach is what NIS2 and ISO 27001 now value: compliance no longer requires a frozen exhaustive CMDB, but a living map able to prove at any time the state of the IT system, its critical dependencies and its risk exposure.