Data as a Product (Data Mesh)

The idea

Zhamak Dehghani proposed data mesh in 2019 as an answer to a familiar pattern: a central data team builds a lake or warehouse, every domain pipes its data in, and the central team becomes a bottleneck that understands none of the data well. She later set out four principles:

1. Domain ownership — the teams closest to the data own it and serve it.
2. Data as a product — each domain treats the data it shares as a product with consumers.
3. Self-serve data platform — a shared platform makes building and running data products easy.
4. Federated computational governance — a small set of global standards, agreed across domains and enforced in the platform.

This page focuses on the second. A data product has an owner and consumers, and it must be usable without a phone call. Dehghani lists the qualities: discoverable (registered in a catalogue), addressable (a stable, conventional address), trustworthy (with published service levels for quality), self-describing (clear schema and samples), interoperable with other domains' data, and secure under global access policies. Each domain gains a data product owner who answers for whether consumers are served.

Why it works

Knowledge stays with the data. The domain team knows what a "policy cancellation" really means. A central team three steps away has to guess, and its guesses become everyone's reports.

Product thinking creates accountability. A pipeline has no owner once it is built. A product has someone who watches quality, handles change and cares whether people use it.

Ownership follows the organisation. By Conway's law, a single central team produces a single central bottleneck. Aligning data ownership to business domains lets the data estate scale with the number of domains.

Where it applies

• Data strategy and operating-model design, when a central data platform team cannot keep up with demand.
• Large, federated enterprises with business units or domains that already own their applications.
• Regulatory and risk reporting, where traceable ownership and lineage per dataset matter.
• Platform roadmaps, where the question is what self-serve capabilities domains need to publish data safely.

How to apply

1. Map data to domains. Use your capability map or bounded contexts to decide which domain owns which data.
2. Name owners and consumers. For each shared dataset, appoint a data product owner and identify who uses it and for what.
3. Set the minimum product standard. Agree the federated rules: catalogue entry, addressing, schema, quality service levels, access control.
4. Build the paved road. Give domains a self-serve platform that makes meeting the standard the default, so they are not each building their own pipelines.
5. Start with a few products. Pick two or three high-value datasets and prove the model before restructuring the whole estate.

Example scenario

An insurer's central data team maintained over a thousand pipelines into its lake. Claims analysts routinely found that "active policy" meant different things in different tables, and every fix waited in the central team's backlog.

The enterprise architects proposed that the policy domain publish a policy data product with a named owner, a documented schema and a daily freshness target, registered in the catalogue. The central team shifted to running the platform and the shared standards. Claims, finance and risk now consume one definition, and questions about it go to the people who run the policy system.

Questions to ask

When not to use it

• Smaller organisations with one data team and a handful of sources; a well-run central warehouse is simpler.
• Domains without delivery capacity, where handing over ownership just creates orphaned data products.

How it misleads you