Domain Data Ownership
Making the team that generates data accountable for publishing it fit for others to use, rather than handing raw extracts to a central team.
The central data team problem is structural rather than a matter of capacity. That team receives data from dozens of source systems whose semantics it does not know, is asked to model it correctly, and is blamed when a source changes without notice. Adding people does not fix a knowledge asymmetry.
Domain ownership moves the responsibility to where the knowledge is. The team
that operates the ordering system publishes order data as a product, with a
schema, stated semantics, a freshness commitment and a named owner — because they
are the only ones who know that status = 7 means partially cancelled after the
2023 refund release.
Two conditions have to hold or it fails. The domain must have the capability — data engineering skill, or a platform that makes publishing genuinely easy — otherwise ownership is a transfer of blame rather than of work. And it needs funding: publishing for others is work that benefits someone else's roadmap, and teams do not do that on goodwill for long.
The commonest failed implementation is renaming existing teams as domains, declaring ownership, and providing neither the platform nor the funding — which decentralises the problem and removes the one team that was solving any of it.