What Is a Data Mesh? Domain Ownership of Data, Explained

A data mesh decentralizes analytical data: each business domain owns the data it produces and publishes it as a product with a contract, on a shared self-serve platform, under federated governance. It is the microservices argument applied to data, with the same trade: the central bottleneck goes away, and a coordination problem takes its place.

A data mesh is a decentralized approach to analytical data, coined by Zhamak Dehghani at Thoughtworks in 2019, in which the teams that produce data own it and publish it as products for the rest of the organization to consume. It stands on four principles: domain ownership (the payments domain owns payments data), data as a product (published with a contract, documentation, and quality guarantees), a self-serve data platform (shared infrastructure so every domain does not rebuild pipelines), and federated computational governance (global standards, enforced in the platform, agreed across domains). The pattern exists because the centralized alternative, one team ingesting everything into one lake, stops scaling at exactly the point where the organization has more domains than one team can understand. For a systems analyst, the mesh is instantly familiar: it is the architecture conversation you already have about services, replayed about data.

What does the shift actually look like?

The clearest way to see the mesh is against the model it replaces:

In the top model, the payments team ships a change and waits for the central team to re-model it; the central team, who never read a pacs.008 in their lives, guess at the semantics; consumers inherit the guesses. In the mesh, the payments domain, the people who actually know what a settled payment is, publish settled-payments as a product with a schema, a freshness guarantee, and an owner, and everyone else builds against that contract.

Why “data as a product” is the load-bearing principle

Domain ownership without product discipline is just silos, which is what most organizations had before central lakes were invented. What makes the mesh different is that each domain’s data is published as a product: discoverable in a catalog, documented, addressable, quality-guaranteed, versioned, and owned by someone whose job includes its consumers’ success. That list should sound familiar, because it is the definition of a good API applied to data, and everything you know about API contracts transfers.

The transfer is practical, not rhetorical. A data product’s schema is a contract, so a breaking change to it should fail before it ships, which is contract testing for tables. Its field definitions need a data dictionary, because “amount” is ambiguous in data products for exactly the reasons it is ambiguous in messages. Its freshness and quality guarantees are requirements an analyst can specify and test: rows arrive within N minutes of settlement, no duplicate UETRs, completeness reconciled daily against the source. When a domain cannot state those guarantees, it does not have a data product; it has a table with a README.

What do the platform and governance actually do?

The self-serve platform exists so that “domains own their data” does not mean “every domain builds its own ingestion, storage, quality tooling, and access control from scratch.” The platform team provides those as paved-road capabilities, and domains use them to build products, the same division of labor as a good internal developer platform. Internally, a domain often organizes its own pipeline as a medallion architecture, publishing its gold tables as the product surface.

Federated computational governance is the answer to the obvious failure mode: thirty domains, thirty incompatible definitions of everything. Representatives of the domains agree the global rules, how entities are identified, how currency amounts are represented, what “settled” means across products, what security classifications apply, and, critically, the rules are enforced computationally in the platform rather than in a policy document nobody reads. Interoperability is the whole point: the fraud domain’s product must join cleanly to the payments domain’s product, which only works if both keyed the payment by the same identifier, the same lesson as carrying the UETR across a payment flow.

When is a mesh the wrong answer?

The mesh solves a scaling problem, so if you do not have the scaling problem, you inherit its costs for nothing. A company whose data fits in one team’s heads gets no benefit from distributing ownership; it gets coordination overhead, duplicated effort, and a governance forum. The honest prerequisite check is organizational, not technical: are there genuinely more domains than a central team can understand, and are the domains capable of, and incentivized for, real product ownership? Without both, the mesh degrades into either the old central bottleneck wearing new vocabulary or the old silos wearing new vocabulary.

For a business analyst, that makes the mesh assessment familiar territory: it is a fit-gap analysis where the requirements are organizational. The analyst’s contribution in a mesh, meanwhile, gets sharper, not smaller: every data product needs its contract specified, its quality guarantees written as testable requirements, and its definitions pinned down, which is requirements work aimed at data.

The takeaway

A data mesh decentralizes analytical data along four principles: domains own their data, publish it as products with contracts, build on a self-serve platform, and interoperate under federated governance enforced computationally. It trades the central-team bottleneck for a coordination problem, which is a good trade exactly when the organization has outgrown one team’s understanding, and a bad one before that.

Treat every data product like an API: demand the contract, the dictionary, the owner, and the quality guarantees, and test them like you would any interface.