Enterprise Architecture

Enterprise architecture frameworks: the complete guide (2026)

There is no single best enterprise architecture framework. This guide compares TOGAF, Zachman, ArchiMate, Gartner and SAFe: what each one is for, where each one fails, and how to blend them so architecture pays for itself.

The Ultimate Guide to Enterprise Architecture Frameworks - Intelance

What this guide covers

Most guides to enterprise architecture frameworks stay theoretical. This one covers what holds up in practice, written by the practitioners who deliver this work for UK organisations, with every service priced in public.

We have written this for CIOs, CTOs, architecture leads, and board-level decision makers who need to:

  • Choose the right framework (or framework combination) for their organisation
  • Avoid the framework worship trap that kills most EA programmes
  • Deliver measurable business value from architecture rather than diagrams alone
  • Understand how AI, cloud, and M&A are reshaping enterprise architecture in 2026

Key takeaways (read this first)

An enterprise architecture framework is a structured way to describe how a business, its applications, its data and its technology fit together, and to govern how they change. The most widely adopted is TOGAF, now in its 10th Edition. Zachman is a classification grid rather than a method. ArchiMate is a drawing language rather than a framework. Gartner sells research and advice rather than a framework you can adopt. None of them is a strategy, and none of them delivers anything on its own.

If you take one thing from this guide, take this: there is no single best enterprise architecture framework, and anyone selling you one is selling theory. Mature architecture teams blend three things: a method for making and governing decisions (usually a simplified TOGAF), a completeness check so nothing important gets forgotten (Zachman thinking), and a shared language for models people can read (ArchiMate). Then they throw away everything that does not help a decision.

  • Use TOGAF when change needs governing across many teams. Simplify the ADM: the full ten-phase cycle is overkill for most organisations.
  • Use Zachman as a checklist against blind spots rather than as a delivery method, because it is not one.
  • Use ArchiMate so business, application and technology views stay consistent and readable.
  • Use Gartner’s capability thinking for board conversations about where money should go.
  • Use ISO/IEC/IEEE 42010 to stop diagram theatre: every view must have a stakeholder and a concern.
  • Blend them and keep it light. The framework is scaffolding. The building is a current register of what you run, a costed roadmap, and decisions people follow.

Most framework programmes fail not because the wrong framework was chosen, but because the framework became the point. If you want a recommendation for your organisation, and an honest list of what to drop, that conversation starts on our enterprise architecture consulting page, with every price published.

What are enterprise architecture frameworks?

Enterprise architecture frameworks are structured ways to design, govern, and communicate change across business capabilities, processes, data, applications, and technology.

A useful enterprise architecture framework helps you answer three plain questions:

1. Where are we today? (current state architecture: a current state you can trust)
2. Where do we want to be? (future state architecture: a target state tied to strategy)
3. How do we get there?
(roadmap and governance: sequence, constraints and governance)

The real business reason frameworks exist is simple: to ensure that every pound spent on IT creates measurable business value.

Why most framework definitions are useless

If you search online right now, you will find thousands of academic definitions of enterprise architecture frameworks filled with technical jargon: meta-models, artefacts, taxonomies, reference models, governance layers, and so on. They are not wrong, but they are not helpful for decision makers.

At Intelance, we see frameworks as decision scaffolding: they guide how you evaluate, select, sequence, and govern technology investments. But we never forget: Frameworks exist to serve the business. Not the other way around.

Why enterprise architecture frameworks matter to the board

For years, EA promised much and changed little. Companies hired EA teams, produced beautiful diagrams, held governance meetings, and nothing changed. Projects still ran over budget. Shadow IT still proliferated.

That era is over. Five forces have made EA frameworks essential:

ForceContext
1. Cost avoidance and spend disciplineYour board is not asking about cloud adoption anymore. They are asking why you are spending £18 million a year on redundant SaaS subscriptions. Why you have 47 different tools that do essentially the same thing.

“Application rationalisation work routinely finds the same thing: two systems doing one job, and licences renewing for software nobody opens. Finding it quickly is what the EA QuickScan is for.”

