A central team that reviews every dataset and approves every access request looks like control. In practice it is a queue, and every team that needs data faster routes around it.
The difference is where the rule runs.
The common pattern: a central team owns every policy and gates every access request, so domains copy and shadow the data to ship on time.
The approach that works: domains own their data, the council sets shared rules once, and the platform enforces them automatically across every domain.
There are three: centralized, federated, and hybrid. They differ on one axis, who owns the data and who sets the rules.
This is the shift that removes the bottleneck. The governance council sets the shared standards but does not approve individual datasets or access requests.
Define the small set of rules that apply everywhere once: definitions, access, quality, lineage, retention, and privacy.
A side-by-side of centralized, federated, and hybrid governance: how each one works, who owns the data, and the scale and domain maturity each one suits.
Domain ownership, data as a product, a self-serve platform, and federated computational governance.
A clear map of who owns what and who decides what across the data owner, data steward, governance council, and platform team
How active metadata turns a stale catalog into the control plane that captures lineage.
A central governance team that reviews everything becomes the queue every domain routes around, and then you have neither speed nor control.
It is the operating model that decides who owns your data, who sets the rules, and where those rules are enforced. This framework lays out three models, the federated approach that scales, the roles and decision rights behind it, and the shared policy components that every domain has to meet.
Federated governance, also called data mesh, gives domains ownership of their own data and decisions while a central function sets shared standards without gating the work. It rests on four pillars: domain ownership, data as a product, a self-serve platform, and federated computational governance where global rules run in code and local decisions stay in the domain.
Chief Data Officers and data platform leaders who have tried the central model and watched it stall. If your governance has become a queue that teams route around, this framework gives you the operating model, the roles, and the enforcement approach to fix it.
A central team that reviews every dataset and approves every access request faces an impossible choice: be thorough and become the bottleneck every domain waits behind, or keep pace and wave requests through without understanding the data. Either way, teams that need data to ship copy it, shadow it, and build around the governance layer, so you end up with less control than you started with.
The data owner owns a domain's data products and access policy. The data steward owns day-to-day quality, definitions, and metadata. The governance council sets the global rules every domain must meet but does not approve individual datasets. The platform team builds and runs the tools that enforce those rules in code but does not write the rules or own the data.
