Enterprise architecture operating models: how to choose centralised, federated, or hybrid

An enterprise architecture operating model is not an org chart.

It is the system of decision rights, governance routes, escalation paths, and engagement rules that determines whether architecture helps the business move faster or quietly becomes another layer of friction.

That is the real issue.

Most organisations do not fail at enterprise architecture because they lack frameworks, smart people, or tooling. They fail because the operating model is weak. Architecture gets set up as a function, but not as a working system. So the team produces artefacts, attends meetings, and writes standards, yet still has little influence on what gets built.

That is why architecture so often gets labelled as bureaucratic, disconnected, or slow. The problem is usually not architecture itself. The problem is how it is wired into the enterprise.

This guide explains how to choose the right enterprise architecture operating model, how to design governance that people will use, and how to stop architecture becoming a bottleneck.

What this article covers

• What an EA operating model is

• Why many architecture functions become ineffective

• The real difference between centralised, federated, and hybrid operating models

• How to choose the right model based on business context, risk, and delivery reality

• How to design governance forums, architecture boards, and decision thresholds properly

• How to make architecture visible and useful without creating unnecessary drag

Enterprise Architecture Operating Model: Why it is usually an afterthought

The uncomfortable truth is most EA teams do not have an operating model

Most have a team structure.

That is not the same thing.

Hiring architects, buying a repository tool, writing principles, and setting up an architecture review board does not mean you have an operating model. It means you have components. The operating model is the logic that makes those components work together in a repeatable way.

If the business does not know:

• when architecture must be engaged,

• who can make which decisions,

• what needs approval,

• what can be decided locally,

• what gets escalated,

• and how long decisions should take,

then you do not have an operating model.

You have ambiguity.

And ambiguity always gets filled by politics, workarounds, and local behaviour.

That is where architecture debt starts.

Why enterprise architecture governance usually goes wrong

The pattern is common.

An organisation creates or refreshes its EA function. The early focus goes into frameworks, target states, principles, standards, and hiring. That all feels sensible. It is visible work. It looks strategic. It gives the team something to point to.

Then reality catches up.

Projects start without architecture involvement. Business leaders see architecture late and view it as a delay. Architects get pulled into too many reviews. Governance forums multiply. Exceptions pile up. Decision-making becomes inconsistent. Some teams bypass architecture entirely. Others escalate everything.

At that point leadership asks the question that should have been answered first:

How is architecture supposed to operate here?

That question is the operating model question.

Why this happens

There are five common reasons.

1. Architecture is treated as a specialist function instead of an enterprise capability

Leadership often sees EA as a technical discipline. So the focus goes into methods and artefacts. But architecture is not just a technical discipline. It is an organisational coordination mechanism. If the coordination model is weak, the technical quality of the architecture team does not save it.

2. Decision rights are politically sensitive

Operating model design forces the organisation to answer awkward questions.

• Who has the final say?

• Can a business unit ignore enterprise standards?

• Does the architecture board approve or advise?

• Can product teams choose their own tools?

• Who decides on platforms, data patterns, AI guardrails, and integration standards?

These are power questions. That is why many organisations postpone them.

3. Governance is designed too late

By the time architecture governance gets formalised, informal behaviour is already embedded. Projects know how to bypass review. Business units have already built local patterns. Procurement routes already exist. Exceptions already became the norm.

Late governance is usually clean on paper and messy in practice.

4. Frameworks do not solve this for you

Frameworks can help with structure, taxonomy, and method. If you need the broader landscape, see our guide to enterprise architecture frameworks and the official TOGAF standard.

5. Architecture teams optimise for control before they earn trust

This is one of the biggest mistakes.

A new EA function often tries to establish credibility by reviewing everything. That feels responsible. In practice it usually creates queueing, resentment, and a reputation problem. If architecture is seen mainly as a gate, it will eventually be routed around.

What an enterprise architecture operating model includes

A proper EA operating model should answer six questions clearly.

1. What decisions are centralised?

For example:

• enterprise platforms

• cloud guardrails

• cyber and data standards

• integration patterns

• identity and access models

• AI governance rules

• major technology exceptions

AI governance rules should not sit in isolation from the wider operating model, especially for organisations working toward ISO/IEC 42001 or similar control frameworks.

2. What decisions are delegated?

For example:

