What federated means here
In a federated model, a central group provides some shared foundations while business units keep real ownership of other parts. The term borrows from politics, where a federation shares certain powers at the center and leaves others with member states. It sits within the broader family of hybrid operating models, but it has a particular flavor: the units are not just customers of a central service, they hold genuine authority and often their own staff.
The pattern appears most often in IT and data, because these areas have a natural split. Some things benefit from being the same everywhere, such as network connections, security tooling and core platforms. Other things benefit from closeness to the business, such as the applications a team uses daily or the datasets only that team fully understands.
What usually sits in the center
Exact splits differ, but central teams in a federated setup commonly look after:
- Shared infrastructure and platforms. The base layers that every unit relies on, such as networks, identity services and common data storage.
- Standards and guardrails. Agreed rules on security, architecture and data handling that units must follow.
- Common definitions. Shared meanings for key terms such as customer or revenue, so that figures can be compared.
- Specialist capability. Scarce skills that are hard to hire in every unit.
- Oversight. Visibility into what is running across the organization.
What usually stays local
Units commonly retain:
- Day-to-day use and configuration. How a team uses a platform for its own processes.
- Local applications and analysis. Tools and reports specific to one unit’s work.
- Data ownership. Accountability for the quality and meaning of the data the unit produces, which connects closely to data stewardship.
- Priorities. Deciding which local needs matter most, within the agreed guardrails.
For data in particular, many organizations describe the arrangement as central platform, local ownership: a common place to store and share data, with domain teams responsible for their own datasets. The idea is that the people closest to the data understand it best.
Why organizations choose it
The appeal is a middle path. A federation can keep the economies of shared platforms while avoiding a central team that must understand every local detail. It can also reduce the bottleneck of a single queue, because units can progress within the guardrails without asking permission for every step.
It is not automatically cheaper or better. The model asks more of everyone: the center must offer platforms that units actually want to use, and units must accept constraints they did not choose.
Where the seams cause friction
The boundary between central and local is where most problems occur. Common trouble spots include:
- Unclear ownership. When something breaks across the boundary, each side may assume the other is responsible. Written system ownership roles help prevent this.
- Platform fit. If the central platform does not meet local needs, units build workarounds or buy their own tools, and the shared foundation fragments.
- Standards that feel imposed. Rules created without local input may be ignored or followed only on paper.
- Duplicated effort. Several units may solve the same problem separately because no one knows the others have done so.
- Inconsistent quality. Units differ in skill and attention, so data quality can vary across the federation even with shared rules.
- Funding disputes. Who pays for shared platforms, and how, can become a recurring argument. Approaches such as chargeback and showback are one way to make costs visible, though they bring their own debates.
- Slow central response. If the center is under-resourced, units wait, and the benefit of the model weakens.
Design choices that reduce friction
No design removes the seams, but some choices make them easier to live with.
- Be explicit about decision rights. Write down which decisions are central, which are local and which are shared. Ambiguity is the main cause of conflict.
- Treat the center as a service. Central teams that measure their usefulness to units tend to build better platforms than those that simply issue rules.
- Create places for local input. Regular forums where units can raise issues help standards stay realistic.
- Provide an exception route. A defined standards exception process lets units deviate with a reason, rather than quietly working around the rules.
- Share what units learn. Simple ways to publish local solutions reduce duplicated effort.
- Review the split periodically. Boundaries that suited the organization two years ago may no longer fit.
When it may not fit
A federated model assumes units are capable of owning their share. A very small organization may lack the staff to do so, and it may be simpler to centralize or to buy services. At the other extreme, where regulation or security demands tight uniform control, a more central arrangement may be appropriate. Where units barely interact, a looser decentralized approach may be enough.
As with other models, the decision should follow the organization’s circumstances rather than fashion. Security and compliance obligations in particular should be reviewed with qualified professionals before responsibilities are divided.