(Spoiler: shortly after the sun explodes.)
Every enterprise eventually asks the question:
“When will the CMDB be done?”
Usually, right after spending a fortune on tooling, consultants, workshops, governance boards, and enough PowerPoint slides to bend space-time.
It’s a fair question.
After all:
- a house gets built;
- payroll goes live;
- The coffee machine gets installed, and productivity mysteriously drops.
So surely the CMDB—your “single source of truth”—must one day also be complete.
The uncomfortable answer:
No.
A CMDB is never “done.”
It can be valuable.
It can be trusted.
It can be governed.
It can be automated.
It can even be loved.
But done?
No.
Because a CMDB is not a project deliverable.
It is a living operational model of how business value is delivered.
And if your business keeps changing, your CMDB must keep changing with it.
The Wrong Goal: Register Everything
Many organizations begin their CMDB journey with optimism:
“We’ll discover everything.”
That usually ends with:
- millions of CIs;
- duplicate records;
- broken relationships;
- stale ownership;
- dashboards no one trusts.
A CMDB should not be an inventory dump.
A CMDB should contain the operational chain of value delivery.
In a modern Zero-Touch CMDB, aligned to CSDM 5, that chain should look something like this:
Business Capability / Process
↓
Business Application / Business Service
↓
Service Offering
↓
Service Instance (environment/region / tenant specific)
↓
Runtime / Technical Components
↓
Hosting Components
↓
Platform
↓
Location / Vendor / Region
That model answers the only questions operations really care about:
- What do we provide?
- How is it delivered?
- What supports it?
- Who owns it?
- What breaks if it fails?
Everything else is just collecting Pokémon.
Why Service Instance Is the Pivot
In many CMDBs, the business-to-technology chain breaks between logical services and technical infrastructure.
That’s where Service Instances matter.
A Service Instance connects:
business meaning
to
technical reality
Example:
Online MyCompany Portal – PROD – NL
can dynamically contain:
- application servers;
- databases;
- certificates;
- load balancers;
- APIs;
- Kubernetes workloads;
- cloud services.
This makes impact analysis and operational automation possible.
Without Service Instances, most CMDBs become glorified server registries.
Why “Zero-Touch” Matters
The moment humans manually maintain runtime infrastructure…
…the CMDB starts dying.
Humans forget.
Humans are busy.
Humans rename “Production” to “Prod-Final-v7”.
A sustainable CMDB should be fed automatically through:
- Discovery
- Service Mapping
- Cloud APIs
- Endpoint Agents
- Vulnerability scanners
- Certificate scanners
- Procurement systems
- Identity systems
- DevOps pipelines
…and reconciled via clear governance and authoritative sources.
That is how you move toward a:
Zero-Touch CMDB
Or at least:
minimum-human-touch-before-it-becomes-fiction.
What Determines CMDB Success?
A CMDB is not successful because it is large.
It is successful because it is useful.
Here are the factors that matter:
1. Fitness for Purpose
Why does it exist?
- Incident Management
- Change Risk Analysis
- Vulnerability Response
- BCM / DR
- Compliance
- Service Mapping
- Audit Evidence
Without use cases, it’s decorative metadata.
2. Trustworthiness of Data
- completeness
- accuracy
- timeliness
- ownership
If they don’t trust it, they won’t use it.
3. Coverage of the Right Things
Focus on stable, operationally relevant entities.
4. Relationships that Matter
A CMDB without relationships is just an expensive spreadsheet.
5. Automation Level
The closer you get to zero-touch, the more sustainable the CMDB becomes.
6. Governance and Reconciliation
Automation without governance creates automated chaos.
7. Adoption
A perfect CMDB nobody uses is worthless.
Common CMDB Pitfalls
Even with the best intentions, many CMDB initiatives derail.
1. Treating the CMDB as an Inventory Dump The goal is not completeness. The goal is relevance.
2. Manual Maintenance Ask humans to maintain runtime infrastructure manually… and watch the CMDB die.
3. No Clear Ownership If everyone owns it, nobody owns it.
4. Confusing Design-Time with Run-Time The CMDB should reflect IST, not SOLL.
5. Ignoring Relationships Without them: no impact analysis, no blast radius, no intelligence.
6. Bad Reconciliation Rules Without proper IRE policies: duplicates, conflicts, and chaos.
7. Modeling for the Tool Instead of the Business Your CMDB should reflect enterprise reality.
8. Measuring Success by Record Count Volume is not maturity. Usefulness is.
9. Lack of Adoption If nobody uses it, it’s an expensive decoration.
10. Overengineering the Model Pragmatism beats perfection.
So… When Is It “Done”?
A CMDB is “done” in the same way:
- security is done;
- architecture is done;
- Digital transformation is done.
Meaning: never.
You can achieve milestones:
- ✔ Discovery complete
- ✔ Service Mapping operational
- ✔ Audit-ready
- ✔ Zero-touch for selected domains
But the CMDB itself remains alive.
Conclusion
The goal should never be:
“Finish the CMDB.”
The goal should be:
“Make the CMDB continuously valuable.”
A successful CMDB is:
- accurate enough to trust;
- scoped enough to manage;
- automated enough to sustain;
- governed enough to control;
- adopted enough to matter.
So next time someone asks:
“When will the CMDB be done?”
Answer:
“Right after the organization stops changing.”
BUT THERE IS LIGHT AT THE END OF THE TUNNEL!!!
Most CMDB’s are established as part of a bigger ServiceNow Implementation Program. Often, the “CMDB” is defined as a set of Program Deliverables. As long as it is understood that providing those deliverables alone does not provide a continuous business outcome, then you could say you are done when the following acceptance criteria are met:
- The CMDB contains relevant content that is properly maintained, preferably automated.
- The CMDB Items are all (in) directly related to an Instance of a Service that is offered.
- The Services that are offered and consumed are owned/supported, and their delivery commitments and their subscribers are defined
- Processes have been implemented, and role players have been appointed and trained to fulfill their duties.
- All incidents, problems, and changes are being related to affected services, offerings, instances, and configuration items.
- Undetectable items are federated from trusted sources or are maintained (as physical assets and/or logical portfolio items)
The CMDB should be able to provide (automated) responses to questions such as:
- Who and what may be impacted if (something in/on) this item breaks?
- If this subscriber faces issues with that offering, what could be broken?
- If this (version of this) product is no longer supported, how much of what do we need to replace/upgrade and who is impacted?
- Which others’ solutions interface with my solutions?
- Who should address this detected vulnerability on that item?
- How many licenses should I pay for?
