A CMDB, or configuration management database, records IT configuration items and — more importantly — the relationships between them. It is what lets you answer, before approving a change, which services go down if that server is taken offline. Without those relationships it is an inventory, not a CMDB.
The practical value of a CMDB is not the number of records it contains. It is the ability to connect a business service to the applications, servers, databases, network links, suppliers and people it depends on. That context supports change impact analysis, incident prioritization and faster diagnosis. A small, trusted model of critical services is more useful than a complete list of devices that nobody can use to make a decision.
This post explains the difference between an inventory and a CMDB, what is worth recording, how to start without a six-month project and why so many CMDBs end up abandoned. It sits inside the wider picture of IT service management, where the CMDB supplies the context that the service desk needs to prioritize and resolve work.
An inventory is not a CMDB: the difference is in the relationships
An IT asset inventory answers what the organization owns or operates: device, serial number, assigned user, location, warranty and lifecycle status. A CMDB answers how those items work together to deliver a service. Both are important, but they solve different questions. Inventory is an input to configuration management; it is not a substitute for relationship mapping.
| Question | IT asset inventory | CMDB |
|---|---|---|
| What exists? | Primary purpose | Includes configuration items in scope |
| Who owns or uses it? | Tracks assignment and lifecycle | May link owner or support group to a service |
| What depends on it? | Usually not modeled | Core purpose: records service and technical dependencies |
| What happens if it changes? | Limited answer | Supports impact analysis before change approval |
| What should be prioritized during an incident? | Uses asset attributes | Uses service criticality and dependency context |
Consider an online customer portal. The service depends on an application, an authentication component, a database, two servers and a network link. If the database server is taken offline, the CMDB should show the affected application and service. If it cannot, the records may still be useful inventory data, but they do not yet provide configuration management context.
What to record, and what is not worth recording
Start with information that changes a decision. For each critical service, record the service owner, support group, application, essential infrastructure, external dependency and the relationships among them. Add attributes such as criticality, environment and lifecycle status only when they support routing, impact assessment, reporting or control.
Avoid recording every possible technical attribute just because it is available. A field that has no owner, no update source and no operational use will become stale. The right data model is deliberately smaller than the data that discovery tools can collect. Automated discovery can supply inventory facts; the service model still requires ownership and rules that explain which relationships matter.
A useful test before adding any field or relationship is to ask which decision it will change. If nobody can name a change approval, an incident priority or a report that depends on it, the field is probably not worth maintaining.
Starting without a six-month project
Choose one business-critical service and draw its dependency tree: service, application, server and network link. Confirm the model with the service owner and the technical teams. Then connect the model to one operational use case, such as change approval or major incident triage. This narrow scope makes quality visible and creates a reason to maintain the records.
| Level | Example | Relationship |
|---|---|---|
| Business service | Customer portal | Delivered by the portal application |
| Application | Portal application | Runs on application server |
| Server | Application server | Connects to database server |
| Link | Primary network link | Supports access to the service |
Once the first service model supports a real decision, expand to the next critical service. OTRS can connect configuration items, tickets, changes and responsible groups so the CMDB becomes part of the ITSM workflow rather than a separate documentation project. This approach keeps the implementation measurable: teams can compare change assessment and incident response before and after relationship data is available.
The classic failure: a CMDB nobody updates
A CMDB fails when updating it is treated as a periodic cleanup task. By the time a quarterly review begins, changes have already altered the environment and people no longer remember every dependency. The database looks complete but cannot be trusted at the moment of impact analysis.
Maintenance must be part of the change process. A change that creates, removes or modifies a configuration item should include the required CMDB update before closure. Automated discovery can flag technical differences, while ownership rules determine who validates the service relationship. Quality metrics should focus on critical records: completeness, freshness, orphaned items and relationships used by active services.
This is also where frameworks such as ITIL 4 help: they describe service configuration management as a practice connected to change enablement and incident management, not as an isolated register. The CMDB earns its keep only when those practices consult it every day.
Aufiero Informática distributes OTRS by EasyVista and supports organizations that want to connect service management, configuration data and operational accountability.
Frequently asked questions about CMDBs
What does CMDB stand for?
Configuration management database: the record of IT configuration items and their relationships.
What is the difference between a CMDB and an IT asset inventory?
An inventory lists what exists; a CMDB records how items relate and which services depend on each one.
Do I need a CMDB to run a service desk?
Not to start, but without one, change impact analysis is guesswork.
How do you keep a CMDB current?
By tying updates to the change process and to automated discovery, never to a periodic manual task.
Where should we start?
With the business-critical services, not with a complete equipment inventory.
Recommended reading
- Help Desk vs Service Desk: Key Differences, Comparison Table and How to Choose
- What is ITSM, and where an IT team actually starts
- OTRS: service desk and ITSM platform
- ITIL 4 — PeopleCert
- ISO/IEC 20000-1
