Last week, we looked at a practical limit: master data will not fix ERP problems. A hub can clean records, align identifiers, and publish trusted data. It cannot repair a broken approval path, unclear ownership, weak process design, or years of ERP workarounds. When the process is confused, the hub usually inherits the confusion.

This week, the problem shifts from systems to operating model. What happens when one central team can no longer review every master data decision? Decentralized MDM is not a pass for every domain to define data however it wants. It gives teams ownership closer to the work, while the enterprise sets the common rules and shared services that keep master data usable across the business.

Decentralized MDM: Coordination Without Control

A supplier change request sits in a queue for twelve days.

Procurement knows the record is wrong. Finance knows the payment terms are wrong. The MDM team knows the hub needs the update. The change still waits because three teams have to approve it, and no one wants to be the person who breaks downstream reporting.

That is the problem we circled last week when we looked at why your ERP should not automatically become the master data authority.

When one platform becomes the default master, teams often accept central control without asking whether the control fits the business. Customer data moves one way. Supplier data moves another. Product data gets squeezed into fields meant for a different process. Eventually, people stop trusting the official path and build their own.

The harder question comes next: how do you decentralize master data without letting every domain drift?

Many leaders hear “decentralized MDM” and assume it means chaos. Every team owns its own data. Every system defines its own rules. Every domain becomes a small island with its own identifiers, workflows, exceptions, and naming habits.

That is usually unmanaged data wearing an MDM label.

A better model gives teams more control over the data they understand best, while the enterprise defines the common rules that keep everything connected. The central role does not go away. It changes from reviewing every change to making safe local change possible.

Why Centralized MDM Starts to Break

Centralized MDM usually begins with a reasonable goal.

The hub has a team. Changes have a workflow. The enterprise model covers the usual domains: Customer, Product, Supplier, Location, Asset, Employee.

Early on, that can work. There are only a few domains, a handful of source systems, and a small group of business owners. The central team can keep up because the number of decisions is still manageable.

Then the program grows.

A regional team needs a supplier attribute for local compliance. Sales wants account hierarchy changes before the next quota cycle. Finance needs billing names to follow legal parent rules. Operations needs locations grouped by service region, not accounting region. Analytics wants lineage, history, and alternate rollups.

The central team becomes the queue.

By that point, people are no longer arguing about master data theory. They are waiting on tickets. They are asking why a simple business change takes three weeks. They are copying data into spreadsheets because the hub cannot move fast enough.

Most teams find this out the hard way. The central model looks strong in design reviews, then starts to weaken under day-to-day pressure. Central control also creates distance. The people approving changes may not understand why the domain needs them. The people closest to the business cannot update the data without waiting. Shadow tables show up. Local overrides become normal. Reports start depending on logic no one owns.

Central teams are rarely the real problem. The trouble starts when normal business change has nowhere else to go.

What Decentralized MDM Actually Means

A product team may need to change how bundles are grouped for a new sales motion. Finance may still need the old rollup for revenue reporting. Operations may care about warehouse handling, not sales structure at all.

A bundle can be one sellable product in CRM, three SKUs in fulfillment, and five revenue lines in finance.

Those are not bad definitions. They are different views created for different jobs.

Decentralized MDM means those teams do not all need to wait on the same central queue for every local decision. Domain teams own more of the master data work close to the business process.

Customer teams manage customer meaning. Product teams manage product structure. Supplier teams manage supplier onboarding and stewardship. Location teams manage facilities, sites, stores, service areas, or regions.

The enterprise still owns the rules that keep those local decisions from breaking everyone else.

A decentralized model does not let every team invent its own identifiers, publish untested changes, or redefine shared terms whenever it wants. It gives domain teams freedom inside an agreed structure.

Think about a customer domain. Sales may understand the relationship. Finance may care about the legal payer. Support may care about entitlement. Marketing may care about consent and channel preference.

One domain owns much of the work, but other teams depend on the result. Without common rules for identity, naming, access, contracts, lineage, quality, and escalation, that domain becomes a local authority with no obligation to the rest of the business.

