Data mesh: what it means for managers, not engineers
The data mesh concept is gaining popularity. I break down what it actually means and when it makes sense for a real business.
Over the past year the term "data mesh" has appeared more and more in conversations about data architecture. Consultants recommend it as the next step after a data lake. Data conferences dedicate separate tracks to it. Companies start writing "experience with data mesh a plus" in job postings.
I want to understand what is actually behind it in practice - not to follow a trend, but to figure out when it solves a real problem and when it is just a relabelling.
What problem data mesh solves
The classic setup works like this: there is a central data team that collects data from all sources, processes it, and provides it to business units. This works at small scale. As the company grows, the central team becomes a bottleneck: the queue of requests grows, tasks from different units compete for the same engineers, and the central team's understanding of business context is inevitably weaker than that of the people working with data every day.
Data mesh proposes a different principle: data belongs to domains. The sales team owns sales data. The logistics team owns movement data. Each team is not just a data source but the owner of a data product it provides to others.
What it means in practice
Four principles make up the concept:
Domain ownership. Data belongs to the team that best understands its nature and meaning. Not to the central data team.
Data as a product. Each domain provides data to others with explicit quality standards, documentation, and availability commitments - like an internal product.
Self-serve infrastructure. A platform team creates tools that allow domain teams to work with data without requiring specialized expertise each time.
Federated governance. Common standards - formats, access policies, quality requirements - are set jointly, not dictated from above.
When this makes sense
The key word is scale. Data mesh solves the bottleneck problem of the central team. If you do not have a central data team and do not have a queue to it - the concept solves a problem that does not exist.
Signs that data mesh may be relevant:
- the company is large enough that data from different business units lives separately and requires different expertise;
- the central data team is overloaded and cannot service all requests;
- business units complain that the data they need is unavailable or stale;
- the existing data lake became a swamp - data exists but nobody knows which parts to trust.
For a company with one analytics team and a couple of data sources, this is an oversized solution.
What this means for the owner
Implementing data mesh is not a technical project. It is an organizational change. It requires business units to take responsibility for the quality of their data. That is concrete work by specific people - not a one-time configuration.
Questions worth asking before launching such a project:
- Are business unit leaders ready to own the quality of their domain's data?
- Do those units have enough technical competence, or does it need to be built?
- Who will maintain the shared platform and standards?
- How will we measure that things have improved?
If there are no answers - answer first, then decide whether the concept fits.
Data mesh is a good idea for the right context. Like most good ideas in architecture, it is not universal.