An organisation is considering data mesh. What problem does it actually solve, what does it require, and when is a central platform team the better answer?

The problem it addresses

A central data team becomes a bottleneck. Every new dataset, every pipeline change and every question queues behind it, and the team lacks the domain knowledge to model data it did not produce — so they build what they were asked for rather than what was needed, slowly.

Meanwhile the domain teams who understand the data have no responsibility for it beyond their operational database.

Data mesh's answer: domain teams own their analytical data as a product, with a central platform team providing the infrastructure rather than the pipelines.

What it actually requires

The requirements are substantial and are what determine success:

• A genuinely self-service platform. If domain teams must build pipelines from scratch, they will not — they have their own priorities. The platform must make publishing a data product straightforward, and this is the largest single investment.
• Domain teams with capacity and skill for data engineering, or an embedded data engineer per domain. This is usually the binding constraint and it is routinely underestimated.
• Data products with contracts: defined schema, documented semantics, quality guarantees, a change policy, and a named owner. Without contracts it is not a mesh; it is a decentralised mess with a new name.
• Federated governance: global standards for interoperability — identifiers, classifications, security policy, quality expectations — decided centrally and implemented locally.
• Discoverability, so consumers can find and understand products without asking.
• Genuine accountability. A domain team that publishes a product and does not maintain it has made things worse, and there must be a consequence — which is an organisational matter rather than a technical one.

When a central team is better

• A small organisation. Below a certain size the central team is not a bottleneck, and the coordination overhead of federation exceeds its benefit. Mesh is a solution to a scale problem and creates overhead at small scale.
• Domain teams without data capability or capacity, where distributing responsibility distributes it to people who cannot discharge it.
• Heavily cross-domain analysis, where most questions span many domains and someone must integrate — which is central work regardless of who owns the sources.
• Strict uniform compliance requirements, where central enforcement is simpler and more defensible than federated implementation.
• No platform investment available, in which case decentralisation produces inconsistent quality and no self-service.

The honest position

The valuable ideas are separable from the whole. Domain ownership of data, data as a product with contracts, self-service platform capability, and federated standards are individually valuable and can be adopted incrementally.

The failure mode is adopting the vocabulary and not the requirements: renaming teams, calling tables "data products", and declaring ownership without giving domains the platform, the capability or the accountability to discharge it — which produces a central bottleneck plus a distributed one, and is worse than either.

The useful question is not "should we do data mesh" but "is our central team a bottleneck, and do our domain teams have the capability to own this?" Both answers must be yes.