[ARTICLE] Discovery Is Doing Its Job, your Identification Strategy Isn’t

[Rafael P]

Spoiler

Discovery is often blamed for CMDB chaos, but in most cases it behaves exactly as designed. This article explains why Identification and Reconciliation is the real architectural control point in ITOM.

Every day.. the most frequent conversations in ITOM projects goes like this:

“Discovery is creating duplicates.”
“Discovery is overwriting data.”
“Discovery cannot be trusted.”

From an architectural standpoint, these statements misunderstand the role of Discovery entirely.

Discovery observes. It does not decide.The Identification and Reconciliation Engine (IRE) is the component responsible for deciding what is real, what is duplicated, and what should be merged or ignored. When duplicates appear, Discovery has already completed its job. The architecture failed earlier.

This becomes painfully visible in environments with virtualization, autoscaling, or cloud elasticity. Hostnames are reused. IP addresses rotate. Servers are rebuilt frequently. If identity is anchored to unstable attributes, duplication is inevitable.

A strong ITOM architecture treats CI identity as a design artifact, not an operational configuration. Identification rules should be deliberate, minimal, and stable. They should be reviewed with the same rigor as application architecture diagrams.

Another common issue is source precedence misuse. When multiple ingestion paths exist — Discovery, integrations, manual updates — precedence must reflect intent, not convenience. If teams adjust precedence reactively to “fix data,” they introduce long-term inconsistency.

In mature environments, IRE changes are rare, documented, and tested. They are understood not just by the CMDB team, but by Discovery engineers and operations as well.

The key architectural insight is simple:
If the CMDB cannot answer “why this CI exists and why it looks this way,” trust will never emerge.

Discovery does not break trust. Poor identity design does.