Data Mesh

The Technical Definition

Data mesh is a domain-oriented data architecture, introduced by Zhamak Dehghani in 2019. Instead of a central data team owning all enterprise data and producing datasets on request, each business domain (sales, supply chain, customer service, finance) owns its own data as a product — defined, documented, versioned, and served to the rest of the organization with explicit quality guarantees.

The four principles: domain ownership of data, data treated as a product (with consumers, SLAs, and lifecycle), self-serve infrastructure so domain teams don’t need a central platform team for every change, and federated computational governance — global standards enforced through automation rather than committee.

In practice, a mesh implementation looks like a catalog of data products, each owned by a named domain team, each with its own pipelines, its own quality monitoring, and its own contract with downstream consumers. The central data team becomes a platform team — they build the rails, not the trains.

What This Actually Means for Your Business

The diagnosis behind data mesh is correct. Centralized data teams become bottlenecks. They don’t understand the domain context of every dataset they curate. They get blamed for quality issues they couldn’t have caught. They spend most of their time triaging tickets from departments that know more about the data than they do.

The cure — moving ownership into domains — is also correct in principle. The problem is that most companies don’t have domain teams capable of owning a data product. They have business units who view data as IT’s problem and a data engineering team that’s about to be told they’re now a “platform.” The org chart change is the easy part. Building the muscle for product engineering, quality monitoring, and consumer support inside every domain takes years.

What you’ll actually see: companies announce a mesh transformation, rebrand their existing warehouse tables as “data products,” put a Confluence page next to each one, and call it done. The pipelines still break the same way. The quality issues still surface in the same meetings. Nothing changed except the vocabulary. This is mesh-washing, and it’s the most common outcome.

Reality Check

What the vendor says: “Move to a data mesh and your AI initiatives will scale because every domain owns its data.”

What that means in practice: Every domain now needs a data product manager, a quality SLA, and a support channel. If your supply chain team doesn’t have anyone who knows what an SLA is, “ownership” means “the same broken thing, with a new sign on it.” The architecture is the cheap part. The capability investment is the hard part.

What Operators Actually Do

The companies running real mesh implementations — and there are some — start with two or three high-value domains and prove the model before scaling. They invest in the platform layer (catalog, observability, lineage, access controls) before declaring domain ownership. They give domain teams real headcount — a product owner, a data engineer, an analytics engineer — not a part-time assignment for someone who already has a job.

They also accept that not every domain is ready. A mature operations team can own a forecast accuracy data product on day one. A finance team that runs everything in shared spreadsheets cannot. The realistic operators run a mixed model: mesh for the domains that can sustain it, central curation for the ones that can’t, with a clear path between the two.

For AI deployment specifically, the mesh model helps when you have multiple AI use cases hitting the same underlying data. The supply chain AI, the procurement AI, and the demand forecasting AI all want the inventory data product. If supply chain owns it as a product with documented quality and freshness, all three consumers get a stable foundation. If it’s still a 400-line SQL view nobody owns, you’ll patch the same break three times.

The Questions to Ask

1. Which domains actually have the capability to own a data product today? Be honest. Ownership without product-engineering muscle is rebranded chaos. Most companies have two to four domains that are ready and ten to twelve that aren’t.

2. What’s the platform team building first — and is it the rails or the trains? A mesh fails when the central team keeps building datasets instead of building the self-serve infrastructure that lets domains build their own. The first six months should produce a catalog, a quality framework, and a deployment pipeline, not three new tables.

3. How do you handle domains that can’t own their data? Half-mesh is a real architecture. The companies that pretend otherwise either force ownership where the capability doesn’t exist (and quality collapses) or quietly maintain a shadow central team (and pay twice).