Data Mesh

What it is

Its originator describes it as founded in decentralisation and the distribution of responsibility to the people who are closest to the data. Domains provide their data as products; a platform team provides the means; governance is federated between them.

It is an operating model more than a technology. No product is a data mesh, and adopting one changes who is responsible for what.

Why it matters

Studies of real implementations report difficulty with federated governance and with shifting responsibility for data products. It suits organisations with several capable teams, not every organisation.

A review of practitioner literature concludes that a data mesh is not a one-size-fits-all approach for data management. Both studies DII has read are preprints; one is based on 15 interviews and has three authors at a vendor.

The problem it addresses

DII editorial view

A central data team that owns every dataset becomes a queue: it lacks the domain knowledge to model the data well and the capacity to serve every request. Data mesh moves responsibility to the domains that understand the data. It works only if those domains can take the work on.

Business and organisational relevance

DII editorial view

The decision is about organisational readiness. A mesh asks business domains to take on work a central team did before, and asks the centre to give up control while keeping standards.

Practical use cases

• Large organisations where a central data team has become a bottleneck
• Domains with the skills and the will to own their data as products
• A shared self-service platform with governance agreed across domains

Benefits and opportunities

• Responsibility sits with the people who understand the data
• A central team is no longer in the path of every request

Risks, limitations and dependencies

• Federated governance is reported as hard to make work
• Domains may lack the engineering capacity the model assumes
• Adopted as a technology purchase, it changes nothing

Prerequisites for adoption

DII editorial view

• Several teams with the skill and the will to own data as products
• Governance that already works, so standards can be federated
• Platform engineering capacity to provide self-service

Implementation considerations

• Test the preconditions first. You need several teams able to own data products, working governance and platform engineering capacity.
• Start with one or two domains. Prove the model where it is most likely to work before extending it.
• Decide what stays central. Federated governance still needs standards that every domain follows.

The DII Radar assessment

Approved DII Radar assessment

DII assesses Data Mesh as Moderate relevance, with direction Stable. Its strategic impact is assessed as Moderate and its enterprise adoption as Emerging. It is in the catalogue and is not one of the ten entries on the current Radar.

DII relevance is our assessment of current significance and momentum, based on evidence, market development and adoption. Direction is the observed trajectory of relevance and adoption. Strategic impact is the potential or current significance to enterprise data capability, and enterprise adoption is the extent of current real-world enterprise adoption; together they set the position on the Radar. The Radar is not a prediction, vendor comparison or performance ranking.

Evidence basis: Dehghani, Data Mesh Principles (2020); Bode et al., industry insights from data mesh implementations (2024, preprint); Goedegebuure et al., grey literature review (2024, preprint).

What to consider next

DII editorial view

• Test the preconditions first: capable teams, working governance and platform capacity
• Start with one or two domains
• Decide which standards stay central