We rarely see Master Data Management programmes pick a single, fixed architecture on day one. Instead, most fall along a spectrum: from lightweight styles that support reporting and analytics, to heavier styles that put MDM directly in the path of live business transactions. Once you understand where a given implementation style sits on that spectrum, and why, it becomes much easier to choose a sensible starting point and a realistic path forward, without ending up in a reactive pattern, where data cannot made better at source.

---

The four classic MDM implementation styles, positioned from analytical to operational.

The Four Implementation Styles

We generally see four implementation styles described in MDM literature (Gartner among others): Registry, Consolidation, Coexistence, and Centralised (or Transaction Hub). Each style answers two questions differently: where does the golden record live, and does it flow back into the systems that created the data in the first place?

Styles That Favor Analytical MDM

Registry

In a Registry style, source systems keep ownership of their data. The MDM hub holds only a thin index, or cross-reference: IDs and match keys that point back to where the real record lives. We see data virtually federated at query time rather than physically consolidated; this is why vendors often call this style “Federated MDM” rather than Registry.

You’ll find this a good fit for analytical use cases (reporting, matching and deduplication for BI, regulatory views) where a unified view of the data is needed, but nothing has to be written back into operational systems. It’s cheap and fast to implement, but unsuitable for real-time operational consumption, since there’s no golden, physically-persisted record to work from.

Registry style: source systems keep ownership; the hub holds only an index.

Consolidation

We pull data physically from source systems into the hub, typically via batch or ETL, and merge it into a golden record. That golden record is used for reporting and analytics, but source systems keep creating and updating their own data independently. The hub doesn’t feed back into operational transactions in real time.

This is the most common analytical MDM pattern: the data-warehouse equivalent of a single version of truth for master data.

Consolidation style: a physical golden record, flowing one way into the hub.

Registry and Consolidation share a structural weakness we’d call data lock: because the golden record only lives in the hub, and nothing flows back to source, the people working in the systems where the data was originally created have no way to correct it there. The same error just gets pulled through, cleaned in the hub, and re-imported at the next refresh, over and over. We make the case for tackling this by moving mastering upstream, into creation, in Master Data at Birth: Why Golden Records Should Be Created, Not Reconciled.

Styles That Favor Operational MDM

Coexistence

Coexistence uses the same consolidation approach, but now we synchronise the golden record back to source systems, bi-directionally. Operational systems begin consuming the improved, mastered data rather than only their own local copy.

This is the point where MDM starts directly touching transactional processes (order-to-cash, procurement, customer service) rather than just reporting.

Coexistence style: the golden record is synced back to source systems as well as out to BI.

Centralised / Transaction Hub

The MDM hub becomes the system of record. Every create and update happens in the hub first, and then propagates out to source and consuming systems. This is fully operational MDM: the hub isn’t a side reference any more; it sits in the critical path of live transactions, for example mastering a customer or material record before you can even place an order.

This style carries the highest governance and data-quality payoff, but also the highest implementation cost and risk, since it requires you to re-architect how systems create and update data in the first place.

Centralised / Transaction Hub style: the hub is the system of record for every create and update.

Summary Comparison

Style	Data flow	Leans towards
Registry	Virtual, read-only	Analytical
Consolidation	Physical, one-way (source to hub)	Analytical
Coexistence	Physical, bi-directional	Operational (transitional)
Centralised / Transaction Hub	Hub is master, propagates out	Operational

Choosing a Starting Point

In practice, large MDM programmes (especially in ERP-heavy landscapes like SAP) tend to start with Registry or Consolidation to get quick analytical wins and build stakeholder trust, then evolve towards Coexistence and eventually a Centralised Transaction Hub as governance maturity increases. Jumping straight to a Transaction Hub is a much bigger organisational lift, and few programmes have the appetite, or the governance foundation, to do that on day one.

The practical takeaway: choosing an MDM implementation style isn’t just a technical decision. It’s a statement about how much operational risk and organisational change your business is ready to absorb, at this point in the programme’s maturity.