Configuration Management Database

A configuration item (CI) is any component you must manage to deliver a service. Examples include a server, a workstation, a network switch, an application, a database schema, a license, a contract, or the documentation that describes how these fit together. Each CI carries attributes such as owner, location, version, serial number, and lifecycle status. Most designs also keep a history of its states over time.

What sets a CMDB apart is that relationships carry the same weight as the items themselves. A CI record says what a component is. A relationship says that the payroll application runs on a particular cluster, that the cluster depends on a storage array, and that a branch office connects through a specific router. Read together, these links form a dependency graph. It answers questions a flat list cannot: if this device fails, which services stop, and who is affected?

In IT service management, the CMDB is the reference point that other processes write to and read from. Incident management links each incident to the CIs involved. This speeds up triage and makes recurring faults visible on the same component. Problem management analyzes those clusters to find root causes. Change management is the main writer. An approved change records which CIs it will touch, and the CMDB should reflect the new state once the change is complete.

The dependency graph turns records into decisions. Before a change is approved, its blast radius can be estimated by following relationships outward from the affected CIs. After an incident, the same traversal shows what to check for side effects. A CMDB consulted only during audits delivers a fraction of this value.

The two are related, but they answer different questions. An asset inventory, a core part of IT asset management, shows what the organization owns, where each asset is, and who is responsible for it. Its main users are finance, procurement, and facilities. A CMDB shows how components relate to each other and what a change to one of them affects. Its users are the incident, problem, and change teams.

In practice, the boundary is gradual. Many organizations start with a plain inventory and add relationships as their service management processes mature. A simple test applies: a repository where nothing links to anything else is an inventory with extra fields, whatever it is called.

Most CMDBs combine automated discovery with manual record keeping. Discovery uses agent-based collection, network scanning, and integrations with cloud and directory platforms. It finds what actually exists and catches drift between the recorded state and the real one. Contracts, service definitions, and other items that cannot be scanned are entered and maintained by hand.

When several tools each hold part of the truth, the CMDB federates or reconciles them. One source is designated as authoritative for each attribute type, and conflicts are resolved by rule, not by argument. Accuracy is a process outcome, not a one-time load. Without a named owner, it decays quickly.

In Anexet Inventory, each workstation card lists the devices and installed applications it holds, with device type, manufacturer, version, and installation date. Records like these are the raw material a CMDB uses to build its configuration items.

1 / 2

• 
• 

A common failure pattern follows a predictable path. The initial scope covers everything at once, so the project drowns in data quality work before delivering anything. Records get updated only when someone remembers. Over time, the database no longer matches reality, and staff stop trusting it. At that point it is technically alive and practically dead. The practices below separate the deployments that survive from the rest.

A CMDB is reference data, not a collector. It rarely observes the environment itself. Instead, it aggregates what discovery, monitoring, and management tools report, and in return it enriches those tools. Monitoring alerts gain context about what a host is and which service it serves. Security investigations start from a known map of what should exist. Recovery planning knows which components to restore, and in what order.

Its limits follow from the same design. A CMDB does not detect intrusions, control devices, or replace endpoint visibility. It tells the organization what its environment is supposed to look like, so other controls can interpret what they see. Controls such as data loss prevention act where data actually moves, as the table shows.

Start with the services whose outage would cost the most, and model the components they depend on. Keeping the model close to reality is the core discipline of configuration management, so expand only after an accuracy audit passes.