IT operating model

Centralized, federated or both: how to structure IT

Reorganizations rarely fix what people wanted fixed, because the problem was usually who decides rather than who reports to whom.

Updated September 2026

The short version

Decide what is central by what breaks if it is done differently in each place.
Reporting lines matter less than decision rights, funding routes and standards.
Federated works when the standards are real and enforced. Otherwise it is fragmentation with a nicer name.
Most organizations need a hybrid, and the work is defining the boundary precisely.

The centralize-or-federate question usually arrives as a reorganization proposal. It is worth answering the underlying question first, because the structure that follows is often not the one being proposed.

Ask what actually breaks when it varies

The useful test for anything: what happens if each business unit does this differently?

Identity, security, network, data protection. Varying these creates risk that crosses boundaries. Central.
Core financial and HR systems. One version of a transaction, one version of an employee. Central.
The standards for integration, architecture and data definitions. Set centrally, applied everywhere, or every project renegotiates them.
Tools that support a specific operation. A scheduling system for one business line, a specialist application for one site. Local, unless something forces otherwise.
Prioritization within a business unit’s own budget. Local. Central prioritization of local work is how IT becomes a bottleneck.

Separate the four things people conflate

“Centralized” is usually shorthand for four separate decisions, and they do not have to move together:

Who reports to whom. The least important, and the one the reorganization is about. Who decides. Which choices need central agreement and which do not. Who funds it. Central budget, business unit budget, or a shared model. Who sets standards. And whether those standards have teeth.

Most of the pain attributed to structure comes from the second and fourth. It is possible to have a federated reporting line and genuinely consistent architecture, and it is common to have a centralized team and no standards at all.

Federated only works if the standards are real

Federation with strong standards is a legitimate model: local teams move fast within boundaries everyone accepts. Federation without enforced standards is fragmentation, and it produces the estate everyone complains about — duplicate systems, incompatible data, integration built per project.

If you are federating, the question to answer first is what happens when someone does not follow the standard. If the answer is nothing, you have not federated.

The hybrid most organizations land on

A central group holding platform, security, architecture, data and the shared applications, with business-aligned people embedded in each unit who understand that unit’s work and carry demand back in.

The two hard parts are the boundary and the embedded role. The boundary needs writing down in enough detail that a new request can be routed without a meeting. The embedded role fails when it becomes an order-taker with no authority, which happens whenever the central group treats its requests as queue items.

What to fix before restructuring

Decision rights, funding routes and standards. If those three are clear, the structure question gets much smaller — and sometimes disappears, because the thing people wanted from the reorganization was one of the three.

Who does this work