The plain truth: CIOs without EA visibility are making million-pound decisions blind. When the CFO asks “What would we lose if we cut IT spend by 15%?“, you should have an answer in 48 hours rather than three months.
2. Business-to-technology alignmentMost boards now expect AI to contribute to growth. But your business units are signing up for AI vendors faster than you can track them. Marketing has three “AI-powered” tools. Sales built a custom GPT wrapper. Finance is piloting ML for forecasting. None of them talk to each other.

Without EA governance: data leakage risk, vendor sprawl, integration nightmares, and regulatory exposure under the EU AI Act. AI makes architecture decisions visible to regulators in ways that legacy systems never did.
3. Regulatory and audit readinessThe EU AI Act, DORA (Digital Operational Resilience Act), NIS2 Directive, and sector-specific regulations all demand architectural documentation, risk classification, and audit trails.

EA frameworks are no longer optional for regulated industries. They are compliance infrastructure.
4. Technical debt is now a board-level riskThat legacy mainframe is not just an IT problem. It is a business continuity risk, a cyber vulnerability, and a competitive disadvantage. Boards are now asking about technical debt in the same breath as financial debt. EA frameworks provide the visibility to quantify, prioritise, and systematically address technical debt.
5. Architectural risk reductionPoor architecture is not just a technical debt issue. It creates enterprise-level risk.

Data breaches, compliance failures, operational downtime, or scalability bottlenecks often trace back to uncontrolled architecture sprawl.

An enterprise architecture framework surfaces these risks early, embeds governance and assigns accountability.

Protecting shareholder value means protecting architectural integrity.

This is why EA is resurging through 2026 and 2027: cost pressure, AI acceleration, cyber risk, and regulation have removed tolerance for “architecture as theatre”.

Related: Enterprise architecture: the CIO’s practical guide (2025-2026 edition)

The framework categories most teams confuse

Before we compare frameworks, you need one clarifying model. Not all “frameworks” are the same thing.

Framework types

TypeWhat it doesExamples
MethodA repeatable process for developing and governing architectureTOGAF ADM
Classification / taxonomyEnsures complete coverage and prevents blind spotsZachman
Modelling languageA standard way to describe and visualise architecture relationshipsArchiMate
Delivery operating modelHow teams deliver change at scale (where architecture must integrate)SAFe (Enterprise Architect role, runway)
Architecture description disciplineForces clear viewpoints, concerns, and stakeholder-aligned descriptionsISO/IEC/IEEE 42010

If you remember one thing: choose a blend across categories rather than a single brand.

The main enterprise architecture frameworks you need to understand

Every EA practitioner needs to understand the major frameworks. The point is not to follow them religiously but to know when to apply which elements. Here is what each framework does well, where it fails, and when to use it.

Enterprise Architecture frameworks landscape showing where TOGAF, Zachman, Gartner, SAFe, and ArchiMate fit by governance vs delivery and ontology vs method.
A practical map of where the main EA frameworks sit, so you choose what fits your organisation rather than copying theory.

TOGAF (The Open Group Architecture Framework): still the dominant global standard

What it is: The Open Group Architecture Framework (TOGAF) remains the most widely adopted enterprise architecture framework globally. Originally released in 1995, TOGAF has gone through multiple evolutions, with the current TOGAF 10 release representing its most modern form.

Core components: At its core, TOGAF provides organisations with a structured method to design, plan, implement, and govern enterprise architecture. Its centrepiece is the Architecture Development Method (ADM), a repeatable step by step process that guides architects through:

  • Preliminary Phase (architecture readiness)
  • Vision
  • Business Architecture
  • Information Systems Architecture (Data & Applications)
  • Technology Architecture
  • Opportunities & Solutions
  • Migration Planning
  • Implementation Governance
  • Architecture Change Management
The TOGAF ADM cycle diagram showing all phases from preliminary through to architecture change management
The TOGAF ADM cycle: the method at the heart of TOGAF.

This cycle ensures continuous alignment between technology capability and business strategy.

TOGAF: strengths versus reality

StrengthsLimitations
Comprehensive governance structureCan become bureaucratic when applied rigidly
Industry-recognised certificationFull ADM cycle takes 6 to 18 months
Repeatable, auditable processesDocumentation-heavy by design
Strong stakeholder managementWeak on change management
Extensive documentation libraryDoes not prescribe tools or techniques