• local solution design

• implementation choices within approved standards

• domain-level design patterns

• team-level sequencing and delivery decisions

3. Where do architects sit?

Are they all in one central team? Embedded in domains? Split between enterprise and delivery? Solid line? Dotted line? Matrix?

4. What forums make decisions?

Do you have:

• an enterprise architecture board,

• domain councils,

• platform design authorities,

• a data governance forum,

• a security design authority,

• an architecture community or guild?

And more importantly: which of those forums actually decide things?

5. When must architecture engage?

What triggers architecture involvement?

• cost threshold?

• regulated data?

• new technology?

• cross-domain integration?

• shared platform impact?

• strategic initiative?

6. How fast must governance move?

This is where many architecture teams fail.

Governance without explicit decision SLAs is not governance. It is delay dressed up as rigour.

The three core Enterprise Architecture operating models

Most enterprises land in one of three broad models:

• Centralised

• Federated

• Hybrid

The mistake is thinking one of them is universally best.

There is no best model in the abstract. There is only the model that best fits your organisation’s structure, maturity, risk profile, and delivery pattern.

Operating Model 1: Centralised enterprise architecture operating model

In a centralised model, architecture authority sits mainly with a central EA function. Enterprise standards, major design decisions, platform direction, and governance are owned centrally. Architects are usually organised together and operate with clearer enterprise-wide authority.

When centralised works well

A centralised model works best when the business needs control, consistency, and consolidation more than local autonomy.

It is a strong fit when:

• the organisation has heavy regulatory pressure

• technology sprawl is out of control

• business units duplicate tools and platforms

• architecture maturity is low

• delivery is fragmented

• there is a major cost, control, or simplification agenda

• the organisation is integrating acquisitions

• data, cyber, and platform decisions need tighter enterprise control

This is especially true where data governance, security architecture, and platform controls must be consistent across everything you run, which is exactly the kind of enterprise-level governance pressure reflected in frameworks such as NIST CSF 2.0.

What centralised gets right

• Stronger standardisation

• Better cost discipline

• Easier platform rationalisation

• Clearer accountability for enterprise-level decisions

• Better control over cross-cutting risks

• Better conditions for enterprise-wide data, security, and integration discipline

Where centralised fails

A centralised model goes wrong when it becomes a review machine.

That usually shows up as:

• architecture reviewing too much

• solution teams waiting weeks for decisions

• central architects detached from delivery

• business leaders seeing architecture as a blocker

• “standards” that exist mainly to defend the central team’s authority

• shadow decision-making emerging outside the model

The blunt truth about centralised EA

Centralised architecture is often the right answer for chaotic organisations.

But it only works if it is paired with:

• clear thresholds,

• lean review scope,

• strong enterprise sponsorship,

• and fast decision routes.

If central EA tries to control everything, it will fail.

If it owns the right things and gets out of the way on the rest, it can be highly effective.

Operating Model 2: Federated enterprise architecture operating model

In a federated model, architecture capability and decision-making are distributed closer to the business, product, or domain teams. A smaller central EA function may still exist, but it focuses more on principles, guardrails, coherence, and community than direct control.

When federated works well

A federated model works best when the organisation needs speed, domain proximity, and local accountability.

It is a strong fit when:

• the business is product led

• domains have genuine autonomy

• teams are mature and architecture-capable

• time-to-market matters more than maximum standardisation

• business units have distinct needs, customer groups, or operating realities

• the organisation already has strong engineering or product governance at team level

What federated gets right

• Faster local decisions

• Better alignment to delivery reality

• Architecture closer to business context

• Higher adoption because teams own the decisions

• Less dependence on a central bottleneck

• Better fit for product-centric or multi-business environments

Where federated fails

Federation without guardrails is just fragmentation with nicer language.

It fails when:

• every domain invents its own standards

• architecture language and artefacts are inconsistent

• there is no meaningful enterprise view

• data, integration, and cyber decisions drift

• the central EA function has influence but no real authority

• enterprise costs rise because autonomy has no boundaries

The blunt truth about federated EA

Federated models sound modern and empowering, so many organisations are drawn to them too early.

That is a mistake.

Federation only works if the organisation already has:

• mature architects,

• strong shared principles,

• disciplined communities of practice,

• and clear enterprise-level non-negotiables.

