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.


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:
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.
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.
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.
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.
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:
| Force | Context |
| 1. Cost avoidance and spend discipline | Your 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 alignment | Most 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 readiness | The 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 risk | That 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 reduction | Poor 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)
Before we compare frameworks, you need one clarifying model. Not all “frameworks” are the same thing.
| Type | What it does | Examples |
|---|---|---|
| Method | A repeatable process for developing and governing architecture | TOGAF ADM |
| Classification / taxonomy | Ensures complete coverage and prevents blind spots | Zachman |
| Modelling language | A standard way to describe and visualise architecture relationships | ArchiMate |
| Delivery operating model | How teams deliver change at scale (where architecture must integrate) | SAFe (Enterprise Architect role, runway) |
| Architecture description discipline | Forces clear viewpoints, concerns, and stakeholder-aligned descriptions | ISO/IEC/IEEE 42010 |
If you remember one thing: choose a blend across categories rather than a single brand.
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.

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:

This cycle ensures continuous alignment between technology capability and business strategy.
| Strengths | Limitations |
|---|---|
| Comprehensive governance structure | Can become bureaucratic when applied rigidly |
| Industry-recognised certification | Full ADM cycle takes 6 to 18 months |
| Repeatable, auditable processes | Documentation-heavy by design |
| Strong stakeholder management | Weak on change management |
| Extensive documentation library | Does 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
Where TOGAF fails
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.

What TOGAF should produce (in the real world)
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:
| What | How | Where | Who | When | Why |
|---|---|---|---|---|---|
| Data | Function | Network | People | Time | Motivation |
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.

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
Where ArchiMate fails
How we use ArchiMate
We use ArchiMate selectively for the models that drive decisions:
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:

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.

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:
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 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
Where ISO 42010 fails
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.
This is the question every CIO asks. And every consultant gives you a non-answer: “It depends.” Here is an actual decision framework.
| Criteria | TOGAF | Zachman | Gartner | Intelance EA Velocity Method |
|---|---|---|---|---|
| Best for | Large enterprise governance | Taxonomy and documentation | Business alignment | Rapid value delivery |
| Time to value | 6 to 18 months | 3 to 6 months | 2 to 4 months | 2 to 6 weeks |
| Governance depth | Deep and formal | None: it is a taxonomy rather than a method | Light | Deep where decisions need it, light everywhere else |
| Business focus | Medium | Low | High | High |
| Agility | Low unless simplified | Low | Medium | High |
| Learning curve | High (certification) | Medium | Low to medium | Low (guided) |
| Cost | Free + cert costs | Free | Paid subscription | Fixed published fees |
Every CIO, CTO or enterprise leader searching for the best enterprise architecture framework is usually asking the wrong question.

Answer these five questions to identify your optimal framework approach:
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.
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.
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.
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.
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?”
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.

We have found that successful EA frameworks operate across three distinct layers, each drawing from different framework strengths:
We use TOGAF’s Architecture Development Method for governance gates, but we simplify the ten-phase cycle into four practical stages:
This preserves the governance discipline of TOGAF while cutting the ceremony that slows it down.
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.
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.”
| Phase | Duration | Activities | Deliverables |
|---|---|---|---|
| 1. Discovery | Days 1 to 3 | Stakeholder interviews, existing documentation review, Zachman completeness check | Architecture scope definition, stakeholder map |
| 2. Mapping | Days 4 to 7 | Current-state application inventory, capability mapping, dependency analysis | As-is architecture views, capability heat map |
| 3. Analysis | Days 8 to 10 | Gap analysis, risk assessment, cost-benefit modelling, technical debt quantification | Risk register, opportunity matrix, technical debt report |
| 4. Design | Days 11 to 14 | Target-state architecture options, principles definition, governance model design | To-be architecture views, architecture principles |
| 5. Roadmap | Days 15 to 18 | Migration planning, initiative sequencing, investment prioritisation | Transformation roadmap, business case |
| 6. Governance | Days 19 to 21 | Operating model design, governance implementation, handover | EA operating model, governance playbook, executive deck |
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.
This is where most enterprise architecture engagements fail. The cause is rarely a weak framework. It is framework religion.

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:
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.
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.
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.
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.
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.
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.
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.
Whether you are starting an EA function from scratch or fixing a broken one, here is a practical 90-day playbook.

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.
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.
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.
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.
| Service | What you get | Price and time |
|---|---|---|
| EA QuickScan | Every system inventoried and scored for cost, fit and risk, with a costed roadmap and board readout | from £18,000 + VAT · 10 working days |
| EA Operating Model | The working parts of an EA function: decision rights, standards, forums and proof of value, built to fit you | Diagnostic from £18,000 + VAT · full builds from £95,000 |
| ProjectEA | Senior architects inside your programme, protecting the systems you own on day two | from £45,000 + VAT per programme |
| Virtual EA Department | The 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.
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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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 IntelanceThirty 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
Enterprise Architecture
