MDM in a Data Mesh World: Who Owns the Golden Record?

In the architecture reviews I have sat through over the years, the same argument keeps surfacing in a new costume. Two teams, each convinced they own the customer. One has spent months building a domain data product they are rightly proud of. The other has an enterprise mandate to produce a single consolidated report. Both are correct about their own scope, and both are stuck, because nobody decided in advance who arbitrates when their definitions of “customer” disagree. The whiteboard fills with boxes and arrows, everyone nods, and the actual question, who owns the golden record, goes home unanswered. I have watched that question stall otherwise healthy Data Mesh and Master Data Management programs more often than any technical limitation ever has.

The Collision Nobody Planned For

The Master Data Management market hit $21.6 billion in 2026 and is growing at nearly 19% per year. At the same time, Data Mesh has matured from conference-talk theory into a real operating model. ThoughtWorks, whose principal consultant Zhamak Dehghani coined the term in 2019, recently described the state of Data Mesh in 2026 as “hard-won maturity”: the hype has faded, and organizations that stuck with it are seeing results.

But here is the problem nobody mapped clearly when the hype was at its peak. Data Mesh says: domains own their data products. MDM says: there is one golden record for each entity. If the payments domain owns its view of a customer and the marketing domain owns its view of the same customer, who owns the canonical customer record? And if nobody does, how do you run a regulatory report that requires one?

This is not a theoretical debate. Gartner predicts that 80% of Data and Analytics governance initiatives will fail by 2027, largely because organizations cannot resolve exactly this kind of cross-domain authority question. The teams that figure out how to reconcile domain autonomy with enterprise consistency will be the ones whose Data Governance programs survive.

Why the Tension Is Genuine

Start with Dehghani’s own framework. Data Mesh rests on four principles: domain-oriented data ownership, data as a product, self-serve data platform, and federated computational governance. The first principle is explicit: the people closest to the data should own it, produce it, and be accountable for its quality.

Traditional MDM operates from the opposite assumption. There is one master record for “Customer,” “Product,” “Supplier,” or “Location.” A central team curates it. Source systems feed data in; the hub resolves duplicates, merges attributes, and publishes the golden record outward. Every downstream consumer trusts the hub.

These two models collide at entities that span domains. Dehghani calls them polysemes: shared concepts that mean slightly different things in different contexts. An “artist” in a media company’s streaming domain has different attributes than the same artist in the royalties domain. A “customer” in lending looks different from a “customer” in wealth management. Both are valid representations. Neither is wrong. But a regulator asking for a consolidated exposure report needs exactly one answer.

The tension, then, is not between good and bad architecture. It is between autonomy (let domains move fast with their own definitions) and consistency (give the enterprise a single source of truth for shared entities). Both are legitimate requirements. You cannot pick one and ignore the other.

For practitioners: If you are running a Data Mesh initiative and have not yet hit this tension, you probably have fewer than three domains publishing data products. The collision becomes unavoidable once cross-domain consumers appear.

Three Patterns That Work

After studying how organizations from financial services to retail are solving this, three repeatable patterns emerge. None is universally best. Each fits a different organizational shape.

Pattern 1: Federated MDM with Shared Data Contracts

In this pattern, domains own their entities but conform to a shared contract that defines the cross-domain fields every entity must carry. The central team does not own the data. It owns the contract.

How it works:

1. A cross-domain governance group defines data contracts for each polyseme (Customer, Product, Supplier). The contract specifies: required fields, allowed formats, reference data values, and a global entity identifier.
2. Each domain publishes its data product with its own domain-specific attributes plus the contracted cross-domain fields.
3. Entity resolution runs at the platform level, using the global identifiers and matching rules to link records across domains.
4. The governance group reviews contract changes through a versioned, pull-request-style process.

Capital One followed a version of this approach, establishing a hybrid governance practice with a central enterprise team and federated teams in each business line. The central team builds platforms and self-service tools. The business lines own the data. Common standards are enforced through tooling, not through a central team manually curating records.

When it fits: Organizations with five or more domains producing data products, where domain teams have enough maturity to honor contracts. This pattern scales well but requires investment in contract tooling and a functioning governance council.

Pattern 2: Domain-Owned Golden Records with Cross-Domain Reconciliation