“TOGAF’s ADM is powerful, but most organisations apply all 10 phases when they only need 4. That is where framework purism kills velocity.” – Emmanuel Olatunji, Chief Enterprise Architecture Partner, Intelance

Where TOGAF wins

  • Strong governance rhythm for complex, multi-stakeholder environments
  • Good for regulated organisations that need traceability
  • Works well when you must coordinate many teams and vendors

Where TOGAF fails

  • When governance slows delivery so much that teams route around it
  • When it becomes documentation-first and delivery-last
  • When teams treat ADM as a compliance exercise

When to use TOGAF: Large enterprises (1,000+ employees) needing formal governance for multi-year transformation programmes. Regulated industries where audit trails matter. Organisations with existing TOGAF-trained staff.

When to avoid pure TOGAF: Fast-moving environments, mid-market companies without dedicated EA teams, or any situation where you need results in under 6 months.

TOGAF ADM deliverables table showing practical executive outcomes and outputs for each phase.
What TOGAF produces in the real world: the decisions, artefacts, and governance you can use.

What TOGAF should produce (in the real world)

  • Decisions: what we will standardise, what we will retire, what we will invest in
  • Guardrails: principles, patterns, and reference architectures
  • Control: architecture governance integrated into funding and delivery

Zachman (taxonomy): prevents blind spots, but does not run delivery

What it is: The Zachman Framework is a classification schema (not a methodology) for describing an enterprise. Created by John Zachman at IBM in the 1980s. Often called the “periodic table of enterprise architecture.” Unlike TOGAF, Zachman does not prescribe processes. It simply organises information into a six by six matrix mapping six interrogatives (What, How, Where, Who, When, Why) against six stakeholder perspectives (Planner, Owner, Designer, Builder, Subcontractor, Functioning System).

Each of these dimensions is examined across six stakeholder perspectives:

  • Planner (Scope)
  • Owner (Business Model)
  • Designer (System Model)
  • Builder (Technology Model)
  • Subcontractor (Detailed Representations)
  • Functioning System

The Zachman matrix simplified

WhatHowWhereWhoWhenWhy
DataFunctionNetworkPeopleTimeMotivation

Key strength: Forces complete structural thinking. Prevents gaps in architectural scope. Excellent for foundational taxonomy work.

Critical limitation: Zachman does not guide how to execute architecture projects. It is a powerful thinking tool but lacks operational sequencing.

How we use Zachman: We apply Zachman principles in the preliminary stage of our EA QuickScans, mapping the full enterprise dimensions before building practical roadmaps. It is a lens rather than a lifecycle.

Zachman Framework 6×6 matrix showing enterprise perspectives by rows and aspects by columns.
Zachman is an EA classification system: it ensures nothing important is missed, but it does not run delivery for you.

ArchiMate (modelling language): makes architecture readable and consistent

ArchiMate is an open, independent modelling language standard of The Open Group for enterprise architecture. It is designed to describe and visualise relationships across business, application, and technology domains in a consistent way.

Where ArchiMate wins

  • Produces diagrams that different teams can read without translation wars
  • Helps connect strategy to capabilities, processes, applications, data and technology
  • Reduces the “every architect draws differently” problem

Where ArchiMate fails

  • If teams draw models with no decision attached
  • If it becomes a modelling obsession without governance or outcomes

How we use ArchiMate
We use ArchiMate selectively for the models that drive decisions:

  • capability to application mapping
  • integration and dependency maps
  • target reference architectures
  • transition states for major programmes (cloud, ERP, M&A)

Gartner’s capability-based planning model

What it is: A business-outcome-focused approach that shifts EA conversations from systems and processes to business capabilities. Unlike TOGAF or Zachman, Gartner’s model is deeply rooted in strategic business alignment.

Core concept: A business capability represents what the organisation must be able to do, independent of how it is done. Capabilities are stable anchors that survive technology changes, organisational restructures, and market shifts.

