We drew the target architecture on a whiteboard in about an hour. Domains own their data as a product. A thin self-service platform underneath. Federated governance on top. Clean. Everyone in the room agreed, and they were not wrong. Then we spent the next year and a half discovering that the picture was never the hard part.
I was running data across a consumer business with dozens of distinct units, each with its own product, its own roadmap, its own idea of what a customer even was. The old model was the one everybody has: a central data team in the middle, every pipeline routing through them, a backlog measured in quarters. Data mesh was supposed to fix that. Push ownership out to the domains who understand the data, give them a platform to publish on, and let the central team get out of the critical path.
The diagram below is the entire argument, and the entire problem.
The left side is a technology change you can ship in a quarter. The right side is a change to who owns what, and that one does not ship at all unless the org chart and the incentives move with it.
The architecture was the easy yes
Catalogs, ingestion frameworks, a templated way to stand up a data product, lineage, access control: all of it is buildable. We built it. None of it was where the rollout stalled. The technology was the part where I could point at a board and watch the burndown go down. It went down. The mesh still did not happen.
It did not happen because data mesh asks a question that has nothing to do with any of that. The question is: who, by name, is on the hook when the product team’s revenue table is wrong at 2am. In the old model the answer was always the data team, every time, which was exactly the bottleneck we wanted to kill. In the mesh model the answer is supposed to be the domain. And the domains, very reasonably, did not want it.
Nobody asked to own a data product
Here is the part nobody tells you. A “data product” sounds like an asset. To the team being handed it, it is a pager. You are telling a squad whose objectives are about shipping features that they now also run a published dataset with consumers, an SLA, a schema contract they cannot break without breaking someone downstream, and a quality bar they get paged on. We gave them the platform to do it. We did not give them a reason to want to.
That is the whole thing. Their performance review was about their product. Owning a clean, reliable customer table for the rest of the company to build on showed up nowhere in how they were measured or paid. So they did the rational thing. They published the minimum, documented less, and quietly hoped the central team would still catch the breakages. A few stronger teams leaned in because a senior engineer there cared about doing it right. Caring is not a rollout strategy.
The platform team became the bottleneck anyway
The grim joke is how the failure mode rhymed with the thing we left. We had pulled the central team out of building pipelines, and then every domain that did not want to own its product filed a ticket asking the platform team to own it for them. Onboarding help. Schema reviews. “Can you just set up this one for us.” The queue came back. Same bottleneck, new name on the door. We had decentralized the org chart on the slide and recentralized it in the support channel.
(I have watched a feature store rollout fail the same way for the same reason, which should have told me the pattern was not about data mesh at all.)
What actually moved it
Three things, and only one of them was technical.
We made ownership a real line item. Owning a data product became part of a domain’s goals, with the consuming teams as named stakeholders who could say whether the product was any good. The moment a team’s rating depended on a downstream team’s verdict, the incentive flipped from “publish the minimum” to “I do not want that team complaining about me.”
We made the platform genuinely self-serve, to the point where filing a ticket was slower than doing it yourself. That is the only honest test of a paved road. If the road is faster than asking a human, people drive on it. If it is not, your platform team is a help desk wearing an architecture diagram. We stopped accepting “set it up for us” tickets and made the setup take an afternoon instead.
And we stopped pretending every domain had to participate. Some data belongs in a shared, centrally owned core, because no single domain owns it and forcing the question just produces an orphan. Identity was one of those. We let it stay central and stopped apologizing for it. A mesh with a small, deliberate centralized core is a working system. A pure mesh you enforced everywhere is a slide.
The decomposition Zhamak Dehghani wrote up is sound, and I would not change the four principles. But they are written in the language of architecture, and that framing is what got me. The shape on the whiteboard implies that if you build the platform and define the boundaries, ownership follows. It does not. Ownership follows reporting lines and performance reviews, set by people who have never read the data-mesh paper and never will.
If you are about to roll this out, do not start with the platform. Start by finding out which teams will fight you for the pager, and why. That is the architecture. The rest is plumbing.