Federated data ownership

Why does a central team that owns everyone's data become the reason nobody's data is good?

Every company that grows past a certain size builds the same thing: a central data team that pulls from every source system, cleans everything, and serves the whole organisation. It looks like the obvious design — one team, one standard, no duplication.

And it reliably ends in the same complaint from every direction at once. The business teams say the warehouse is out of date and the numbers are wrong. The central team says it is drowning in requests and nobody tells them when a schema changes. Both are right. That is the interesting part: nobody is behaving badly, and the outcome is bad anyway. So what is it about the structure itself that produces this?

Ask a narrow question first: when the payments team renames a column, who finds out? The payments engineers, obviously. The central data team finds out when their pipeline breaks — or worse, when it does not break and silently starts producing nonsense. Whose job was it to tell whom?

Follow the incentive. The payments team is measured on shipping payments features. Notifying a downstream consumer costs them time and yields them nothing, and the cost of not notifying lands entirely on someone else. That is not a character flaw; it is what happens when the person who can prevent a cost is not the person who bears it.

Now the other side. The central team owns a pipeline over payments data. Do they know what the data means? They know the column names. They do not know that status = 7 was a temporary hack during a card-processor migration, or that refunds before March are recorded with a positive sign. That knowledge lives in the payments team's heads. So the central team is accountable for the correctness of something they cannot actually judge — accountability without the knowledge to discharge it.

Put those two together and the pattern is clear enough to name. The structure separates the knowledge of what data means from the responsibility for its quality, and it separates the ability to avoid a breakage from the consequences of one. Scaling the central team does not fix either separation; it only adds people to the side that lacks the knowledge.

So what would the alternative look like? If the fix is to reunite knowledge and responsibility, then the team that generates the data has to own what it publishes — not just the operational database, but a deliberate, documented, versioned dataset that others are permitted to build on. That is the core move behind what Zhamak Dehghani named the data mesh in 2019: domain teams own their analytical data as a product.

But push on the obvious objection, because it is a real one. If every domain publishes its own way, do you not get sixty incompatible datasets and a worse mess? Yes — unless two things are true. First, a shared platform must make publishing a good dataset easy: storage, pipelines, access control, cataloguing, quality tooling a domain team can use without building any of it. Second, some rules must be global rather than local — how an entity is identified across domains, how personal data is handled, what a dataset must document about itself — decided jointly and, wherever possible, enforced by the platform rather than by review meetings.

Notice what the central team has become in that picture. It no longer owns anyone's data. It owns the road that everyone's data travels on. Its measure of success stops being "requests closed" and becomes "how cheap is it for a domain to publish something good".

The first misconception to head off: this is not an argument that central teams are bad, or that decentralisation is good in itself. Decentralising without the platform and the shared rules is strictly worse than the centralised version — it is the same fragmentation with nobody accountable at all. The whole proposition rests on making the good path the cheap path.

The second: federated ownership does not mean every domain reinvents its own definition of "customer". The point of the federated governance layer is that certain things — identifiers, privacy classifications, the obligation to document — are agreed globally and, ideally, checked automatically at publish time. Local autonomy over how a dataset is built; global agreement on what makes it interoperable.

The third, and it deserves plain language: this is an organisational theory, not a measured result. There is no good evidence that a mesh outperforms a well-run central platform in general, and it is a poor fit for small organisations, where three people can hold the domain knowledge and per-domain ownership buys nothing. The honest claim is narrower than the enthusiasm around it: past the scale where one team can understand every source, the bottleneck stops being technical and becomes a question of who knows what and who pays for what.

• What a data product must expose to count as one: schema, docs, quality metrics, an owner who answers.
• How computational governance works — policies checked at publish time, not in a review board.
• When a central platform genuinely is the right answer, and what scale marks the crossover.

Every term the collection defines is gathered in the glossary.