The four capability layers:

  1. Business Capabilities: What the business must achieve (e.g., Customer Onboarding, Financial Forecasting)
  2. Information Capabilities: Data and analytics that support business capabilities
  3. Technical Capabilities: Technology platforms and infrastructure
  4. Governance Capabilities: Controls, policies, and decision rights
Business capability map example with a capability heatmap showing which capabilities to invest in, maintain, or fix.
Modern EA starts with capabilities: what the business must be able to do, then where to invest, fix, or rationalise.

Key strength: Transforms EA conversations from “What technology are we buying?” to “What capability are we enabling?” Boards and executives immediately see how technology enables strategic growth.

Trade-off: Full access to Gartner’s complete meta-models requires expensive research subscriptions (£50,000 or more a year).

How we use Gartner’s model: Capability mapping is the backbone of every Intelance engagement. We use capability maturity assessments to prioritise investments and align technology spending with board-level strategic objectives.

SAFe (Scaled Agile Framework): not an EA framework, but architecture must fit it

Diagram showing how enterprise architecture provides guardrails and runway in SAFe while Agile Release Trains deliver change.
In SAFe, EA wins by enabling fast delivery safely: clear guardrails, reference architectures, and continuous feedback from execution.

What it is: While not an enterprise architecture framework in the traditional sense, the Scaled Agile Framework (SAFe) increasingly intersects with enterprise architecture discussions, especially in organisations adopting large-scale agile delivery.

SAFe incorporates an architectural runway concept, system-level design, and Lean Portfolio Management that directly affects enterprise architecture governance.

Where SAFe intersects with EA:

  • Supports agile programme delivery at scale
  • Requires architects to enable incremental, continuous architecture development
  • Demands tight coordination between enterprise-level architecture and delivery teams

The caution with SAFe:

Many organisations confuse agile delivery frameworks with enterprise architecture frameworks. SAFe helps with how you deliver. Enterprise architecture frameworks determine what and why you are delivering.

ISO/IEC/IEEE 42010 (architecture description discipline): the quality control most teams ignore

ISO/IEC/IEEE 42010 is an international standard for architecture description best practices.
If your architecture documents are inconsistent, unreviewable, or not trusted by stakeholders, this is usually the missing discipline.

Where ISO 42010 wins

  • Forces clarity on stakeholders, concerns, and viewpoints
  • Stops the “one diagram explains everything” habit
  • Supports auditability and decision traceability

Where ISO 42010 fails

  • If you treat it as paperwork instead of a quality bar for communication

How we use ISO 42010
We use it as a checklist for credibility: if a model does not have a clear stakeholder and decision purpose, it should not exist.

Which enterprise architecture framework should you use?

This is the question every CIO asks. And every consultant gives you a non-answer: “It depends.” Here is an actual decision framework.

The frameworks compared side by side

CriteriaTOGAFZachmanGartnerIntelance EA Velocity Method
Best forLarge enterprise governanceTaxonomy and documentationBusiness alignmentRapid value delivery
Time to value6 to 18 months3 to 6 months2 to 4 months2 to 6 weeks
Governance depthDeep and formalNone: it is a taxonomy rather than a methodLightDeep where decisions need it, light everywhere else
Business focusMediumLowHighHigh
AgilityLow unless simplifiedLowMediumHigh
Learning curveHigh (certification)MediumLow to mediumLow (guided)
CostFree + cert costsFreePaid subscriptionFixed published fees

Every CIO, CTO or enterprise leader searching for the best enterprise architecture framework is usually asking the wrong question.

Decision tree showing how CIOs choose an enterprise architecture framework based on maturity, regulation, and delivery needs.
A practical way to choose frameworks: start from the decision you need to make rather than the method you were sold.

Which framework should you choose? The decision tree

Answer these five questions to identify your optimal framework approach:

  1. Do you have an existing EA function with TOGAF-trained staff? Yes: consider TOGAF as the governance backbone. No: skip to question 2.
  2. Do you need results in under 3 months? Yes: avoid pure TOGAF and use the Gartner capability model or the EA Velocity Method. No: continue.
  3. Is your primary audience the board/executives or IT teams? Board: prioritise capability-based approaches. IT: consider more technical depth.
  4. Are you in a highly regulated industry? Yes: you need governance documentation, so blend TOGAF governance with business models. No: a lighter approach is possible.
  5. Do you have dedicated EA budget and headcount? Yes: an internal team can own framework adoption. No: EA-as-a-Service may be more effective.

