What enterprise architecture is and is not

People often meet TOGAF backwards. They see the ADM wheel, a pile of publication codes, or a training slide deck, and conclude that the standard is a bureaucratic diagram kit. That is the wrong starting point.

The right starting point is the definition itself. TOGAF 10, in C220 Part 1, defines enterprise architecture as follows:

"A conceptual blueprint" means enterprise architecture is not a physical object and not a piece of software. It is a model, a way of thinking about the organisation that makes important structures visible. The word "conceptual" matters because it tells you that the blueprint exists to aid understanding and decision-making, not to specify every bolt and wire.

"That defines the structure and operation of an organisation" means the scope is the whole enterprise, not one project, not one system, and not one department. Structure covers how the organisation is arranged: its business processes, its data, its applications, and its technology. Operation covers how those parts work together day to day and how they change over time.

"Its intent is to determine how an organisation can most effectively achieve its current and future objectives" means the purpose is not documentation for its own sake. The purpose is effectiveness. The architecture exists to help the enterprise make better decisions about how to reach its goals, both now and in the years ahead.

Think of it this way. If you were running London Grid Distribution, a fictional electricity distribution company serving 2.3 million customers across Greater London, you would face dozens of change pressures at once: connecting rooftop solar panels to a network designed for one-way power flow, publishing network data under regulatory mandate, defending ageing SCADA systems against cyber threats, and digitising a paper-heavy connections process. Enterprise architecture is the discipline that helps you see how all of those pressures connect and how to address them coherently rather than one project at a time.

Without enterprise architecture, each of those problems gets its own project team, its own budget, and its own technology choices. The connections project buys one workflow platform. The data publication team buys another. The SCADA modernisation programme selects a third. Two years later, the organisation discovers that three separate teams built three separate customer-identity systems because nobody was looking across the whole enterprise.

The fastest way to understand TOGAF is to keep four recurring questions in mind while you read. Every concept, every phase, every deliverable in the standard ultimately serves one or more of these questions.

Question 1: Why change?

This question covers drivers, principles, stakeholder concerns, business goals, value, constraints, and risk appetite. Before any architecture work begins, the team must understand why the enterprise needs to change at all. What business pressures exist? What regulations apply? What technology risks have become unacceptable?

For London Grid Distribution, the "why change" question has several concrete answers. The UK connections reform is changing how customers connect distributed energy resources to the network. Ofgem requires better data publication through the Long Term Development Statement. The National Cyber Security Centre expects improved OT security posture. And the board has set a net zero target that requires a fundamentally different approach to network planning. None of these pressures can be addressed by a single project working in isolation.

Question 2: What should exist?

This question covers the target state across all four architecture domains: business, data, application, and technology. What should the organisation look like after the change is complete? What business processes need to operate differently? What data needs to be available, and to whom? Which applications should exist, and how should they interact? What technology platforms underpin everything?

For London Grid, "what should exist" means defining a coherent target across multiple domains simultaneously. The business architecture needs a connections process that can handle two-way power flow and customer self-service. The data architecture needs a single authoritative source of network asset data that supports both the distribution management system and regulatory reporting. The application architecture needs integration between the connections workflow, the geographic information system, and the SCADA control layer. The technology architecture needs secure, monitored infrastructure that can support real-time operational data without exposing critical control systems to the internet.

Question 3: How do we move?

This question covers gap analysis, work packages, transition architectures, migration choices, sequencing, and roadmaps. The target state is rarely achievable in a single step. The enterprise must move through intermediate states, each of which must be stable enough to operate while the next change is prepared.

For London Grid, the move is staged. The first transition might focus on establishing a single asset register and migrating the connections process to a digital workflow. The second transition might integrate that workflow with the GIS and introduce automated data feeds for LTDS publication. The third might tackle SCADA modernisation and the OT security uplift. Each transition must leave the network safe and the lights on. You cannot take the control room offline for six months while you upgrade the infrastructure.

Question 4: How do we sustain it?

This question covers governance, Architecture Board behaviour, compliance, contracts, roles, skills, and change control. Architecture is not a one-off exercise. Once the target state is defined and the transition plan is in motion, something must keep the whole enterprise aligned. Projects will drift. New pressures will emerge. Technology choices will need revisiting.

For London Grid, sustaining the architecture means establishing an Architecture Board that reviews major technology decisions before they are committed, a repository that connects principles to decisions to work packages so anyone can trace why a choice was made, and a change management process that detects when business or regulatory shifts require a new architecture cycle.

