Data mesh has become one of the most discussed architectural patterns in enterprise data over the last few years. The core ideas — domain ownership of data, data as a product, self-serve infrastructure, federated governance — address real problems that centralized data teams struggle with at scale.
What I observe in practice is something different: organizations adopting the language of data mesh without making the organizational changes that data mesh actually requires. The result is data mesh in name only, with the added complexity of a distributed architecture and none of the benefits.
What Data Mesh Is Actually Proposing
Before discussing why implementations fail, it's worth being clear about what the pattern actually requires.
Data mesh is not primarily a technical architecture. It's an organizational model. The central claim is that data should be owned, managed, and served by the domain teams that generate it — not by a central data team that acts as an intermediary.
For that to work, domain teams need to be able to do the work. They need data engineering capability, not just business knowledge. They need tooling that lets them build and operate data products without being blocked by a central team. They need accountability for the quality of the data they produce, with metrics that are visible.
In most organizations, none of these conditions exist. Domain teams don't have data engineering capability. The tooling isn't in place. There's no accountability structure for data quality at the domain level. The organizational changes required to create these conditions are significant and slow.
What Organizations Actually Implement
What I observe instead:
Renamed teams, unchanged accountability. The central data team becomes the "data platform team." Domain teams are told they now "own" their data. But the data platform team still builds most of the pipelines, still manages most of the infrastructure, and domain teams still escalate data quality issues to them rather than resolving them. The vocabulary changed. The accountability didn't.
Distributed architecture without distributed capability. Some organizations implement the technical pattern — domain-owned data products, a central catalog, shared infrastructure — but the domain teams don't have the skills to maintain what they nominally own. The technical distribution creates coordination complexity without the organizational distribution that would justify it.
Federated governance without federated decision-making. A governance council is formed with representatives from domain teams. But the council operates like a traditional governance committee — central staff prepare the agenda, central staff implement the decisions, and domain team representatives attend meetings but don't make meaningful decisions about their data.
Where It Actually Works
Data mesh implementations that work share a few characteristics that are worth being specific about.
The domains are large enough to justify dedicated data capability. A domain team of fifteen people producing a data product for internal consumption doesn't need a dedicated data engineer. A domain team of two hundred people producing data that feeds regulatory reporting, actuarial models, and management reporting probably does. The pattern works at a certain scale of domain complexity; below that, the overhead isn't justified.
The organization has genuinely decentralized accountability. This is the hard one. In most financial services organizations in Turkey — as in most large enterprises globally — accountability is centralized. Decisions flow from the top. Resources are allocated centrally. The domain team "owner" of a data product has accountability in title but not in practice. Data mesh requires real decentralization, which is an organizational culture change, not a technical project.
The infrastructure genuinely enables self-service. The platforms exist, work well, and can be used by domain teams without significant central support. This is rare — most "self-serve data platforms" require significant hand-holding in practice.
What to Do With This
If your organization is considering data mesh, the honest questions to ask before starting are:
Do your domain teams have data engineering capability today, or would you be building it from scratch? How long would that take, and what would it cost?
Is accountability for data quality genuinely distributed in your organization, or does it concentrate in a central team when things go wrong?
Is the scale of your data operations large enough that the coordination overhead of a distributed model is justified by the autonomy it creates?
If the answers are unfavorable, adopting data mesh vocabulary and architecture without the organizational foundation will add complexity without the benefits.
Data mesh is a useful pattern for the right organizations in the right conditions. Most organizations are not in those conditions. The honest move is to understand what problem you're actually trying to solve and pick the approach that solves it — not the approach that's generating conference talks this year.