Framework recommendations by industry

Financial services

Recommended blend: TOGAF governance + Gartner capability model. Regulatory requirements (DORA, PRA, FCA) demand formal governance trails, but business transformation pressure requires capability-based prioritisation. Focus on: risk-based architecture decisions, regulatory compliance documentation, and technology resilience mapping.

Healthcare and life sciences

Recommended blend: Zachman for data architecture + Gartner for business capabilities. NHS and private healthcare require complete data governance views (Zachman’s strength), but clinical system modernisation moves too fast for full TOGAF ADM cycles. Focus on: patient data flows, interoperability standards, and clinical capability enablement.

Manufacturing and supply chain

Recommended blend: Capability-based planning + TOGAF for OT/IT governance. Supply chain complexity requires clear capability mapping, but operational technology integration demands structured governance. Focus on: OT/IT convergence, supply chain resilience capabilities, and production system architecture.

Private equity portfolio companies

Recommended: EA Velocity Method (blended approach). PE timelines do not allow for 18-month TOGAF implementations. Focus on: rapid current-state visibility, integration architecture for bolt-ons, value creation roadmaps aligned to investment thesis. We have supported 23 PE-backed integration programmes using this approach.

The Intelance EA Velocity Method: how we blend the frameworks

This is where most EA framework guides stop: they describe existing frameworks but do not explain how to combine them for real results. Here is exactly how we do it at Intelance.

There are no single “right” enterprise architecture framework.

Each of TOGAF, Zachman, Gartner and SAFe offers valuable thinking tools. But none of them, in isolation, deliver what complex organisations truly need: practical execution tied directly to business value.

The real question boards should ask is:

“How do we blend these enterprise architecture frameworks into something that delivers results quickly in our context?”

The Intelance blended model (the EA Velocity Method)

TOGAF provides the governance, Zachman the completeness check and Gartner the business alignment. The blend is what delivers.

A blended approach shaped by client delivery, designed to produce usable architecture decisions in weeks rather than months.

Blended enterprise architecture framework stack showing how strategy, capabilities, standards, delivery governance, and assurance work together.
The real answer is not choosing one framework. It is stacking the right parts to run EA like an execution system.

The three layers

We have found that successful EA frameworks operate across three distinct layers, each drawing from different framework strengths:

Layer 1: governance (TOGAF ADM, simplified)

We use TOGAF’s Architecture Development Method for governance gates, but we simplify the ten-phase cycle into four practical stages:

  1. Scope and vision (combining ADM Preliminary + Phase A)
  2. Architecture Design (combining Phases B, C, D)
  3. Roadmap and migration (combining Phases E, F)
  4. Governance and change (combining Phases G, H)

This preserves the governance discipline of TOGAF while cutting the ceremony that slows it down.

Layer 2: taxonomy (the Zachman lens)

We apply Zachman’s six by six schema as a completeness check, ensuring we have mapped Data, Function, Network, People, Time, and Motivation across stakeholder perspectives. This happens in Week 1 of every engagement, preventing architectural blind spots.

Layer 3: alignment (the Gartner capability model)

Every architecture deliverable maps to business capabilities. We do not present technology recommendations. We present capability enablement options. This transforms board conversations from “We need a new ERP” to “We are investing in finance capability maturity.”

The EA Velocity Method: delivery in six phases

PhaseDurationActivitiesDeliverables
1. DiscoveryDays 1 to 3Stakeholder interviews, existing documentation review, Zachman completeness checkArchitecture scope definition, stakeholder map
2. MappingDays 4 to 7Current-state application inventory, capability mapping, dependency analysisAs-is architecture views, capability heat map
3. AnalysisDays 8 to 10Gap analysis, risk assessment, cost-benefit modelling, technical debt quantificationRisk register, opportunity matrix, technical debt report
4. DesignDays 11 to 14Target-state architecture options, principles definition, governance model designTo-be architecture views, architecture principles
5. RoadmapDays 15 to 18Migration planning, initiative sequencing, investment prioritisationTransformation roadmap, business case
6. GovernanceDays 19 to 21Operating model design, governance implementation, handoverEA operating model, governance playbook, executive deck

