Your CMDB problem is ownership, not tooling

Every organization I have worked with that distrusts its CMDB has already bought the tooling. Discovery is running. Service mapping was configured at some point. There may even be a reconciliation strategy in a document somewhere.

And yet, when a major incident starts, nobody opens the CMDB to find out what depends on the failing component. They open a chat channel and ask who knows.

That is the real test, and tooling does not pass it on its own.

What discovery can and cannot do

Discovery is good at finding things that respond to probes and populating attributes about them. Within its scope, it is reliable and much better than manual entry.

What it cannot do:

• Tell you which business service a server supports, unless someone has modeled that relationship or the application tells it
• Decide whether two records that look similar are the same thing
• Know that a configuration item was decommissioned last Tuesday if nothing told it
• Determine who should be called when something is wrong

Those are all judgment calls requiring an accountable human. When no human is accountable, the CMDB degrades at exactly the rate your environment changes — which is faster every year.

The ownership gap, concretely

Here is the question that exposes the gap. Pick a configuration item class that matters — business services, say. Now ask: when a record in this class is wrong, whose performance review is affected?

In most organizations the answer is “the CMDB manager’s,” which is the wrong answer. The CMDB manager does not control application teams’ deployment practices, procurement’s asset recording, or whether a project team registered the service it built. Holding them accountable for data they cannot control guarantees the program plateaus.

The answer that works: accountability sits with the team that owns the thing being described. The application team owns its application records and their relationships. Infrastructure owns infrastructure CIs. Service owners own their service definitions. The platform team owns the model, the tooling and the measurement — not the accuracy of every record.

That reassignment is uncomfortable, which is why it is so often skipped in favor of another discovery project.

Making ownership real

Declaring ownership in a governance document changes nothing. Four things make it real.

Name owners on the record, not in a spreadsheet. If a CI class has no owner field populated, it has no owner. Populate it, and treat an unowned record in a critical class as a defect.

Measure accuracy by owner and publish it. A monthly scorecard per owning team: completeness of required attributes, relationship coverage, records not seen by discovery in 30 days, duplicates. Visible comparison between peer teams does more than escalation ever does.

Put CMDB updates inside processes people already run. If the only way to register a new service is a separate form nobody remembers, the data will be wrong. The request should come out of the deployment pipeline, the project closure checklist, or the change record — wherever the work already happens.

Give owners a way to fix things in under a minute. If correcting a wrong relationship requires a ticket to the platform team, owners will not do it. They will note it mentally and move on, and you will lose the correction.

Where CSDM helps, and where it is blamed unfairly

CSDM gets criticized for being heavy. In practice most of the pain I see comes from adopting it as a data model without adopting the decisions it implies.

CSDM asks you to distinguish a business service from a technology service from an application service, and to say which domain a record belongs to. Those distinctions are only useful if someone decides, for your organization, what each one means and who owns it. Teams that adopt the structure and skip the decisions end up with three overlapping record types and no clarity — then conclude the framework is the problem.

Adopt it in order: decide the service model and the ownership first, then configure the classes. Doing it the other way around produces a tidy-looking model that nobody trusts, which is where you started.

A reasonable first 90 days

If your CMDB is distrusted and you want to change that without a large program:

1. Measure where you are, by owner. Completeness, correctness, relationship integrity, discovery coverage, duplicates. Publish the baseline even though it is embarrassing. Especially because it is embarrassing.
2. Pick one class that matters. Business services, or whatever class your major-incident process actually needs. Fix that one properly rather than improving everything by 5%.
3. Assign and publish owners for it. On the record, with a named person.
4. Wire one upstream process. Make one existing process — change, deployment, project closure — responsible for keeping that class current.
5. Re-measure and show the delta. A single class moving from unreliable to trusted builds more support for the next phase than any roadmap presentation.

The uncomfortable part is that none of this requires new software, which means it cannot be delegated to a vendor. It requires someone with authority to assign accountability and then hold it. That is harder than a procurement cycle, and it is the only thing that works.