Every TOGAF concept fits somewhere in this frame. If a piece of the standard feels detached, ask which of the four questions it answers. That exercise keeps reading on course.

Before TOGAF 10, the standard was structured as a single large body of text. TOGAF 9.2 was a monolithic document: practitioners had to work out for themselves which sections were the durable spine of the method and which sections were contextual extensions that could be adopted selectively. The shift from TOGAF 9.2 to TOGAF 10 was structural, not cosmetic. It reorganised the entire publication model into three distinct layers, each with a different role and a different rate of change.

Layer 1: The six Fundamental Content volumes

These six documents are the backbone of the standard. They are intended to be stable over time. When you need the canonical, authoritative answer to an architecture question, this is where you look first. The six volumes are:

1. C220 Part 0: Introduction and Core Concepts. This volume is the conceptual front door. It covers what enterprise architecture is, the four architecture domains (business, data, application, technology), architecture principles, the enterprise continuum, viewpoints and views, architecture services, agility, and risk. Read Part 0 first when you are new to the standard or when you need to ground a conversation in first principles.
2. C220 Part 1: Architecture Development Method. This volume contains the ADM itself: the Preliminary Phase, Phase A (Architecture Vision), Phase B (Business Architecture), Phase C (Information Systems Architectures), Phase D (Technology Architecture), Phase E (Opportunities and Solutions), Phase F (Migration Planning), Phase G (Implementation Governance), Phase H (Architecture Change Management), and Requirements Management. This is the operating cycle of TOGAF.
3. C220 Part 2: ADM Techniques. This volume provides disciplined techniques for handling stakeholder management, principles, patterns, gap analysis, migration planning, interoperability, readiness assessments, risk evaluation, and trade-off methods. These techniques are used alongside the ADM phases, not instead of them.
4. C220 Part 3: Applying the ADM. This volume explains what happens when the ideal ADM cycle meets enterprise reality. It covers iteration (you almost never run the phases in a single linear pass), the architecture landscape (how strategic, segment, and capability architectures relate), and partitioning (how large enterprises divide architecture work across teams and domains).
5. C220 Part 4: Architecture Content. This volume defines what architecture work should produce and how the outputs relate to each other. It covers deliverables, artefacts, views, viewpoints, building blocks (both architecture building blocks and solution building blocks), the repository structure, and the content metamodel that defines how all architecture content is logically organised.
6. C220 Part 5: Enterprise Architecture Capability and Governance. This volume covers the sustaining mechanism: how to establish and operate an architecture capability, how the Architecture Board should behave, how compliance reviews work, how architecture contracts hold delivery teams accountable, and how change management keeps the architecture relevant as the enterprise evolves.

Layer 2: The Series Guides

Series Guides are official publications that explain how to use the core in specific contexts. They are not optional extras or marketing material. They are the main vehicle for practical and topical depth. If the Fundamental Content is the operating system, the Series Guides are the configuration layer that adapts the operating system to the problem in front of you.

Examples include guides on business architecture, digital enterprise, enterprise agility, agile architecture sprints, information mapping, customer master data, metadata management, business intelligence and analytics, risk and security, microservices, sustainability, and more. Module 2 covers the full Series Guide catalogue.

Layer 3: The TOGAF Library

The TOGAF Library is the supporting layer for helpful aids and related material. This is where you find reference cards, pocket guides, templates, and other practical accelerators. Library material supports the main standard rather than replaces it. It is official, but it carries less authority than the Fundamental Content or the Series Guides.

This three-layer structure is the most important change from TOGAF 9.2. It means you do not read every document the same way. You learn the operating model from the core, then configure it with the guide that fits the problem. That separation makes the standard modular by design, and modular standards are easier to teach, easier to adopt, and easier to extend without breaking the core method.

The documents make sense when you read them as layers of authority and use. The top layer is the most authoritative. Lower layers become more supportive and more practical. Understanding this hierarchy is the prerequisite for navigating the standard without getting lost.

Authoritative: TOGAF Fundamental Content

This is the stable core. When two sources disagree, the Fundamental Content wins. It is the first place to go when you need the canonical answer to a question about the ADM, about what architecture work should produce, or about how governance should operate. The six volumes change slowly and deliberately, through formal revision processes with corrigenda (corrections) applied transparently.

Authoritative and configurable: TOGAF Series Guides

