We had the target architecture inside an hour, drawn on a whiteboard, and the speed of it should have worried me more than it did. Domains own their data as a product, a thin self-service platform underneath, federated governance on top. It looked clean, everyone in the room agreed, and they were not wrong to. What none of us clocked that afternoon was that the picture had never been the hard part, and the next year and a half made sure I understood why.
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 by pushing ownership out to the domains who understand the data, giving them a platform to publish on, and getting the central team 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, and we built it. None of that was where the rollout stalled. Technology was the piece I could point at on a board and watch the burndown fall, and it fell, right on schedule. The mesh stayed exactly as far off as it had been the day we drew it.
The stall had nothing to do with any of that. Data mesh asks a different question entirely: 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
A “data product” sounds like an asset right up until you are the one being handed it, and then 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, but not a single reason to want to.
The reason was sitting in the performance review. Their rating was about their product, and 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. Faced with that, they did the rational thing and published the minimum, documented less, and 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 was how closely the failure mode rhymed with the model we had just 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, the same bottleneck with a 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 moved it, 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: when it is faster than asking a human, people drive on it, and when it is not, your platform team is a help desk wearing an architecture diagram. We stopped accepting “set it up for us” tickets and got the setup down to an afternoon.
We also 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, so we let it stay central and stopped apologizing for it. A mesh with a small, deliberate centralized core is a working system, while a pure mesh you tried to enforce everywhere stays a slide.
The decomposition Zhamak Dehghani wrote up is sound, and I would not change the four principles. They are written in the language of architecture, though, and that framing is what got me. The shape on the whiteboard implies that once you build the platform and define the boundaries, ownership follows. In practice it follows reporting lines and performance reviews instead, set by people who have never read the data-mesh paper and never will.
None of that was on the whiteboard we filled in during that first easy hour. The real architecture was the answer to a smaller, uglier question: which teams would fight me for the 2am pager, and which would file a ticket to hand it straight back. Everything else was plumbing, and I think I knew it even as we capped the markers and admired the boxes on the wall.