Data mesh is about ownership, not about the platform
Breaking down the data mesh concept without the hype - why it is an organisational model first and a technical stack second.
The data mesh concept appeared a few years ago and is now at peak interest. I see it in tender documents, in job descriptions, and in strategy papers from companies that have never thought about anything like it before.
The problem is that most data mesh discussions reduce it to a technology choice: which platform to adopt, how to organise storage, which cataloguing tools to use. That is the wrong entry point. Data mesh is primarily an organisational model. And if you do not sort out the organisational side, no platform will help.
What the idea is actually about
Traditionally, data in a company is collected in one place - a centralised warehouse or data lake - and served by a specialised team. This model works well up to a certain scale. Then the central team becomes a bottleneck: every domain wants data, and one team has limited throughput.
Data mesh offers a different principle. Each domain - sales, logistics, manufacturing - owns its data as a product. It is responsible for quality, availability, and documentation. The central team provides infrastructure and standards, but does not handle each domain's data manually.
The key phrase is "data as a product". This means the data has an owner who is accountable for its usefulness to internal consumers.
Why it does not work without organisational change
I have seen several attempts to implement data mesh through a technology purchase. A company buys a platform, sets up a catalogue, announces the move to a decentralised model. Six months later everything has reverted.
The reason is always the same. Domains do not want to take responsibility for data. They do not have people with the right skills. They do not have time to maintain something outside their direct responsibilities. Data continues to be updated irregularly, documentation stays stale, and consumers stop trusting quality.
Without answering "who specifically owns this data and what is required of them", moving to data mesh is just renaming the problem.
What to resolve before choosing a platform
Before thinking about technology, there are several organisational questions worth settling:
- Have you defined your domains and their boundaries? Not just the org chart, but zones of data responsibility.
- Is there a person or team in each domain capable of owning data as a product?
- How will conflicts between domains be resolved - when multiple domains need the same data?
- What is the federated function - who sets standards and monitors compliance?
- How will you measure data quality per domain?
If these questions have no answers, adding a platform will only complicate things.
When data mesh makes sense
Honestly: not for everyone. Data mesh is a solution for companies with high decentralisation, many domains evolving at different speeds, and a chronically overloaded central data team.
If you have one product, one team, and a relatively clear data flow, a centralised model with solid data engineering will be simpler and more effective.
Data mesh is not a default step forward. It is an architectural choice with specific prerequisites. Start with an organisational diagnosis, not with picking a tool.