Series Guides are official publications. They carry authority within their scope. But they are designed to be selected based on the problem at hand rather than read exhaustively. A team working on business architecture will reach for the business capability and value stream guides. A team working on digital transformation will reach for the digital enterprise and agility guides. You are not expected to read all 26 guides before starting work. You are expected to know they exist and to reach for the right one when the problem demands depth.

Supportive: TOGAF Library

Library material is official but supportive. It helps you use the standard more effectively. It does not replace or override the core. Reference cards, pocket guides, and templates live here. Use this layer after you understand whether the answer you need is normative (from the core) or contextual (from a guide).

Supportive: Training and certification material

Training slides, practice exams, study guides, and certification syllabuses are useful for learning and checking understanding. But they are not a substitute for the standard or the official guidance set itself. A common mistake is to treat the certification syllabus as the boundary of what TOGAF is. The syllabus defines what the exam tests, not what the framework contains. Real architecture practice is broader than any single exam path.

How a practitioner navigates this hierarchy

In practice, navigation follows a predictable pattern. You start with the Fundamental Content to understand the canonical concepts, the ADM cycle, and the governance model. When a specific problem requires deeper treatment than the core provides, you reach for the relevant Series Guide. When you need a practical template or reference card, you check the Library. And when you need to understand what a certification exam covers or structure a study plan, you consult the certification material while remembering that it maps to (but does not replace) the standard.

The key discipline is always knowing which layer you are reading from. A claim made in a training slide carries less weight than a statement in Part 1 of the Fundamental Content. A recommendation in a Series Guide carries authority within its domain but does not override the core. Getting this hierarchy clear in your mind prevents the confusion that most beginners experience when they encounter the TOGAF document set for the first time.

The six Fundamental Content volumes are not six independent books. They interact during every architecture engagement. Here is the typical flow:

1. Drivers and scope. Part 0 and the Preliminary Phase (from Part 1) help you frame the enterprise, identify stakeholders, establish principles, and understand the operating context before any design work begins.
2. Architecture cycle. Part 1 runs the work through the Preliminary Phase and Phases A to H, with Requirements Management threading across every phase as a continuous process.
3. Decision techniques. Part 2 adds disciplined tools such as stakeholder management, gap analysis, migration planning, interoperability assessment, readiness evaluation, risk management, and trade-off methods. You use these techniques within the phases, not as a separate activity.
4. Practical adaptation. Part 3 explains how to iterate (because real work never follows a single linear pass), how to partition architecture work across a large enterprise, and how strategic, segment, and capability architectures relate to each other.
5. Outputs and repository. Part 4 defines what architecture work should produce: deliverables, artefacts, views, viewpoints, building blocks, repository structure, and the metamodel that organises all architecture content.
6. Governance loop. Part 5 keeps the architecture capability alive through governance, Architecture Board behaviour, compliance reviews, architecture contracts, and change management.

For London Grid Distribution, the flow would work like this. Part 0 helps the team frame the enterprise scope (all of London Grid, not just the IT department) and establish principles (such as "data published for regulatory purposes must come from a single authoritative source"). Part 1 guides the team through each ADM phase. Part 2 provides the gap analysis technique that compares the current connections process to the target. Part 3 explains how to partition the work so that network operations architecture and customer-facing architecture can proceed in parallel. Part 4 defines what each phase should produce. Part 5 sets up the governance that prevents project teams from making technology choices that contradict the agreed architecture.

Defining what something is becomes clearer when you also define what it is not. Five common confusions cause real problems in organisations adopting TOGAF for the first time. Each one deserves explicit correction.

Enterprise architecture is not solution architecture

Solution architecture designs a specific system or project. It answers questions like "which database should this application use?" and "how should these two services communicate?" Enterprise architecture operates at a higher level. It answers questions like "across all our projects, are we building toward a coherent target state or are we creating accidental duplication?"

At London Grid, the solution architect for the connections workflow might choose a specific workflow engine and a specific API gateway. The enterprise architect would ask whether that workflow engine is consistent with the organisation's integration strategy and whether the API gateway is the same one being used by the LTDS publication team, or whether two teams have independently chosen two different products.

Enterprise architecture is not project management

Project management delivers a defined scope on time and within budget. Enterprise architecture defines the target state and the transition logic that project management then delivers. The two disciplines need each other, but they are not the same thing. Confusing them leads to architecture teams that track Gantt charts instead of designing cross-enterprise coherence, or project managers who make technology choices without architecture input.

Enterprise architecture is not documentation theatre

