CMDB vs EA repository: why they disagree and how to reconcile them

A CMDB records what runs: configuration items, the services they make up, and the incidents and changes against them. An EA repository records what the business has and plans: applications, the capabilities they support, lifecycle, owners, cost and target state. Neither replaces the other. They disagree because they count different things, owned by different teams, updated at different speeds. The fix is not to merge them but to agree a join key, map their vocabularies, match records with evidence, and send each conflict back to the owner of the source.

What is each system for?

The CMDB is operational truth. It exists so that service management can restore a service, assess a change and trace an incident to the components behind it. Its records are created by discovery tools, deployment pipelines and change processes, often many times a day.

The EA repository is planning truth. It exists so that architects and portfolio owners can answer what the business has, what it costs, who is accountable, and what should happen to it next. Its records change when people review them, which is usually quarterly or yearly.

Both are correct for their own purpose. The trouble starts when a question needs both.

Why the units don't match

An application in the repository is a business idea: "Customer onboarding", one record with one owner. In the CMDB the same thing might be a business service, three application instances for development, test and production, two databases, a message queue and a dozen servers. Some of those CIs are shared with other applications.

So the relation is rarely one to one. One application maps to many CIs. One shared database maps to several applications. Some CIs belong to no application in the repository, and some applications have no CI at all because they are bought as a service. Any reconciliation has to decide first which CMDB record stands for the application: usually the business service or the application-type CI, not the infrastructure beneath it.

Why matching by name fails

The obvious approach is to match on name. It works for the easy half of the estate and fails quietly on the rest:

• Acronyms. "Customer Relationship Platform" in one system is "CRP" in the other.
• Environment suffixes. "Payments-PROD", "payments_uat" and "Payments Hub" may be one application or three.
• Case and punctuation. Small differences that a strict match treats as different records.
• Many CIs per application. A name match returns six candidates and no rule for picking one.
• No shared id. Many CMDB records carry no repository id at all, because nobody was asked to fill it in.

A name match that looks nearly complete can hide the records that matter most: the old, oddly named systems nobody has reviewed.

Which disagreements actually matter?

Not every difference is worth chasing. Three are.

Lifecycle. The repository marks an application retired, but the CMDB still shows operational CIs, or incidents and changes in the last quarter. Either the application still runs and the plan is wrong, or the CIs are stale and the operational record is wrong. Both matter. A change that is the decommission itself is not a conflict.

Criticality. Both systems usually rate criticality, on different scales. One may use four business tiers, the other a numeric service priority. Compare them only after you have written down how one scale maps onto the other. Without that mapping, every record looks like a disagreement.

Owner. The repository names a business owner; the CMDB names a support group or a technical owner. These are often different people by design. A real conflict is when the person in either system has left, or when the two point to different business units.

What isn't a disagreement

A value that is blank in one system and filled in the other is a gap, not a conflict. Report it separately. Mixing gaps with conflicts inflates the problem and sends people to argue about records where nobody ever disagreed. Records you could not match are also not disagreements. They are a third list: unmatched, waiting for a person.

A reconciliation method that holds up

1. Agree the join key and write it back. Choose one id, usually the repository's application id, and store it on the matching CMDB record (business service or application CI). Once written back, the next run matches on the key and not on names.
2. Map the vocabularies. Write down how lifecycle phases, criticality tiers and status values in one system translate to the other. Keep the mapping in a reviewed document, not in someone's head.
3. Match with evidence and a confidence. For records without the key, match on normalised names, acronyms, owners, support groups and relations. Record why each pair was matched and how sure the match is. Send the ambiguous pairs to a person instead of guessing.
4. Report three lists, not one. Conflicts between matched records, gaps where one side is blank, and records that could not be matched. Each goes to a different owner.
5. Fix at the source, with owners. Do not patch the report. Send each conflict to the owner of the system that is wrong, and let them correct the record. A reconciliation that edits a spreadsheet fixes nothing.
6. Rerun on a schedule. Monthly is a reasonable start. Track how many records carry the join key and how many conflicts remain. Those two numbers tell you whether the estate is getting better.

The questions in our kit for testing an AI assistant on EA work include repository and CMDB reconciliation and the retired-but-still-running check. They are a quick way to see whether a tool does this matching properly or skips it.

Why this matters more now

For years, the gap between the two systems was absorbed by people. An architect who saw a retired application with fresh incidents knew to ask. An agent does not. When an AI assistant reads both systems to answer "what does retiring this platform touch?", it repeats whatever inconsistency it finds, and presents it with the same confidence as a fact.

That changes the cost of poor data. An inconsistency that sat unnoticed in two screens now turns up in a board paper. As the EA repository becomes the context agents read, its agreement with the CMDB becomes part of its quality, not a separate project.

Where to start

Pick your mission-critical applications, perhaps fifty. Agree the join key, write it into the CMDB for those records, and agree the criticality mapping. Run the three lists once, by hand if you must, and send each conflict to its owner. When the critical set reconciles cleanly, extend it to the next tier and put the run on a schedule. A small set that both systems agree on is worth more than a full estate that neither can trust.