What you can honestly expect

We do not publish percentages from studies you cannot check, and we would not believe a consultancy that did. What we publish instead is prices and deliverables, so you can hold us to them.

A blended, decision-led approach produces its first paid-for value in weeks rather than quarters: a complete register of what you run with owners and costs, the duplications and risks named, and a costed roadmap a board can approve. That is the EA QuickScan: ten working days, from £18,000 + VAT fixed, agreed in writing before day one. What it finds is specific to your organisation, which is precisely why we will not put a fake average on it.

The framework worship trap: why most EA programmes fail

This is where most enterprise architecture engagements fail. The cause is rarely a weak framework. It is framework religion.

EA framework anti-patterns infographic showing common mistakes like framework theatre and diagram spam, with practical fixes.
Frameworks fail for predictable reasons. This is how to spot the failure patterns early and correct them fast.

Framework purism kills architecture.

The failure patterns repeat so reliably across organisations that we can name them. Here are the seven that kill EA programmes most often:

Anti-pattern 1: framework purism

The symptom: Teams endlessly debate which framework is “correct.” Architecture review boards become philosophy seminars. Real business decisions stall while consultants produce TOGAF-compliant artefacts nobody reads.

The fix: Frameworks exist to serve the business. If TOGAF Phase C is slowing you down and adding no value, skip it. Document why, and move on.

Anti-pattern 2: ivory tower architecture

The symptom: Architects work in isolation from delivery teams. They produce beautiful target-state diagrams that have no connection to what is being built. Developers view EA as “the people who slow us down.”

The fix: Embed architects in delivery. EA should be reviewing solution designs weekly rather than quarterly. If your architects do not understand the tech stack your teams are using, you have a credibility problem.

Anti-pattern 3: tool-first thinking

The symptom: The EA programme starts with a £200,000 investment in LeanIX or Ardoq. Six months later, the tool is empty because nobody knows what to put in it, or why.

The fix: Start with questions rather than tools. What decisions do you need to make? What information do you need to make them? Only then consider tooling. We have seen EA programmes deliver more value with SharePoint and PowerPoint than with enterprise EA suites.

Anti-pattern 4: documentation obsession

The symptom: The EA team measures success by the number of documents produced. Architecture repositories grow to thousands of artefacts that nobody reads or maintains.

The fix: Every artefact needs an owner and a use case. If nobody is using it to make decisions, delete it. Architecture should enable decisions rather than produce shelfware.

Anti-pattern 5: no business sponsorship

The symptom: EA is owned entirely by IT. The CIO cares, but the CFO and business unit leaders see EA as overhead. When budgets tighten, EA gets cut first.

The fix: Frame EA in business terms. Do not report on architecture maturity. Report on cost avoided, risk reduced, and capability enabled. Get a business sponsor rather than just IT sponsorship.

Anti-pattern 6: big bang transformation

The symptom: EA creates a perfect target-state architecture and a five year transformation roadmap. By year 2, the business has changed, leadership has changed, and the roadmap is fiction.

The fix: Plan in 90-day increments. Have a directional target state, but sequence work in quarterly sprints with clear value delivery at each stage.

Anti-pattern 7: ignoring technical debt

The symptom: EA focuses on shiny new capabilities while legacy systems accumulate risk. Nobody tracks technical debt, so it grows invisibly until something breaks.

The fix: Quantify technical debt in business terms. “This legacy system costs us 120 hours/month in manual workarounds and creates £2 million of regulatory exposure.” Make technical debt visible at board level.

Getting started: your first 90 days

Whether you are starting an EA function from scratch or fixing a broken one, here is a practical 90-day playbook.

90-day enterprise architecture plan for CIOs with deliverables by phase
A practical 90-day plan: establish baseline and decision control, publish reference patterns, deliver a visible win, then scale the operating model.

Days 1 to 30: foundation

Week 1: stakeholder alignment

  • Identify your EA sponsors (CIO minimum, CFO or COO ideal)
  • Define EA scope: What is in, what is out?
  • Agree on success metrics (cost reduction, risk reduction, delivery speed)
  • Document the three biggest architecture pain points