This pattern gives each domain full ownership of its golden record. No central contract governs the shape of their entities. Instead, a reconciliation service detects conflicts after the fact.

How it works:

1. Each domain maintains its own golden record for the entities it cares about, using its own matching rules, survivorship logic, and quality standards.
2. A scheduled reconciliation process compares entity representations across domains, flagging conflicts: mismatched addresses, duplicate identifiers, contradictory statuses.
3. Conflicts route to a governance council that adjudicates: which domain’s value wins for which use case, or whether a shared value needs to be established.
4. Adjudication decisions are recorded as precedent, building a body of cross-domain rules over time.

This is the Microsoft Cloud Adoption Framework’s recommended starting point for organizations adopting MDM within a data mesh. Microsoft’s guidance is direct: “Your organization must find the correct balance. Having too many areas of master data leads to too much cross-domain alignment. Having no enterprise data at all makes it impossible to compare any results.”

When it fits: Organizations early in their Data Mesh journey, where domains have uneven maturity. This pattern tolerates inconsistency in exchange for faster domain autonomy. It requires a governance council willing to make rulings and a reconciliation pipeline that runs frequently enough to catch problems before they reach production reports.

What this looks like in practice. Consider an illustrative composite: a retail company that lets its supply chain domain and its e-commerce domain each maintain their own product golden records. The supply chain team cares about packaging dimensions, lot codes, and shelf life. The e-commerce team cares about product images, SEO descriptions, and pricing tiers. A weekly reconciliation job checks that every SKU appearing in both domains shares the same UPC, manufacturer, and category code. When it finds a mismatch, it creates a ticket assigned to the cross-domain product steward.

Pattern 3: Thin MDM Layer as a Platform Service

This pattern treats MDM not as a central authority but as infrastructure. The MDM capability is offered as a self-serve platform service that domains consume voluntarily.

How it works:

1. The data platform team builds a matching-and-merging service: entity resolution, duplicate detection, cross-reference management, and ID assignment.
2. Domains call the service when they need to resolve entities, mint new global identifiers, or check whether a record already exists in another domain.
3. The service stores only identifiers and cross-references (the registry pattern in traditional MDM terminology). Full entity attributes stay in the domains.
4. The platform team owns the algorithms and infrastructure. Domains own the data and the decision of when to call the service.

This is the lightest-weight option and maps cleanly to Dehghani’s self-serve data platform principle. The traditional MDM registry pattern stores only IDs and matching keys without maintaining full attribute sets. When an application requests master data, the registry resolves the entity using its index and federates the query back to the originating systems.

When it fits: Organizations with many source systems that want minimal disruption, or organizations whose primary MDM need is entity resolution rather than full golden record management. Works well when the data platform team is already operating as a product team with an internal-customer mindset.

The agent-era restatement: AI-powered entity resolution is changing the economics of Pattern 3. Agentic entity resolution uses ML models to match records across domains with higher accuracy and lower human effort than rule-based approaches. Platforms like Tamr and Senzing reduce the manual matching effort involved in cross-domain resolution while improving match quality, part of a broader shift in which Gartner expects GenAI to cut manually intensive data management costs up to 20% each year through 2026. This makes the thin-platform pattern viable for organizations that previously needed full consolidation-style MDM because their matching volumes were too high for manual curation.

Choosing Your Pattern: A Decision Framework

The right pattern depends on three variables: domain maturity, entity overlap, and your organization’s tolerance for central authority.

Factor	Pattern 1: Federated + Contract	Pattern 2: Domain-Owned + Reconciliation	Pattern 3: Thin Platform Service
Domain maturity	High (5+ domains, data product thinking)	Mixed (some mature, some early)	Any (platform absorbs complexity)
Entity overlap	High (many polysemes shared across domains)	Moderate (a few key entities overlap)	Variable (on-demand resolution)
Central authority appetite	Moderate (contract governance, not data ownership)	Low (governance council reacts, does not prescribe)	Minimal (platform offers tools, domains choose)
Time to value	Longer (contract negotiation takes months)	Faster (domains start independently)	Fastest (platform team ships a service)
Consistency guarantee	Strongest (contracts enforced upfront)	Eventual (reconciliation catches drift)	Weakest (voluntary adoption)
Regulatory pressure	Best fit for regulated industries	Workable with strong reconciliation cadence	Sufficient for non-regulated or low-overlap cases