If those do not exist, federated architecture will not create autonomy. It will create inconsistency.

Operating Model 3: Hybrid enterprise architecture operating model

Hybrid is the model most organisations say they want.

Unfortunately, many define it badly.

A real hybrid model is not “a bit central and a bit local”. It is a model with explicit decision rights by category. The central team owns some decisions. Domains own others. Shared areas are clearly defined. Escalation rules are understood. Governance does not overlap.

That is what makes hybrid work.

When hybrid works well

A hybrid model is usually the strongest choice for medium-to-large organisations that need both:

• enterprise control in high-risk or shared areas, and

• delivery speed close to the domain or product teams.

It is often the best fit when:

• platforms are shared but delivery is decentralised

• the organisation needs strong cyber, data, AI, or integration guardrails

• business units need some autonomy but not full independence

• there is pressure for both standardisation and speed

• enterprise architecture maturity is moderate to good

What hybrid gets right

• Strategic control where it matters

• Faster decision-making in tactical delivery

• Better balance between enterprise coherence and business agility

• Clearer separation between enterprise architecture and solution architecture

• Better conditions for scaling architecture without central overload

Where hybrid fails

Hybrid fails when the boundaries are vague.

That creates the worst of both worlds:

• double governance,

• duplicated roles,

• central and local architects second-guessing each other,

• too many forums,

• confusion over who decides,

• and endless escalation.

The blunt truth about hybrid EA

Hybrid is powerful, but it is not easy.

It requires discipline.

If you choose hybrid, you must define in plain English:

• what central decides,

• what domains decide,

• what requires consultation,

• what requires approval,

• and what is completely delegated.

If you cannot do that clearly, do not choose hybrid yet.

Comparing the three models properly

You will find tables elsewhere scoring these models with percentages and satisfaction ratings. Treat those numbers with suspicion, including any we might have published ourselves: nobody has measured this across enough comparable organisations to quantify it, and the fair comparison is qualitative. Here it is:

The pattern behind the table: the right model follows the shape of the business rather than the preference of the architects. Which is exactly where the next section starts.

How to choose the right enterprise architecture operating model

The right model depends on reality rather than preference.

Here is the practical way to decide.

1. Start with risk rather than fashion

Ask first:

• Where could a bad technology decision materially hurt us?

• Which decisions create enterprise-wide consequences?

• Where do we need consistency because the cost of variation is too high?

If the answer includes things like regulated data, identity, core platforms, security controls, cross-domain integration, or AI risk, then those areas need stronger central authority.

That does not automatically mean a fully centralised model. It does mean those decision categories should not be left entirely to local discretion.

2. Be honest about organisational maturity

Many organisations choose a decentralised model that their maturity does not support.

Ask:

• Are architects trusted by the business?

• Do teams already use shared patterns well?

• Can domains make good local decisions without constant escalation?

• Is there a functioning architecture community?

• Do we already have a track record of coherent enterprise decisions?

If the answer is no, then heavy federation is risky.

Low maturity usually requires more central structure at the start.

3. Look at the business model rather than just the technology

A highly integrated enterprise with shared customers, shared platforms, and shared economics usually needs stronger central architecture than a diversified group with genuinely autonomous business units.

Ask:

• Are business units truly independent?

• Do they share platforms, data, or customer journeys?

• Are they held to local P&L outcomes or enterprise-wide outcomes?

• Do they operate under different regulatory conditions?

• Do they compete in different markets with different delivery needs?

The more integrated the business, the stronger the case for centralisation or hybrid control.

4. Decide how much standardisation you need

Not all variation is bad.

Some variation is necessary. Some is waste. Some is strategic. Some is accidental.

The job of the operating model is not to eliminate all variation. It is to distinguish between:

• valuable variation that supports business needs, and

• uncontrolled variation that creates cost, risk, and complexity.

That distinction is where good architecture governance earns its keep.

5. Design for decision velocity

This is the question many teams forget:

How quickly must architecture decisions be made for the business to move at the required speed?

If your operating model gives good answers too slowly, it is still a bad model.

That is why architecture governance should always be built with:

• thresholds,

• routes,

• delegation,

• pre-approved patterns,

• and SLAs.

Enterprise Architecture Governance: how to make it work in practice

Once you choose the model, governance design matters.

This is where many architecture strategies fall apart.