Weeks 2 to 3: current state inventory

  • Build application inventory (aim for complete enough to decide rather than perfect)
  • Map critical business capabilities to supporting applications
  • Identify integration points and data flows (high-level only)
  • Document known risks, technical debt, and compliance gaps

Week 4: quick wins

  • Identify two or three applications for immediate decommissioning (every organisation has them)
  • Flag duplicate functionality for rationalisation review
  • Present findings to sponsors with quantified savings potential

Days 31 to 60: governance

Weeks 5 to 6: establish the operating model

  • Define architecture review board (ARB) or equivalent
  • Create architecture principles (start with five to seven rather than 50)
  • Design exception process (EA must be able to say no, but also know when to allow exceptions)
  • Map EA to existing governance forums (investment committee, risk committee)

Weeks 7 to 8: the first roadmap

  • Create 12-month architecture roadmap aligned to business priorities
  • Prioritise initiatives by business impact rather than technical elegance
  • Get sponsor sign-off on roadmap and governance model
  • Present to the leadership team and make EA visible

Days 61 to 90: embed and scale

Weeks 9 to 10: embed in delivery

  • Start reviewing project architectures before funding approval
  • Join two or three active projects as architecture advisor
  • Create reusable architecture patterns from successful projects
  • Build relationships with delivery teams (EA must be helpful rather than bureaucratic)

Weeks 11 to 12: measure and report

  • Track architecture decisions made and their outcomes
  • Quantify value delivered (costs avoided, risks mitigated, speed improvements)
  • Report to sponsors on 90-day achievements
  • Plan next quarter priorities based on business strategy

Critical success factor: Deliver visible value within 90 days. EA programmes that take 12 months to show results rarely survive leadership changes or budget pressures.

EA-as-a-Service: when external support makes sense

Not every organisation can justify a full-time EA team. Not every organisation should. Here is the decision framework for internal versus external EA capability.

When to build internal EA

  • You have 1,000+ employees with complex technology landscapes
  • You are in a heavily regulated industry requiring deep domain knowledge
  • Architecture decisions need to flow continuously (not project-by-project)
  • You can attract and retain senior architects (£90,000 to £140,000 or more in the UK market)
  • Your architecture changes frequently (M&A, continuous transformation)

Cost reality: A five person internal EA team costs £600,000 to £800,000 a year across salaries, tools, training and recruitment. Add 6 to 12 months of ramp up time before full effectiveness.

When to use EA-as-a-Service

  • You need senior architect expertise without permanent headcount
  • You are running a specific transformation programme with a defined end date
  • You need to start fast (weeks rather than months)
  • Your internal team needs augmentation for peak demand or specialised skills
  • You are a mid-market organisation (250 to 1,000 employees) where full EA team is not justified
  • You are a PE portfolio company needing rapid architecture visibility for integration or exit

Intelance EA services with the prices published

Every service below has a fixed, published price, which remains rare in this market. The framework knowledge in this guide is built into all of them.

ServiceWhat you getPrice and time
EA QuickScanEvery system inventoried and scored for cost, fit and risk, with a costed roadmap and board readoutfrom £18,000 + VAT · 10 working days
EA Operating ModelThe working parts of an EA function: decision rights, standards, forums and proof of value, built to fit youDiagnostic from £18,000 + VAT · full builds from £95,000
ProjectEASenior architects inside your programme, protecting the systems you own on day twofrom £45,000 + VAT per programme
Virtual EA DepartmentThe whole EA function run monthly by a named lead and bench, with handover to your own hires designed in£6,500, £11,000 or £22,000 per month by capacity

Independent proof rather than help: the Independent Technology Audit covers the whole technology picture for boards from £4,500 to £18,000 + VAT, at fixed published fees.

Enterprise architecture frameworks in the AI era

Two things changed for architecture teams since the frameworks in this guide were written, and neither of them is the framework.

