Data mesh architecture
Definition
Data mesh architecture
A data mesh architecture is an approach that hands ownership of data to the business domains that produce it. Each domain publishes its data as a product, a shared platform makes that easy, and governance is agreed across domains rather than imposed.
The problem it attacks is the central team bottleneck. One platform group owning every pipeline becomes a queue — and the people who understand the data best are the ones standing in that queue.
A mesh is not a rival to a data lakehouse strategy. The lakehouse answers where data sits and how it is queried; the mesh answers who owns it. Plenty of meshes run on lakehouse technology.
Key takeaways
- A data mesh architecture distributes data ownership to the domains that create the data.
- Its four ideas are domain ownership, data as a product, a self serve platform and federated governance.
- It is an organisational choice, so it fails on operating model problems more often than on technology.
- A mesh can run on lakehouse storage, because the two decide entirely different things.
How it works
A data mesh architecture works by treating each domain’s data as a product with an owner, a service level and a published interface. A central platform team supplies the tooling, while a federated group agrees the rules every product must meet.
| Principle | What it means | Who holds it | Failure sign |
|---|---|---|---|
| Domain ownership | Producers own their data | Business domain teams | Ownership stays with IT |
| Data as a product | Documented, versioned, supported | Domain product owner | Nobody answers for quality |
| Self serve platform | Shared tooling, low friction | Central platform team | Each domain builds its own |
| Federated governance | Rules agreed across domains | Cross domain council | Standards drift apart |
Federated governance is the part teams underestimate. Shared definitions, interoperability standards and security rules still get agreed centrally, or your domains publish products that nobody can join together.
Data as a product means the boring things. A version, a named contact, a change log, a stated freshness and a route for complaints, all maintained by the domain that publishes it.
The idea has a clear origin. Writing on Martin Fowler’s site in May 2019, Zhamak Dehghani of Thoughtworks argued for treating data as a product owned by domains instead of pooling everything in one lake.
Evidence arrived later. A 2023 study of industry implementations describes the mesh as a socio-technical, decentralised concept for enterprise data management and notes how little field evidence existed at the time.
Someone still has to hold the shape. An enterprise architect keeps the interfaces consistent, so twelve domains do not invent twelve ways to publish the same customer identifier.
The platform itself needs running. IT managed services partners often operate the shared tooling, which keeps your central team working on capability rather than on tickets.
A mesh is business process transformation wearing a technical hat — it changes who is accountable for an output, not merely which tool produces it.
Domain products need definition before they need code. A business process analyst maps who consumes an output and what it must guarantee, which becomes the product’s service level.
Expect the resistance that business process reengineering programmes meet, since the hard part is asking a domain to support strangers who depend on its data.
Incentives decide whether it holds. If a domain gets no credit for serving other teams, its product decays into a dump with a nicer name, whatever the platform offers.
Adopt it in this order:
- Pick two domains with real, impatient consumers.
- Define each product’s interface and service level.
- Build only the platform those two actually need.
- Agree the cross domain rules before a third domain joins.
- Measure consumption, not the number of products.
Examples
Meshes appear in organisations with many semi independent domains and a central team that has already become a bottleneck. Banking, logistics and large retail groups are the common settings.
Banking. A group gives payments, lending and fraud their own data product owners, publishes documented tables with stated freshness, and keeps a cross domain council for shared definitions such as customer.
Logistics. A carrier makes the tracking domain publish one event product that every downstream team consumes — four teams no longer build four slightly different versions of the same feed.
Large retail. A group gives store operations, supply chain and loyalty their own products, with a shared customer identifier agreed centrally so the three can be joined without a reconciliation project.
Outsourced domain pods. A group with offshore delivery pods assigns each pod to a domain, so the pod owns a product rather than a queue of tickets, with the client’s domain lead accountable.
Related terms
- Business process improvement: the incremental cousin of the structural change a mesh asks for.
- Business process automation (BPA): automates the steps inside a domain once its data product is defined.
- Enterprise architect: keeps interfaces consistent so domain products stay usable across the group.
- IT managed services: often operates the shared self serve platform the domains build on.
- Business process analyst: defines what each data product must guarantee to the teams consuming it.
FAQ
What are the four principles of a data mesh?
Domain ownership, data as a product, a self serve data platform and federated governance. All four are needed, since adopting one or two produces the old bottleneck with new vocabulary.
Is a data mesh the same as a data lakehouse?
No. A lakehouse is a storage and compute architecture, while a mesh is a decision about who owns the data. You can run a mesh on a lakehouse.
When is a mesh the wrong answer?
When you have few domains, a small data team, or no appetite to move accountability into the business. A central platform is simpler at that size — and a good deal cheaper.
Who owns data quality in a mesh?
The domain publishing the product owns it, against a service level its consumers can see. The federated council sets the floor every product has to clear. Quality arguments stop being tickets and start being commitments between teams.
How long does a mesh take to adopt?
Start with two domains and a thin platform, then extend once the first products have real consumers. Most of the effort goes into ownership and incentives rather than tooling.
Explore partners that can staff domain data teams across the Outsource Accelerator network.
Independent
