Why CMDB Fails and How to Build a Sustainable Configuration Management Database

CMDB (Configuration Management Database) stores all relevant information about an organization’s IT service components and their relationships, originating from ITIL V3’s Service Asset and Configuration Management.

It is the core of configuration management and the foundation of automated operations, providing essential data for various tools and influencing system connectivity and data consistency.

Key terminology: CI (Configuration Item) such as servers, routers, MySQL; CI model (a relational table); CI attributes (fields like IP, hostname, CPU); attribute types (string, integer, etc.); CI instance (a concrete resource, e.g., mysql‑node1).

Many CMDB projects are labeled as failures because they become static: they rely on manual maintenance, leading to inaccurate data despite automated collection attempts.

Dynamic CMDBs integrate with monitoring and job systems, but they can also lose relevance if relationship designs are flawed, such as using ambiguous relations like "runs on", "placed in", "depends on", "connected to", or "belongs to" without clear semantics.

The article introduces the first‑principles approach: instead of iterating on existing solutions, rethink CMDB from its essence, using physics‑style reasoning to uncover fundamental requirements.

Relationship design: Separate relationships into parent‑child (strong dependency, e.g., VM’s parent is a physical host) and connection (weak or associative links, e.g., a switch and an engineer). Apply tags to connection relationships for quick filtering.

Introduce the concept of virtual CI to handle resources that can run on multiple underlying hosts, allowing a virtual "host" CI to abstract physical, virtual, container, or cloud instances.

CI attribute classification: Ordinary attributes – manually entered or automatically collected static data. Relationship attributes – express parent‑child, connection, or no‑relationship links. Dynamic attributes – continuously updated by external systems (e.g., runtime status).

To build a lasting CMDB, adopt the 3C method:

Core: Establish a complete, automatically collected, regularly validated static CMDB.

Connection: Consume CMDB data across automation toolchains, not just for search.

Closed‑Loop: Ensure end‑to‑end lifecycle management and feedback loops to other systems.

Images illustrating concepts are embedded throughout the original article:

The article concludes with a promotion for a live training session on automated operations knowledge, indicating the practical relevance of the discussed concepts.