First, AI changed the speed of the work rather than the accountability. Discovery that took months, building the application inventory, mapping integrations, finding duplication, can now be largely automated. That makes registers cheaper to keep current, which removes the oldest excuse in architecture. What AI does not change is decision rights: no model decides which ERP survives a merger or which supplier holds your customer data. Frameworks earn their keep in exactly that gap, because they are, at their best, a way of deciding.

Second, AI regulation made architecture registers a legal matter. The EU AI Act, as amended by the Digital Omnibus adopted in June 2026, sets obligations that cannot be met without knowing what AI systems you run and where: transparency duties apply from 2 August 2026, AI content marking from 2 December 2026, and the postponed high-risk obligations from 2 December 2027. Every one of those starts with an inventory, which is architecture work by another name. If your organisation touches the EU market, the EU AI Act Readiness Assessment maps your systems against the dates that stand.

The honest summary: frameworks matter more in the AI era rather than less, but only the parts that produce decisions and current registers. The ceremony matters even less than it used to, because nobody has time for it and the regulators will not accept it as evidence.

Enterprise architecture operating loop for the AI era showing telemetry inputs, EA repository, AI assistance, governance, and measurable outputs.

Enterprise architecture frameworks: frequently asked questions

What is an enterprise architecture framework?

A structured way to describe how a business, its applications, its data and its technology fit together, and to govern how they change. The best known are TOGAF, which is a method, Zachman, which is a classification grid, and ArchiMate, which is a modelling language. They answer different questions and are routinely used together.

Which enterprise architecture framework is best?

There is no single best framework. TOGAF is the most widely adopted and the strongest for governed change. Zachman is the best completeness check. ArchiMate is the best way to draw consistent models. Mature teams blend all three and keep only what helps a decision.

What is the difference between TOGAF and Zachman?

TOGAF is a method: it tells you what to do, in what order, with which deliverables and governance. Zachman is a taxonomy: a six by six grid that tells you what to describe so nothing is forgotten, but says nothing about how to run the work. One runs delivery, the other prevents blind spots.

Is TOGAF still worth it in 2026?

Yes, used selectively. The current version is the TOGAF Standard, 10th Edition, split into Fundamental Content and Series Guides, with the core ADM unchanged. Its value is a shared vocabulary and a governance backbone. Its danger is ritual: full ten-phase cycles and document sets that nobody reads. Adopt the backbone, drop the ceremony.

Do small companies need an enterprise architecture framework?

No. They need the decisions a framework is supposed to produce: a current list of systems with owners and costs, a view of what talks to what, and a roadmap. A ten day assessment produces those directly, and a framework can come later if the organisation grows into one.

Can you combine enterprise architecture frameworks?

Yes, and most successful practices do: a simplified TOGAF for method and governance, Zachman thinking as a completeness check, and ArchiMate as the modelling language. The frameworks were designed for different jobs, which is exactly why they combine well.

How long does it take to implement an EA framework?

Adopting a framework label takes a workshop. Producing value takes a register, a roadmap and working governance, and a decision-led approach delivers those in weeks: our EA QuickScan takes ten working days. Full operating model builds run three to nine months. Anything promising value only after a year of framework adoption should worry you.

How much does an enterprise architecture framework cost?

The frameworks themselves cost little: the TOGAF Standard is free to download for non-commercial use, and certification exam fees are published by The Open Group. The real cost is people and time. For the work itself, our prices are published: assessments from £18,000, operating model builds from £18,000 for the diagnostic, and a run monthly EA function from £6,500 per month.

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

The framework is the reference material: methods, taxonomies and languages anyone can download. The operating model is what your organisation builds: who makes which decisions, which forums run, which standards apply and how value is proved. Frameworks inform it. They cannot substitute for it.

Do enterprise architecture frameworks still matter in the AI era?

More than before, but only the decision-making parts. AI automates discovery and keeps registers current, which strips away the documentation burden. It does not decide anything, and AI regulation now requires organisations to know exactly what systems they run, which is architecture work. The ceremony is worth less than ever. The registers and decision rights are worth more.

Related guides

Emmanuel Olatunji

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

Discuss this guide with an architect

Thirty minutes with the architect who wrote this guide. A clear recommendation and a fixed fee in writing, within one UK business day.

Talk to a senior adviser

+44 20 3985 5809  ·  info@intelance.co.uk