This is the failure mode from the opening story. Documentation theatre happens when architecture work produces volumes of diagrams, catalogues, and matrices that nobody reads and nobody uses to make a decision. The test is simple: if you removed the architecture artefacts tomorrow, would any cross-enterprise decision move differently? If the answer is no, the programme is producing documentation, not architecture.

Enterprise architecture is not IT strategy

IT strategy defines the direction for technology investment. Enterprise architecture is broader. It covers business processes, data, applications, and technology together. An IT strategy might say "we will move to the cloud." The enterprise architecture asks "which workloads should move, in what order, with what data sovereignty constraints, and how does the cloud migration interact with the SCADA modernisation programme that cannot move to the cloud for safety reasons?"

Enterprise architecture is not a one-off exercise

Some organisations treat enterprise architecture as a project with a start date and an end date. They produce a target state document, declare success, and disband the team. This misses the point. The ADM is a cycle, not a line. Phase H (Architecture Change Management) exists precisely because the enterprise keeps changing. Business pressures shift. Technology evolves. Regulations are updated. The architecture must evolve with them, which means the architecture capability must be sustained, not dissolved after the first design pass.

Section 1.3 introduced the six volumes. This section gives you enough detail to know what each one is for and when to reach for it.

C220 Part 0: Introduction and Core Concepts

Use this when you need the conceptual front door. Part 0 defines what enterprise architecture is, introduces the four architecture domains (business, data, application, technology), explains architecture principles, describes the enterprise continuum (a way of classifying assets from generic to organisation-specific), introduces viewpoints and views (how different stakeholders see the architecture), defines architecture services (what the architecture capability does for the enterprise), and addresses agility and risk. If you are new to TOGAF, Part 0 is the starting point.

C220 Part 1: Architecture Development Method

Use this when you need the operating cycle itself. Part 1 contains the Preliminary Phase (setting up the architecture capability), Phase A (creating the architecture vision and securing stakeholder buy-in), Phase B (business architecture), Phase C (information systems architectures, covering both data and applications), Phase D (technology architecture), Phase E (identifying opportunities and solutions), Phase F (migration planning), Phase G (implementation governance), Phase H (architecture change management), and Requirements Management (the continuous process that feeds requirements into every phase). The ADM is the most recognised part of TOGAF, but it is one part of six.

C220 Part 2: ADM Techniques

Use this when you need disciplined ways to handle specific challenges within the ADM. The techniques covered include architecture principles (how to define and use them), stakeholder management, architecture patterns, business scenarios (a technique for discovering requirements through stories about real business problems), gap analysis, migration planning, interoperability, readiness assessment, risk management, and capability-based planning.

C220 Part 3: Applying the ADM

Use this when the ideal ADM cycle meets enterprise reality. Part 3 covers iteration (how to run the ADM in cycles and sprints rather than a single linear pass), the architecture landscape (how strategic architecture, segment architecture, and capability architecture relate), partitioning (how to divide architecture work across a large enterprise), and the different engagement models needed in different situations.

C220 Part 4: Architecture Content

Use this when you need to understand what architecture work should produce and how the outputs relate. Part 4 covers deliverables (formally reviewed and signed-off work products), artefacts (specific documents, diagrams, tables, or lists), views and viewpoints, building blocks (both architecture building blocks and solution building blocks), the content framework that organises all outputs, the content metamodel that defines the logical structure of architecture information, and the repository that stores it all.

C220 Part 5: Enterprise Architecture Capability and Governance

Use this when you need the sustaining mechanism. Part 5 covers how to establish and mature an architecture capability, how the Architecture Board should operate, how compliance reviews check that implementations match the approved design, how waivers handle exceptions when projects cannot fully comply, how architecture contracts hold delivery teams accountable, and how architecture maturity assessment guides investment in the capability itself.

The Series Guides are easier to navigate when you group them by the problem they address rather than by publication code. Here are the main groupings this course uses.

Leadership and practice