Most organizations will not stay in one pattern forever. A common progression: start with Pattern 3 (thin platform) to prove value and build trust, graduate to Pattern 2 (reconciliation) as cross-domain consumers emerge, and formalize into Pattern 1 (contracts) once the governance muscle is strong enough to maintain them. This mirrors the traditional MDM evolution path from registry to consolidation to coexistence.

The Organizational Design: Who Staffs This

Technology does not resolve this tension. Organizational design does. Here is the staffing model that works across all three patterns.

The central data platform team owns MDM infrastructure: the matching engine, the cross-reference store, the contract registry, the reconciliation pipelines. They do not own any master data. They own the practice of mastering data. ThoughtWorks describes this evolution precisely: the central data office moves “from a gatekeeper to a center of excellence that acts as a facilitator and enabler”.

Domain data product owners own their entity representations, including the quality, completeness, and timeliness of their domain’s view. They are accountable for conforming to data contracts (Pattern 1), participating in reconciliation reviews (Pattern 2), or calling the platform service when publishing cross-domain data products (Pattern 3).

The cross-domain governance council arbitrates disputes. When payments says a customer’s primary address is their billing address and marketing says it is their shipping address, the council decides: for this use case, which value wins? Their decisions become precedent that feeds back into contracts or reconciliation rules. Capital One built this structure with data stewards responsible for risk within each organization, data stewards for business units, and a data risk officer role providing cross-domain oversight.

The entity steward is a role that does not exist in most organizations and should. This person owns a specific polyseme (Customer, Product, Supplier) across domains. They do not own the data in any one domain. They own the consistency of the entity across domains. They chair reconciliation reviews, propose contract changes, and escalate unresolved conflicts to the governance council.

What this looks like in practice. Here is how this role tends to look at a typical mid-size financial services firm (an illustrative composite, not a single named engagement). The Customer entity steward sits in the enterprise data office but spends roughly half to two-thirds of their time embedded with the lending and deposits domains. They maintain the Customer data contract, review reconciliation exceptions weekly, and bring unresolved disputes to a monthly governance council. The role requires someone who understands both the business semantics (what “customer” means in each domain) and the technical plumbing (how entity resolution works).

Where CDEs Fit In

If you have been following the Critical Data Element series on this blog, you may notice the overlap. CDEs are the specific fields within these master entities that carry the most regulatory, financial, or operational weight. Customer Name, Tax ID, Legal Entity Identifier: these are Critical Data Elements that happen to live inside Master Data domains.

The CDE inventory methodology applies directly here. When you trace backward from Tier 1 uses (regulatory submissions, risk models) to source elements, you are identifying the exact fields that data contracts must cover. A well-built CDE register tells you which attributes of the Customer polyseme are non-negotiable across domains and which can safely vary.

In practice, the CDE register becomes the input to your data contracts in Pattern 1, the reconciliation scope in Pattern 2, and the matching-key configuration in Pattern 3. If you are running both a CDE program and an MDM modernization, connect them early. They are solving the same problem at different levels of abstraction.

Do Next

Priority	Action	Why it matters
1	Inventory your polysemes: list every entity that appears in more than one domain	You cannot govern cross-domain consistency for entities you have not identified. Start with Customer, Product, and Supplier.
2	Assess domain maturity honestly	Your pattern choice depends on whether domains can honor contracts (Pattern 1) or need reconciliation training wheels (Pattern 2). Do not pick a pattern that assumes maturity you do not have.
3	Stand up the entity steward role for your highest-overlap polyseme	Most organizations skip this role entirely. Without someone accountable for cross-domain consistency of a specific entity, disputes have no owner.
4	Build or buy entity resolution as a platform service	Whether you choose Pattern 1, 2, or 3, you need matching and cross-referencing infrastructure. AI-powered options have made this cheaper and more accurate than manual rule sets.
5	Draft data contracts for your top three polysemes	Even if you are starting with Pattern 2 or 3, writing the contract surfaces the disagreements you need to resolve. The contract is a conversation tool as much as a technical artifact.
6	Connect your CDE register to your MDM contracts	CDEs tell you which attributes are non-negotiable. MDM contracts tell you how those attributes are governed across domains. Link them before they drift apart.