Discovery goes live. The schedules run green, class counts climb, and the CMDB dashboard finally looks like the one in the demo. Six months later, someone tries to use it for a change impact assessment and quietly goes back to asking a colleague instead.
This is not a failure of Discovery. It is what happens when a CMDB is treated as a project with a go-live date rather than a dataset with an owner. The decay is predictable, and so is the prevention.
The three ways it actually decays
1. Duplicates arrive through the side doors
Discovery is rarely the only thing writing to the CMDB. Import sets, an integration from the HR system, a spreadsheet load during a migration, an ITSM ticket that creates a CI on demand — each one is a separate door into the same table.
Discovery gets identification right because it uses the Identification and Reconciliation Engine properly. The other doors frequently do not. An import that matches on name alone will happily create a second server record because someone typed the hostname in uppercase. Now you have two CIs, each with half the relationships.
The tell is a CI count that grows faster than your estate does. If you commissioned forty servers last quarter and the CMDB gained four hundred CIs, something is creating rather than updating.
2. Reconciliation rules that nobody set
The Reconciliation part of IRE decides which data source is allowed to overwrite which attribute. If you never configured it, the answer is effectively "whichever wrote last".
That produces the most corrosive failure mode of all, because the data is not obviously wrong. The operating_system field is populated. It just happens to reflect a stale spreadsheet import from March rather than last night's Discovery scan. Nobody notices, because nothing looks broken. Trust erodes quietly, one wrong answer at a time.
3. Relationships that were never maintained
Class data — what exists — degrades slowly. Relationship data — how things connect — degrades fast, because it changes every time anything is deployed, migrated or decommissioned.
Discovery maintains the relationships it can infer from the infrastructure. It cannot infer that a business service depends on an application that runs on a cluster, unless Service Mapping has been configured to tell it so. Those upper-layer relationships are usually populated once, by hand, during the CSDM workshop, and then never touched again.
Six months on, the infrastructure layer is accurate and the service layer is fiction. And the service layer is the part leadership actually asks about.
Why "just run a data audit" does not fix it
The instinct is to schedule a clean-up. Find the duplicates, merge them, correct the stale attributes, move on.
Clean-up without changing the inputs buys you a few weeks. The duplicates return because the import that created them still runs on Tuesdays. The stale attributes return because the reconciliation precedence that allowed them is still unset. You have treated the symptom while leaving the mechanism intact.
Data quality is not a state you reach. It is the output of the rules governing what may write to the database.
What to put in place instead
Write down which source is authoritative for which attribute. Not per table — per attribute. Discovery is authoritative for operating_system and cpu_count. The procurement system is authoritative for cost_center and warranty_expiration. Then configure IRE datasource precedence to match, and make it impossible for a lesser source to overwrite a better one.
Audit the doors, not just the data. Enumerate every mechanism that can insert into cmdb_ci — every import set, every integration, every catalog item, every script. For each, confirm it goes through IRE. Anything writing directly to the table is a future duplicate generator, and it is easier to find it now than to reverse its output later.
Instrument identification, not just population. Most CMDB dashboards report completeness — how many CIs have an owner, how many have a support group. Far more useful is the IRE error and duplicate-detection log. A rising count of unmatched or ambiguous identifications is the leading indicator; a wrong impact assessment is the lagging one.
Give the service layer an owner and a review cadence. The relationships CSDM cares about will not maintain themselves. Someone has to be accountable for the map between business services and the things underneath them, and it needs to be reviewed on a schedule rather than when something breaks.
Set the standard before you scale the scope. It is far cheaper to establish this while Discovery covers one data centre than after it covers five and three integrations have joined the party.
The question worth asking
A useful test of CMDB health has nothing to do with CI counts. It is this:
When there is a major incident, does anyone open the CMDB?
If the answer is no — if people ring a colleague who "knows the estate" instead — the CMDB is not a source of truth regardless of what the completeness dashboard says. That gap between what the data claims and what people actually trust is the real measure, and it is the one worth closing.
If any of this sounds like your environment, our Platform Health Check reviews CMDB structure, reconciliation behaviour and data quality as one of its eight areas.