These guides help you stand up architecture as a real operating capability rather than a documentation side activity: G184 (Leader's Guide to Establishing and Evolving an EA Capability) and G186 (Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM).

Business architecture

These guides deepen the business layer so TOGAF can shape strategy, operating model, capabilities, value delivery, and planning: G18A (Business Models), G211 (Business Capabilities), G178 ( Value Streams), G233 (Business Capability Planning), G176 (Business Scenarios), and G206 (Organisation Mapping).

Digital, agile, and information-heavy delivery

These guides matter when teams think TOGAF is incompatible with digital operating models, sprint-based delivery, or serious information architecture: G217 (Digital Enterprise), G20F (Enterprise Agility), G210 (Agile Architecture Sprints), G190 (Information Mapping), G21B (Customer Master Data), G234 ( Metadata Management), and G238 (Business Intelligence and Analytics).

Specialist contexts

These guides let the core method carry security, microservices, sustainability, building-block choice, and public-sector reference models more credibly: G152 (Risk and Security), G21I (Microservices), G248 (Selecting Building Blocks), G242 (Sustainable Information Systems), and G21D (Government Reference Model).

The following scenarios illustrate how the document hierarchy works in practice. Each scenario names the starting documents and explains why.

Stand up or repair the EA capability: Start with C220 Part 5 (which defines the capability and governance model), then add G184 (Leader's Guide) and G186 (Practitioners' Approach). Part 5 tells you what the capability should look like. The guides tell you how to build it.

Design a target direction for enterprise change: Start with C220 Part 0 (core concepts and principles), then move to C220 Part 1 Phase A (Architecture Vision), and add G176 (Business Scenarios) to discover requirements through structured storytelling.

Map business capabilities and value streams: Start with G211 (Business Capabilities), G178 (Value Streams), G233 (Business Capability Planning), and then add G18A (Business Models) or G176 (Business Scenarios) where needed.

Run TOGAF in digital or agile delivery: Start with G217 (Digital Enterprise), G20F (Enterprise Agility), G210 (Agile Architecture Sprints), and keep C220 Part 3 (Applying the ADM) nearby for iteration and partitioning guidance.

Fix information and data architecture: Start with G190 (Information Mapping), then go to G21B (Customer Master Data), G234 (Metadata Management), and G238 (Business Intelligence and Analytics) based on the specific data problem.

Authoritative first. The six Fundamental Content volumes are the backbone of the standard. If a Series Guide appears to contradict the core, the core wins. The Series Guides are official guidance that configure and extend that backbone in specific contexts. They carry authority within their scope, but they do not override the Fundamental Content. The TOGAF Library is official supporting material and should be treated as helpful, not random extras, but secondary to the core and the guides.

Supportive but secondary. Learning studies, practice tests, slides, and course notes can help you learn, but they do not replace the standard or the guides. Case studies are useful for application, but they remain examples rather than the framework itself. A common error is to quote a training slide as if it were the standard. Always trace claims back to the Fundamental Content or the relevant Series Guide.

The BOK Guide (02.1). The Open Group publishes a Body of Knowledge Guide (publication code 02.1) that serves as a navigation document for the TOGAF ecosystem. It is not the standard itself. It is a map that helps you find your way through the publication set. Think of it as the table of contents for the entire TOGAF library. It is particularly useful when you know what topic you need but are not sure which publication code to look for.

This module sets the recurring case that the rest of the course uses. London Grid Distribution is a fictional electricity distribution network operator serving 2.3 million customers across Greater London. It operates 36 primary substations, over 4,800 secondary substations, and roughly 42,000 kilometres of underground cable. By the time you have completed the three primer modules that precede this course, you already know what London Grid does, who its key stakeholders are, and what pressures it faces.

In London Grid Distribution, the four basic TOGAF questions already appear clearly.

Why change: connections reform is changing how customers connect solar panels, batteries, and EV chargers to the network. LTDS publication quality is under regulatory scrutiny. Cyber resilience expectations are tightening. And governance pressure from Ofgem requires demonstrable improvement in how the organisation plans and reports.

What should exist: the enterprise needs coherent business, information, application, and technology views rather than isolated project artefacts. The connections process needs to handle two-way power flow. The asset register needs to be authoritative. The Common Information Model needs to underpin data exchange. And the SCADA and DMS layer needs secure, monitored infrastructure.

How do we move: the transformation needs staged transition logic, evidence-led roadmaps, and decision traceability. You cannot take the control room offline for six months. Each transition state must leave the network safe and the lights on.

How do we sustain it: the Architecture Board, repository, principles, and compliance logic must keep architecture alive after the first design pass. London Grid's regulatory environment means architecture decisions have real consequences: a poorly governed technology choice could affect supply security for millions of customers.

• Connections reform pressure becomes a business-architecture and operating-model problem, not just a queue-management problem.
• LTDS and data-publication obligations become an information-architecture problem, not just a reporting problem.
• OT, IT, telecoms, and cyber expectations become a cross-domain architecture problem, not just a security workstream.
• The DSO transition (from passive distribution network operator to active distribution system operator) becomes a whole-enterprise architecture challenge that touches every domain simultaneously.