A good CMDB is defined by the decisions it supports
Completeness is not the same as usefulness. A CMDB can contain millions of configuration items and still fail operational teams if ownership is unclear, relationships are wrong or different sources disagree without a reconciliation model.
Start with use cases
Define the decisions that service and technical teams need to make: impact analysis, incident routing, change risk, service ownership, monitoring correlation, vulnerability prioritisation, licence or asset governance. Those use cases should drive the data model.
Make ownership explicit
Every important data domain needs an accountable owner and a quality mechanism. Discovery can collect data, but it cannot decide what the organisation means by a service, who owns it or which source wins when records conflict.
Service mapping matters
Business value is created by relationships: which infrastructure supports which application, which application enables which service, who owns the service, and what customers or business processes depend on it.
Measure trust, not just volume
- Accuracy against authoritative sources.
- Completeness for defined operational use cases.
- Timeliness and stale-record controls.
- Relationship quality and orphan detection.
- Ownership and remediation performance.
BSMS Limited CMDB consultancy
We help organisations define configuration strategy, governance, data models, reconciliation, service mapping and adoption so the CMDB becomes an operational decision-support capability rather than a repository.