A data mesh is a way of organising data in which no single central team owns everything. Instead, each domain - purchasing, transport, warehousing, finance - owns the data it produces and delivers it as a product the rest of the organisation can build on.
It is not a product you buy and not a tool you install. It is a decision about who owns what. The term comes from Zhamak Dehghani's work (2019) and became popular with organisations that found their central data team could not scale with demand.
Why the idea appeared
The classic setup is a central data team that unlocks every source. That works while the number of sources is small. As the organisation grows, a queue forms: every new question goes through the same team, which has to guess what the data means because it does not do the work itself. The team becomes the bottleneck and, at the same time, the place where most errors creep in.
The same work, but meaning comes from a different place.
A mesh turns that around. The planner who knows when an order is genuinely ready records that definition. Not an analyst deriving it from a column name.
The four principles
Four agreements that together make a mesh. Separately they do not work.
Ownership per domain. The people doing the work own the meaning of the data that comes out of it. That also means the domain is accountable when a delivery is late or wrong, not the central team.
Data as a product. A dataset is only finished when it has a description, an agreement about quality and freshness, and a named contact. A product has users, and those users are entitled to expect something.
The platform as self-service. Domains must not each build their own infrastructure. One platform, built well once, that everyone serves themselves from: storage, processing, catalogue, access, monitoring.
Governed, not left loose. Access, definitions and traceability are enforced centrally so autonomy does not become sprawl. In the literature this is called federated governance: policy is central, delivery sits in the domain.
The first two are about people, the last two about technology. Organisations that only do the last two end up with an expensive platform and the same argument about numbers as before.
What a data product looks like in practice
"Data as a product" stays abstract until you write it down. A usable data product has six things:
- A name and a purpose. For example: orders ready to ship, used by planning and customer service.
- A definition in words. When is an order ready: when the last line is picked, or when the pallet is weighed and labelled? One of the two, written down.
- A shape. Which fields, which units, which keys, and what happens when a field is empty.
- An agreement on freshness and quality. Refreshed every fifteen minutes, at most 0.5 percent of rows without a weight, and an alert when it falls outside that.
- A named owner. Not a department: a person who is accountable and has a stand-in.
- Traceability. For every field you can see which source system it came from and which transformations were applied.
Those six points together are what we call a data contract. Without that document, a data product is just a table with a nicer name.
Which roles you need
A mesh asks for three roles that many organisations do not have yet.
The domain owner is accountable for meaning: which definition applies and what the organisation may expect. This is a business role, not a technical one.
The data product engineer builds and maintains the delivery. In smaller organisations this is someone from the domain with time and access, not necessarily a specialist.
The platform team builds the self-service layer and enforces policy. It no longer delivers datasets on request. That shift is bigger than it sounds: the team moves from data supplier to road authority.
Where it goes wrong in practice
Three patterns keep recurring.
Ownership without capacity. A domain is made owner in a steering committee but gets no hours and no mandate. Quality then drops rather than rises, because the central team lets go and the domain does not pick up.
A mesh without a platform. Every domain builds its own pipelines, with its own choices for storage and permissions. After a year you have no mesh, but four small central teams that cannot read each other's work.
A platform without agreements. The technology stands, the definitions do not. Two domains both deliver "revenue", calculated two ways, and the meeting is back where it started.
When a mesh does not fit
With two sources and one analyst, a mesh is overhead. It pays off once several domains deliver data at the same time and the queue at the central team is noticeable: questions that sit for weeks, or reports that coexist because nobody knows which one is right. It also does not pay off when the organisation cannot or will not assign ownership. A well-run central setup with recorded definitions is then more honest and cheaper.
How to start: one domain, one product
Five steps you can take in weeks, not quarters.
Start with one number the board leans on every month and that currently has more than one answer. Name the domain that does the work, write the contract, publish the delivery as a product, and then measure who uses it and where it drifts.
That last step is the one most often skipped and the one that pays back most: without usage measurement you do not know whether your product is trusted, and therefore whether the next domain should follow the same pattern.
What has to sit underneath
Underneath a mesh sits an ordinary platform: storage in an open format, one catalogue, lineage per field and access per role. In many environments that is a lakehouse, for example on Databricks. How those layers relate is covered in what is data architecture. How we build and run that layer is described on the engine.
One domain, one data product, one number the board leans on. Once that holds up to scrutiny, the rest follows.