Governance still exists. More of it happens closer to the work.

The Enterprise Should Provide Standards, Not Approve Everything

A central MDM team should not spend its best hours acting like a help desk for every field change.

Some changes are too big to handle locally. A new customer ID pattern is one. A survivorship rule that changes which address wins is another. Sensitive attributes, cross-system models, and global hierarchy rules also need enterprise review. Those changes carry enterprise risk, so they need review outside a single domain.

Many other decisions should happen inside the domain. A product team should not need a central committee to adjust a local product description rule. A regional team should not wait weeks to correct a domain-specific classification that has no cross-domain impact. A steward should not open a governance ticket to fix a known data quality issue already covered by policy.

The enterprise data function should define the rules that make local action safe.

In practical terms, it should provide the pieces every domain needs but should not have to invent. That includes identifier standards, glossary terms, naming rules, data quality thresholds, API standards, event standards, lineage requirements, access rules, and a clear path for exceptions.

DAMA’s data management guidance supports this broader view of data work. Data management requires metadata, quality, planning, enterprise perspective, business and technical skills, leadership, and shared accountability. It is not something one isolated team can do well alone.

In practice, the central team becomes a standards and services team. That shift changes the tone of governance. Instead of asking, “Who approved this?” teams ask, “Did this follow the standard?” Instead of routing every decision through a meeting, teams rely on defined patterns, automated checks, and clear exception paths.

Shared Services Are the Real Backbone

Decentralized MDM needs shared services more than centralized MDM does.

That may sound backwards. It is not.

When everything runs through one hub and one team, some controls can stay informal for a while. People ask the same architect. They message the same steward. They rely on the same batch process. It does not scale well, but it can hold together longer than it should.

Once domains start owning more work, the controls need to be more visible.

A shared glossary becomes more than a documentation tool. It becomes the place where Customer, Active Supplier, Billable Location, and Product Family get pinned down.

Nobody wants to call a meeting about a field name. Plenty of teams have lost days because one field name hid two meanings.

This also happens with status fields. “Active” may mean billable in one system, open-for-service in another, and eligible-for-reporting somewhere else.

Metadata becomes more than an afterthought. It tells consumers who owns a field, where it came from, what it means, how fresh it is, and what systems depend on it.

Lineage becomes a survival tool. Without it, a local change in a supplier domain can break a finance report two systems away. This usually shows up during a release. A domain team changes a field, the integration test passes, and two days later a Power BI report starts showing blank regions. The schema did not break. The meaning did.

Data contracts matter here too. If a domain publishes master data through an API or event stream, consumers need a stable shape, clear versioning, and rules for breaking changes. A schema alone is not enough. Consumers also need meaning, quality promises, security rules, and support paths.

One side may publish a customer change event with a parent account ID. Another side may consume that event for billing, quota planning, and reporting. If the meaning of that parent ID changes, the damage may show up in three places before anyone connects it to the source.

The same applies to access. Decentralized ownership should not create decentralized security. Sensitive master data still needs classification, role-based access, masking where needed, and audit trails.

Shared services also need funding. A catalog no one maintains, a contract process no one owns, and a lineage tool no one trusts will not support decentralized MDM for long.

Without those services, local freedom usually shows up later as cleanup work.

What Should Stay Central

Some decisions are too expensive to let drift.

Enterprise identifiers are the clearest example. If every domain creates its own customer ID, supplier ID, or location ID with no mapping rules, integration becomes guesswork. You may get away with it inside one system. Cross-system reporting will expose the problem fast.

Shared semantics also need central care. The enterprise does not need to define every field in every local model, but it must define the terms that cross domains.

Customer. Supplier. Product. Site. Employee. Active. Legal parent. Billing account. Ship-to location.

A small word can carry a large process difference.

Finance may roll customers to a legal parent for billing. Sales may roll them to a regional account team for quota management. Support may care about service entitlement.

