Somewhere in the world right now, a leadership team in a boardroom is approving a multi-million dollar investment in a "Data Mesh Platform." The vendor has been impressive. The demo was slick. The architecture diagram looked exactly like the one from Zhamak Dehghani's book.
Six months down the line, that organisation will have a world-class data platform. A modern lakehouse. A unified catalog. Automated lineage. Federated governance policies written in code.
And... a central team doing exactly what it was doing before — fielding tickets, building pipelines, owning everything — with no understanding of the business domains it serves.
You cannot buy a data mesh. You can only build one — by changing how your organisation thinks about accountability for data.
This is the most important thing to understand before your organisation spends a single dollar on tooling. And it is the thing that almost always evades the decision makers.
Expected global size of the Data Mesh market in 2026, up from $1.74B in 2025 (360iResearch)
of enterprise AI projects without AI-ready data will be abandoned through 2026 (Gartner)
of organizations report high maturity in data readiness, integration, or governance (World Economic Forum, 2026)
The numbers tell a clear story. Enterprises like the idea and want to invest in it. The market is growing. But the failure rate is staggering. Why?
Because most organisations are buying the tool and skipping the transformation. In many cases, the organisational chart remains unchanged. Before we get into why that keeps happening, let us first define what a data mesh actually is — in plain English, not vendor language.
What Is a Data Mesh?
Data Mesh is a way of organising data ownership around business domains. Instead of relying on a centralised data team to manage and serve all analytical needs, Data Mesh places responsibility for data with the domain teams that create and understand it.
The teams that generate and use the data are also responsible for managing, maintaining, and sharing it. They treat their data as a product — something that can be discovered, trusted, and consumed by others across the organisation. We will dig into that very important concept in the next part of this series.
Why the shift? Why move away from centralised to decentralised? Quite a few good reasons. Let us contrast with what centralised data architectures actually produce.
The bottleneck problem
In the centralised model, every single data request — a schema change, a dashboard update, a new view — from every department flows into a single monolithic backlog managed by one central IT data team. One team cannot deliver everything to everyone. At bigger scale, even a small request can feel like it takes an eternity.
Data Mesh solves this by applying the same pattern that changed software engineering — microservices architectures. Organisations moved from monoliths to decomposed, domain-managed services. Data Mesh applies this proven concept of decomposition and decentralisation to the data plane. By giving ownership back to the domains, you distribute the engineering workload and scale horizontally.
Domain blindness
The central data team is highly skilled in technology. But they are not domain experts. They do not understand the underlying business nuances, shifting rules, or operational context of the Sales, Finance, or Marketing data they are managing. To a domain-blind engineer, a string is a string and a row is just a row — they normalise the schema but lose the business context. The further data travels from its source, the more context it loses.
Data Mesh fixes this by shifting accountability directly to the domain experts. Those who understand the business context are the ones writing the data logic. By embedding deep business context directly into a self-describing data product, accountability for data trustworthiness is closer to the source.
The AI forcing function
Pause and think for a moment. A central data lake with no semantic context — how well do you think an AI agent will make sense of that data?
Some will say it has worked fine so far. And they are right — sort of. It worked because humans are very good at working around problems. Call a fellow engineer. Ask a domain expert. Fix it. But AI agents do not make those calls. They act on whatever they find. A well-implemented Data Mesh encourages domain teams to capture and maintain business semantics closer to the source. And it is precisely those semantics that make autonomous exploration of data possible — enabling AI agents to discover and use data without human intervention. Data Mesh increases the likelihood that data semantics are maintained close to the source, which becomes increasingly important as AI systems consume more enterprise data.
Decentralisation — A Proven Paradigm From the Operational Plane
Before the era of microservices, software engineering faced the exact same problem that data faces today. Organisations built massive monolithic applications — all managed by a single central team. Need a small feature update? Push it into a giant central backlog. The result was slow turnaround, slower innovation, and high cost of failure.
The software world fixed it by decomposing the monolith into agile microservices. Individual domain teams were given end-to-end accountability for their specific application. The result? Agility, faster feature rollouts, shorter experiment cycles, and a dramatically lower cost of failure.
Data Mesh is fundamentally that same pattern — already proven more than a decade ago in the operational plane — now applied to the data plane. The idea is not radical. It is overdue.
Social or Technical or Both?
Zhamak described data mesh initiatives, quite aptly, as sociotechnical. This is the most important point to understand.
Go back to the operational plane. When organisations decomposed monoliths into microservices, the domain teams had to first believe in the model. They had to understand the benefits, internalise the shift, and commit to the accountability that came with it. The technology followed conviction — not the other way around. Domain teams that were not convinced never sustained the change.
The same is true for data mesh. Organisations that treat it as a technology upgrade — buy the platform, spin up the catalog, call it done — are guaranteed to fail. The domain teams must first appreciate the agility and innovation that domain ownership unlocks in the analytics plane. When they understand what it does for their ability to make data-driven decisions, the tooling becomes the easy part.
Technology without conviction is expensive furniture.
Understanding Data Mesh is the easy part. Implementing it is where most organisations stumble. Giving domains ownership sounds simple until budgets, engineers, governance, and accountability enter the conversation. Entire transformations have failed on these questions alone.
We will dedicate a future article in this series to why enterprises struggle to implement Data Mesh and what successful organisations do differently.
The Four Principles
1. Domain-Oriented Ownership
The people closest to the data own the data. The sales team owns and maintains the sales data — not the central data engineering team. If a data quality issue surfaces, the sales team is responsible for fixing it. For this to work, domain teams must be genuinely empowered — with budget, data engineers, and real accountability. Ownership without authority is just blame.
2. Data as a Product
Domain teams apply product thinking to their datasets. A raw dump or a messy schema with no documentation is not a data product. A true data product is discoverable, secure, natively documented, and bound by a strict data contract to its consumers — whether those consumers are humans or AI agents.
3. Self-Serve Data Infrastructure
Domain teams must be able to build and share their data products without wrestling with raw infrastructure. A central platform team in a mesh is responsible for creating the tooling that makes domain ownership tractable. If domain teams have to worry about provisioning pipelines and configuring storage, the agility benefit disappears. The platform team clears the path. Domain teams run on it.
4. Federated Computational Governance
The words federated and computational are critical here. Standards for interoperability, security, and schema validation are defined by a federated council of domain experts — not imposed by central IT. And these standards are enforced computationally — embedded directly into the platform's automated pipelines, not policed by a governance committee reviewing spreadsheets once a month.
The Question to Ask Before Spending a Dollar
Before your next data platform evaluation, ask your leadership team this:
"Are we willing to give domain teams real accountability — with the budget, the data engineers, and the structural authority that accountability requires?"
If the answer is yes, you are ready to build a data mesh. If the answer is no — even remotely no — then any platform you buy will become a dead investment. You will end up with a shinier, better-looking version of what you already have. Just as slow. Just as painful. With a bigger price tag.
And What to Ask After You Decide to Implement
Deciding to implement is only the beginning. These are the questions that tell you whether the transformation is actually taking hold — not whether the platform is running:
Has turnaround time improved? Domain teams owning their data should mean faster response to analytical requests — not longer. If it has not improved, the ownership shift has not happened yet.
Are domain teams actively publishing data products? A catalog with entries created by the central team is still a centralised model in disguise. Domain teams publishing their own products is the signal that accountability has genuinely moved.
Are those products being used? Published but unused data products mean discoverability or trust is still broken. Someone needs to investigate why consumers are not relying on what domains are producing.
Has executive confidence in the data platform improved? The ultimate test. If leadership is still working off separate spreadsheets or asking for manual reports, the mesh has not yet delivered on its promise.
Further reading: Approach Your Data With a Product Mindset — Harvard Business Review. A sharp, accessible read on why product thinking transforms the way organisations relate to data.
Coming next — Part 3: Data as a Product vs Data Products — Most organisations are calling their pipelines data products. Here is how to tell the difference, and why it matters more than ever.