You do not need more forums. You need a governance system that is clear, proportionate, and fast.

The purpose of governance is not control for its own sake

Good architecture governance does four things:

1. It makes key decisions at the right level.

2. It reduces avoidable risk and duplication.

3. It gives delivery teams clarity and speed.

4. It makes exceptions explicit instead of invisible.

If your governance model does not improve decision quality and delivery flow, it is badly designed.

Architecture Review Boards: Design for decisions rather than meetings

Many architecture review boards are ineffective because they try to do too much.

They become:

• discussion forums,

• presentation sessions,

• approval factories,

• or political arenas.

That is not governance. That is organisational drag.

What a good architecture board should do

A good architecture board should only handle decisions that genuinely need cross-enterprise judgement.

For example:

• major platform choices

• enterprise exceptions to standards

• high-risk integration decisions

• decisions that affect multiple domains

• strategic technology direction

• major shifts in data, cloud, cyber, or AI guardrails

What it should not do

It should not review every project.

It should not debate low-risk implementation details.

It should not become a compulsory stop for work that could be handled through patterns, domain governance, or delegated authority.

Good architecture board principles

Keep membership small

Five to eight strong members is usually enough. Bigger boards become slow, passive, and political.

Be explicit about authority

Does the board decide, recommend, or advise? If that is unclear, the board will underperform.

Use thresholds

Define what must come to the board based on impact, risk, cost, or cross-domain effect.

Separate strategic from tactical governance

Do not mix enterprise-shaping decisions with delivery-level design queries.

Measure cycle time

If governance speed is not measured, it will degrade.

Centres of Excellence: enablement rather than empire building

A Centre of Excellence can be useful, but only if it is designed properly.

Too many CoEs become document factories or soft-power approval layers.

That is not their job.

A good architecture-related CoE should do three things well:

• curate reusable knowledge,

• build community capability,

• and enable teams to make better decisions themselves.

A CoE exists to multiply other teams

That means:

• patterns

• reference architectures

• reusable guidance

• playbooks

• training

• onboarding

• community forums

• office hours

• mentoring

• lessons learned

If the CoE is doing most of the design work itself, it is probably swallowing work that should sit in delivery.

A CoE should increase architecture quality through enablement rather than by becoming a shadow delivery team.

Engagement rules: this is where trust is won or lost

Every project should not need to negotiate architecture involvement from scratch.

That creates confusion, inconsistent expectations, and endless argument.

Instead, define clear engagement rules.

Architecture must be engaged when:

• the change affects enterprise platforms

• regulated, sensitive, or critical data is involved

• a new technology is being introduced

• there is cross-domain integration

• the decision affects security

• the initiative is strategically material

• a standards exception is being requested

Architecture may be engaged when:

• a team wants design support

• an existing pattern needs adapting

• a local decision has uncertain enterprise impact

• a domain needs help assessing trade-offs

Architecture does not need formal review when:

• the change is low risk

• the team is using approved patterns

• the decision stays fully within delegated authority

• the work is routine and within known standards

That is how you reduce unnecessary governance load without losing control.

Solution: Architecture Engagement Framework

Define clear, simple rules for when and how architecture engages with projects and business initiatives.

Engagement Trigger Framework:

When Architecture MUST be engaged:

When Architecture SHOULD be engaged (Recommended):

When Architecture CAN be skipped:

Engagement Process Flow:

Standard Architecture Engagement Process:

Step 1: Intake (1 day)
Project submits architecture request form
    • Project overview, budget, timeline, technology scope
    • Auto-routing based on trigger criteria

Step 2: Initial Assessment (2-3 days)
Assigned architect reviews request
    • Determines engagement level required
    • Identifies relevant patterns/standards
    • Schedules architecture workshop if needed

Step 3: Architecture Workshop (1-2 weeks)
Collaborative session with project team
    • Review business requirements
    • Define solution architecture options
    • Identify standards, patterns, risks
    • Document architecture decisions

Step 4: Architecture Review (3-5 days)
For mandatory reviews, present to ARB or domain council
    • Present architecture approach
    • Review against standards and principles
    • Approve, approve with conditions, or request revisions

Step 5: Delivery Support (ongoing)
Architect available for questions during delivery
    • Ad-hoc consultation as needed
    • No formal approval required for implementation details
    • Optional design review checkpoints