None of those views are wrong. They answer different questions.

The mistake is forcing one hierarchy to serve every purpose.

Central governance should define which hierarchy is used for which purpose, how each one is named, who owns it, and how consumers know the difference.

I’ve seen this happen when finance and sales both use the same customer hierarchy label, but one means legal parent and the other means selling relationship. The words match. The business meaning does not.

Privacy rules also belong near the enterprise level. A domain team may own customer attributes, but it should not invent its own rules for sensitive data. The same goes for retention, masking, access approval, and audit requirements.

What Domain Teams Should Own

A domain issue usually reaches the business before it reaches the hub. The team closest to the process knows what changed, why it changed, and whether the change is valid.

That is why domain teams should own the business meaning and day-to-day health of their data.

This includes local rules, stewardship decisions, issue triage, domain-specific fields, and source system knowledge.

A central team may know how the hub works. The domain team knows why a value is wrong.

Procurement may know why a supplier is active but blocked for payment. Finance sees the tax profile problem. Sales catches the account hierarchy that no longer matches the field team. Operations notices the closed location that still appears in scheduling.

A store can be closed for sales, active for returns, and still valid for lease accounting.

Those are not abstract data issues. They are business facts.

When those teams have no ownership path, two things happen. The central team gets overloaded with decisions it cannot make well. Domain experts stop sending changes through the official process because the process does not respect their urgency.

A strong decentralized model gives domain teams clear rights and clear duties.

They can update local rules within policy. They can resolve known data issues. They can publish changes through approved contracts. They can request exceptions when the standard does not fit.

They also own the consequences.

If the product domain publishes bad classifications, it shows up on their scorecard. If supplier data misses required quality thresholds, the supplier owner sees the breach. If a customer domain breaks a contract, consumers know who to call.

If no one can see the owner, the scorecard, or the support path, ownership will not change much.

Use a Control Plane for MDM

The easiest way to explain this is to separate where the work happens from how the work is governed.

The data plane is where master data moves and changes. Source systems, domain workflows, APIs, event streams, data products, and consuming systems all sit here.

The control plane is where coordination happens. Standards, metadata, contracts, access policy, quality checks, lineage, monitoring, and exception handling sit here.

The data plane can be distributed.

The control plane needs to be shared.

A product team can manage product data locally, but the product interface still follows contract rules. A supplier team can manage onboarding, but supplier identity still follows enterprise standards. A customer team can own stewardship, but sensitive attributes still follow security policy.

A shared services team does not need to touch every record. It needs to make sure the rules are clear, testable, and visible.

Some of those controls can be automated. Contract checks can catch breaking schema changes. Quality rules can flag required fields. Lineage tools can show downstream impact. Access workflows can route standard requests without a meeting.

Humans still matter. They handle conflict, policy gaps, business exceptions, and tradeoffs.

The better the control plane, the less often people need to fight through email threads to figure out what happened.

Where Data Mesh Helps, and Where It Does Not

Data mesh gave data teams a better vocabulary.

Domain ownership. Data products. Self-service platforms. Federated governance.

That language helps with decentralized MDM, but the two ideas are not the same.

Data mesh is broader. It mostly shows up in conversations about analytical data products and domain-owned data at scale. Decentralized MDM has a narrower burden: shared business entities that affect operations, reporting, integration, and sometimes compliance.

There is overlap. A Customer master can be published like a data product, and a Product domain can own its model and interfaces. The difference is risk. Master data often feeds operations, not just analysis.

Master data does not just sit in a dashboard. It changes what systems do.

A bad customer merge can affect billing. A wrong supplier status can block purchasing. A broken location hierarchy can misroute work. A product classification change can affect pricing, reporting, and inventory.

Problems start when teams borrow the domain ownership language and leave the governance work vague. Domain ownership helps. It needs shared standards around it.

The Risks Are Real

Decentralized MDM can fail.

It fails when teams mistake autonomy for independence. It fails when the enterprise publishes standards but never funds shared services. It fails when domain owners are named on paper but do not have time, authority, or incentives to do the work.

