In short:
- A CMDB records configuration items and, above all, the dependency relationships linking them.
- Its primary use is impact analysis, before a change or during a major incident.
- An inventory lists assets, a CMDB adds dependencies: they are two different objects.
- Manual population always drifts: automated collection is the only sustainable option.
What a CMDB actually contains
A CMDB, for Configuration Management Database, records the configuration items of an information system: servers, workstations, applications, services, contracts. But the list is not the point. What separates a CMDB from a spreadsheet is the relationships between those items: which server hosts which database, which database feeds which application, which application delivers which business service.
The question it must answer
“If I shut down this server tonight, who notices tomorrow morning.” A CMDB that cannot answer that question has no operational use, however many rows it holds.
Inventory and CMDB are not the same thing
| Object | Contents | Question answered |
|---|---|---|
| Inventory | Assets, technical characteristics, location, owner | What do I own and where |
| CMDB | Configuration items and their dependencies | What breaks if I touch this |
| Asset management | Financial lifecycle, contracts, licences, depreciation | What does it cost and until when |
The three overlap and often live in the same tool, which keeps the confusion alive. The practical starting point remains the inventory, fed by the collection methods covered in our article on automated IT inventory.
Why CMDBs drift
- Initial scope is too broad, and nobody keeps it current
- Relationships are captured once and never revisited
- No change process makes updating the database a condition of closure
- The tool does not distinguish automatically discovered data from manually entered data
That last point is decisive. Without source tagging, a manual correction is overwritten at the next collection run, or conversely blocks automatic discovery for good.
A sustainable population method
- Limit scope to critical services and what carries them, even if that covers less than half the estate
- Automate discovery of technical items, and reserve manual entry for business relationships
- Wire updates into change management, so no approved change leaves the database behind
The third point assumes an existing change management practice, therefore an ITSM foundation already in place. It is also what makes the CMDB usable in problem management, where root cause analysis relies on dependencies to trace a symptom back to its origin.
Frequently asked questions
What is a CMDB and what is it for?
A CMDB, or configuration management database, records the configuration items of an information system and above all the relationships linking them: which server carries which application, which application serves which business service. Its main use is assessing the impact of an incident or a change before acting. Its value rests entirely on freshness: a manually maintained CMDB drifts within months and becomes more dangerous than useful, since decisions then rest on a false map.
What is the difference between an inventory and a CMDB?
An inventory lists assets and their characteristics. A CMDB adds the dependency relationships between those items, which is what makes impact questions answerable.
Should everything go into the CMDB?
No. Scope should be limited to items whose failure or modification affects a service. An exhaustive CMDB is unmanageable and goes stale faster than it can be populated.