Data Mesh: Your Enterprise Already Is One

You heard "data mesh" at a conference. Your architect heard it on a podcast. Your vendor heard it and started updating their slide deck.

Now everyone is excited about decentralized data ownership. Domain teams own their data products. Self-serve infrastructure. Federated governance. It sounds like freedom. It sounds like the opposite of that centralized data lake that never delivered.

Here's the problem: your enterprise already runs a data mesh. You've been running one for years. You just call it "every department has their own database and nobody shares anything."

Data mesh without governance is just your current mess with a prettier architecture diagram.

The Four Words still apply.

[If you're joining the series here: the Four Words are Data Governance, Data Standards, Data Management, Data Exchange. Same order. Every time. Parts 1 and 2 covered why you can't skip straight to tools.]

Data mesh lives in Word 3 (Data Management) and Word 4 (Data Exchange). It is an architectural pattern for how data gets organized and shared across domains. It is not a governance model. It does not replace Words 1 and 2. It depends on them.

Let me say that louder for the vendors in the back: data mesh does not eliminate the need for enterprise data governance. It increases it.

Why mesh fails without governance

When you decentralize data ownership to domain teams, you're making a bet. The bet is that each team will define their data products with consistent quality, interoperable standards, and clear access policies. Without centralized governance standards, here's what actually happens:

Marketing defines "customer" one way. Finance defines it another. Operations has three definitions depending on which system you check. And the data mesh becomes a data marketplace where nobody speaks the same language.

I've watched this play out at three different agencies. The pattern is always the same. Phase 1: excitement about domain autonomy. Phase 2: teams build data products in isolation. Phase 3: someone tries to combine data from two domains and discovers the schemas don't align, the timestamps use different zones, and "Enterprise" means four different things (true story).

That's not a mesh. That's a mess with a Kubernetes cluster. [side note: I've seen this exact failure pattern more times than I've seen a clean data lake migration. And I've never seen a clean data lake migration.]

What governance looks like in a mesh

The good news: data mesh done right is actually excellent. It's one of the better patterns for large, complex organizations. But "done right" means the federated governance layer is the first thing you build, not the last.

Three non-negotiable governance requirements for mesh:

1. A shared business glossary that every domain agrees to before they build their first data product. Not after. Before. If domain teams can't agree on what "customer" means, they're not ready for mesh. They're not even ready for a shared spreadsheet.
2. Interoperability standards at the contract level. Every data product has a schema contract. Those contracts follow enterprise-wide standards for naming, typing, versioning, and access. The mesh platform enforces these contracts automatically. If a data product doesn't meet the standard, it doesn't publish.
3. A central governance council (small, empowered, cross-domain) that reviews data product registrations, resolves definition conflicts, and audits quality. This council doesn't own the data. The domains own the data. The council owns the rules.

The real question

When someone tells me their org is "moving to data mesh," I ask three questions:

1. Do you have an enterprise data glossary that more than one team actually uses?
2. Can you tell me, right now, who owns the definition of your top 10 business entities?
3. When two domains define the same thing differently, what's the resolution process?

If the answer to any of those is "we'll figure it out as we go," you're not implementing data mesh. You're decentralizing a problem.

[Save these three questions. Ask them at your next architecture review. The answers will tell you exactly how ready your org is.]

The path forward

Data mesh is not the enemy. Premature decentralization is. The pattern works when governance provides the rails and domain teams provide the trains. Without rails, you just have expensive vehicles driving in circles.

Four words. Same order. Same answer.

If your mesh doesn't start with governance, it ends with a vendor re-platform pitch in 18 months.

Part 3 of The Governance Series by daitagov. First published on LinkedIn.