Semantic drift is the first common problem. Teams use the same words with different meanings. At first, it looks harmless. Then reports disagree. APIs return confusing results. New integrations require long mapping sessions because no one can tell which definition is current.

Duplicate mastering is another problem. One domain masters Supplier for procurement. Another masters Vendor for finance. A third keeps a local partner table for operations. All three describe overlapping entities, but the mappings are incomplete.

The same supplier may appear under a legal name in finance, a trade name in procurement, and an abbreviated name in a local ordering system. Add one tax number and two active IDs, and the cleanup becomes political fast.

Tool sprawl can sneak in next. Each domain buys or builds what it needs. One team uses a catalog. Another uses a wiki. Another keeps contracts in a repo. Another tracks steward issues in a spreadsheet. Nothing connects.

You can also end up with slow exceptions. The normal path gets faster, but anything unusual still falls into a governance black hole. Teams remember that. They start routing around it.

A decentralized model needs a few non-negotiables. Shared master data products need named owners. Published interfaces need contracts. Critical attributes need definitions. Sensitive fields need classification. Exceptions need a path that people can actually use.

That list is not fancy. It is the minimum needed to keep trust from slipping.

Metrics Should Measure Coordination

Many MDM programs measure data quality and stop there.

Quality matters, but decentralized MDM needs a wider scorecard. You need to know whether teams are coordinating well.

Start with friction. How long does it take to publish a domain-approved change? How often do contracts fail? How many teams still pull from local extracts because the governed API is too slow, too thin, or too hard to use? How many quality issues close before a downstream team complains?

The most interesting metric may be reuse.

If five teams consume the same governed Customer API instead of building five local extracts, the model is working. If product data consumers use the published domain contract instead of calling someone for a custom file, that is progress. If data stewards close issues before downstream teams complain, even better.

A technically correct hub that no one wants to use is not a success.

Adoption tells you whether the model fits real work. A decentralized model with strong reuse, clear ownership, and fewer side paths is much closer to the goal.

A Practical Starting Point

You do not need to redesign the whole MDM operating model at once.

Start with one domain where central control is causing visible pain. Customer, Product, Supplier, and Location are common candidates.

Supplier is often a good pilot because the pain is easy to see. Duplicate suppliers affect procurement. Bad remit-to data affects payments. Weak onboarding controls create risk. The domain has clear business owners, but plenty of cross-functional impact.

Start with ownership. Not the name in the slide deck. The person or team that gets called when the data is wrong.

From there, separate the shared core from the local fields. Some attributes need enterprise rules. Others only matter to one workflow and should stay there.

Follow the consumers next. Reports, APIs, operational feeds, downstream processes. You are looking for the places where a local change becomes someone else’s outage.

Look at the contracts. If consumers are pulling from whatever table they can reach, you do not have a publishing model. You have exposure.

Then look at stewardship. Where do data quality issues go? Who fixes them? Who decides when the fix is good enough?

From there, build the first support layer around the domain. Define the core terms. Clean up identifier rules. Publish a basic contract. Add quality checks. Document ownership. Create an exception path. Track adoption.

Do not start by federating every domain. Pick one domain, prove the pattern there, and carry what worked into the next one.

Final Thought: Coordination Beats Control

Good MDM programs do not try to pull every decision back to the center.

They centralize the things that make local decisions safer: standards, shared services, metadata, contracts, quality checks, access rules, lineage, escalation paths, and ownership expectations.

Domain teams should not need permission for every normal change. They need a structure that lets them move without breaking everyone else.

Command-and-control MDM feels safer at first because the authority is easy to see. The problem is that business change does not wait for one central queue to catch up.

Decentralized MDM is harder to design, but easier to live with when done well.

The enterprise role still matters. Define the standards. Run the shared services. Handle the exceptions. Make ownership visible. Then let domain teams fix the work they are closest to, without sending every normal change back into the same queue.