The CMDB was right. We gave it the wrong job.

Keep the correlation. Drop the grooming.

If you believe in the CMDB and are exhausted by it, the idea was never the problem. Correlation, one thread tying alerts, incidents, changes, and services to the things they happened to, is as right as it ever was. What failed was welding that to asset management. An ICDB carries the correlation forward, and leaves the attributes, the grooming, and the audits behind.

There is a specific crowd this is written for, you sat through the ITIL slide, every record pointing back to one understanding of the environment, and you believed it. You were right to. Then you lived the practice, attribute forms, discovery imports that disagree with each other, reconciliation meetings, and the audit that finds a third of the records stale. Believing in the idea and being burned by the implementation are not contradictory positions. They are both correct, and holding both is what this piece is about.

The failure has a mechanism, and it is not discipline, tooling, or your team. The CMDB was given two jobs with incompatible definitions of correct. Correlation needs the record to be right, is this the thing that fired, and what does it belong to? Asset management needs the record to be complete, owner, warranty, cost center, rack position, patch level.

Completeness rots by nature, because attributes change without producing events, nothing tells the record it is now wrong. Correlation stays fresh by nature, because operational activity is events, every alert, incident, and change is the record updating itself. Weld the two together and the job that decays sets the reputation for both. The correlation you actually needed drowns under the inventory that can never be finished.

An ICDB, an Identity Correlation Database, keeps exactly the part you fell for. Identity first, every entity is a name and a type, one point of reference. And the thread, this alert fired on that entity, that entity belongs to that service, that incident was fixed by that change. When something breaks, the question is never "what is this thing's cost center", it is "what is this, what does it touch, and what happened to it last time". That is the CMDB promise, kept, minus everything that kept breaking it.

Everything else about an entity is earned from the work instead of declared on a form, what it fired, what it belongs to, what fixed it, what it took down with it. Associations are events, and events are facts, facts do not go stale the way declared attributes do. Which means there is nothing to groom, because nothing is asserted that was not observed. The recurring reconciliation project, the quarterly audit, the fight over who owns the record, none of it has an ICDB equivalent, because the decay those rituals exist to fight was a property of the attribute model, not of configuration data itself.

This is an evolution, not a rip-and-replace. The CMDB remains the right artifact for the jobs where completeness genuinely matters, compliance, procurement, asset lifecycle. Keep it for those, and reconcile the ICDB against it. The mistake was never having a CMDB. The mistake was asking one record to satisfy the auditor and the operator at the same time, when the two have never once agreed on what correct means.

Signal9 ships the ICDB as a working part of the platform, not a concept, entities are born from alerts and records, correlation accumulates as evidence, and the thing operations always wanted from the CMDB, the thread that ties everything together, stays current because the work itself maintains it.

What is the alternative to a CMDB for operations? An ICDB, an Identity Correlation Database, is a configuration database stripped to identity, where every entity is a name and a type, and everything else is earned from live operational activity, what it fired, what it belongs to, what fixed it. It keeps the CMDB's correlation promise and drops the asset-attribute maintenance that made CMDBs decay.

Why do CMDB projects fail? Because the CMDB is given two jobs with incompatible definitions of correct, correlation needs records to be right, asset management needs them to be complete. Completeness decays because attributes change without producing events, so the record silently goes wrong. It is a structural property of the model, not a failure of tooling or discipline.

Do I have to replace my CMDB to use an ICDB? No. Keep the CMDB for compliance, procurement, and asset management, where completeness matters, and reconcile the ICDB against it. The ICDB takes over the operational half, correlation, where being right matters more than being complete.

Does Signal9 include an ICDB? Yes. Signal9's ICDB assembles itself from operational activity, entities start as a name and a type, and their associations, alerts, services, incidents, changes, accumulate from the work itself. It stays current by construction, because it is built from what actually happened rather than a form somebody updates.