Fast-Track Process for Low-Risk Projects:

Step 1: Self-Assessment (1 day)
Project team completes architecture checklist
    • Are we using approved technology?
    • Are we following standard patterns?
    • Do we need cross-domain integration?

Step 2: Pattern Selection (1 day)
Project selects from reference architecture library
    • Choose applicable patterns
    • Document in project architecture doc

Step 3: Notification (1 day)
Submit architecture summary to CoE
    • For awareness and metrics only
    • No formal approval required

Implementation proceeds immediately (0-day wait)

Engagement Roles and Responsibilities:

RACI Matrix for Architecture Engagement:

R = Responsible, A = Accountable, C = Consulted, I = Informed

Where Intelance can help

Everything in this article is work we deliver, at fixed published prices, and the approach is built from designing and repairing EA functions for UK organisations rather than from theory:

• EA Operating Model &amp. Governance: the diagnostic at £18,000 + VAT tells you plainly what you have and what to change. Full builds run from £95,000 fixed, designed around decision rights, working forums and proof of value.
• EA QuickScan: the ten day baseline of everything you run, from £18,000 + VAT, which most operating model work should start from.
• Virtual EA Department: the whole function run monthly by a named lead and bench, £6,500 to £22,000 per month, with succession to your own hires designed in from day one.

The boundary: if your organisation is small enough that one good architect with clear authority covers it, we will say so on the first call, because an operating model programme you do not need is exactly the kind of empire building this article warns against.

Enterprise architecture operating models: frequently asked questions

What is an enterprise architecture operating model?

The working design of how architecture runs in an organisation: which decisions are centralised, which are delegated, where architects sit, which forums decide, when architecture must engage, and how the function proves its value. It is the difference between having architects and having architecture.

What is the difference between centralised and federated enterprise architecture?

In a centralised model, one team owns architecture decisions and standards for the whole organisation, which buys consistency at the price of speed. In a federated model, decisions sit with business units or product teams, which buys speed at the price of divergence, duplication and integration pain. Most real organisations end up needing elements of both.

Which enterprise architecture operating model is best?

The one that matches the shape of the business. A highly integrated business with shared customers and platforms usually needs a centralised core. A group of genuinely autonomous businesses can federate with a small, hard set of shared rules. Most organisations with a shared core and autonomous edges do best with a hybrid, provided the boundaries are written down rather than assumed.

What is a hybrid enterprise architecture operating model?

A deliberate split: a small set of decisions held centrally, security, integration, data and platform choices that affect everyone, with everything else delegated to teams inside clear standards. It works when the boundary between central and delegated is explicit, and fails into confusion when it is left fuzzy.

What is an architecture review board, in plain words?

The forum where architecture decisions get made: significant designs are challenged, exceptions are granted or refused, and every decision is logged with its reasons. A good one moves at delivery speed and decides. A bad one is a monthly committee that reviews slides and slows everyone down. The difference is decision rights and pace rather than membership.

How many architects do we need?

Fewer than you fear, if decision rights are clear. The number is driven by decision volume rather than headcount ratios: a lean centre with capable delivery teams and written standards outperforms a large function with fuzzy authority. Organisations buying folklore ratios usually end up with architects nobody asked for and decisions nobody owns.

What is the difference between an EA operating model and an EA framework?

A framework such as TOGAF is reference material anyone can download: methods, taxonomies and languages. The operating model is what your organisation builds: who decides what, which forums run, and how value is proved. Frameworks inform the operating model. They cannot substitute for it. Our guide to enterprise architecture frameworks covers the reference side in full.

What does it cost to build an enterprise architecture operating model?

With Intelance, at published fixed prices: the EA Operating Model Diagnostic at £18,000 + VAT tells you what you have and what to change. Full builds run from £95,000 fixed depending on scale, with the largest programmes custom above £300,000. If you want the function run for you instead, the Virtual EA Department starts at £6,500 per month with handover designed in.

Emmanuel Olatunji

Chief Enterprise Architecture Partner

Emmanuel founded Intelance in 2017 and has led architecture, AI governance, cyber and deal engagements across the UK, Europe, the Middle East and Africa. Every Intelance engagement runs under his direction, and every guide he publishes comes from that work.

See his record on LinkedIn About Intelance