Course revision guide

25 min read 9 stages distilled 10 figures

The whole course in one place, arranged for revision. Each stage below gives you its figure, the distinctions worth holding in your head, and the fastest routes back into the full material. Skim the figures first, then test yourself against the distinctions: anything you cannot explain from memory points at the stage to revisit.

The method on one page

Everything the course teaches hangs off one cycle and four questions. The Preliminary Phase readies the capability, Phases A to H run vision, the four architectures, delivery, and change, and Requirements Management disciplines every step. The four questions keep any organisation honest, whether it runs hospitals, payments, or power networks: why change, what should exist, how do we move, and how do we sustain it.

The TOGAF ADM is an iterative cycle of eight phases

The method turns as a ring, but it is iterative, not a single pass: you iterate within a phase, loop back between phases, and repeat the whole cycle, re-entering at the phase that fits rather than restarting at A. Requirements Management is two-way with every phase.

The TOGAF ADM is an iterative cycle of eight phases The TOGAF architecture development method as a ring of eight phase panels around a central Requirements Management hub. A Preliminary Phase panel enters at Phase A, Vision, then clockwise arcs run through B Business, C Information systems, D Technology, E Opportunities and Solutions, F Migration planning, G Implementation governance and H Architecture Change Management, closing back to A. The method is iterative, not a single pass, and two-way spokes join the hub to every phase. AVisionThe Architecture Visionand remit BBusinessThe businessarchitecture CInformationsystemsData and applicationarchitecture DTechnologyThe technologyarchitecture EOpportunities andSolutionsSolution options andwork packages FMigrationplanningThe implementation andmigration plan GImplementationgovernanceDelivery held to thearchitecture HArchitecture ChangeManagementKeeping the livearchitecture current Requirements Management Feeds and checks every phase enters at Preliminary PhasePrinciples and the architecture capability TOGAF applies the ADM iteratively through four overlapping cycles, not as a single pass: Context (Preliminary and A) · Definition (B to D) · Transition Planning (E and F) · Governance (G and H)

Stage 0: How an electricity network works and why coherence needs architecture

Voltage steps down from the grid to your wall socket

Electricity reaches you through five voltage steps, each a handover between operators: NESO runs the 400 and 275 kV transmission grid, and from the 132 kV grid supply point down to the 230 V socket the network is licensed to the distribution operator.

Voltage steps down from the grid to your wall socket A vertical ladder of five voltage tiers, highest at the top and lowest at the bottom, with a left axis pointing down labelled voltage steps down and the voltage band shown beside each tier. From the top: Transmission at 400 and 275 kV run by NESO; the grid supply point at 132 kV, where transmission hands over to local distribution; primary distribution at 33 kV; secondary distribution at 11 kV; and the customer outlet at 230 V. A structural brace on the right spans the grid supply point down to the outlet, labelled DNO licence boundary, marking everything from 132 kV down to 230 V as licensed to the distribution network operator. Voltage steps down 400/275 kVTransmissionBulk power from generation across the country on overhead linesNESO 132 kVGrid supply pointThe formal handover from transmission to local distributionNESO / DNO 33 kVPrimary distributionBulk feeders out to primary substations that step voltage downDNO 11 kVSecondary distributionLocal feeders along streets to the substation by each estateDNO 230 VCustomer outletService cable into the meter cabinet at the customer premisesDNO / Customer DNO licence boundary

Hold these distinctions

  • Electricity is the flow of electrons through a conductor, voltage is the push, and higher voltage loses less energy as heat over long distances
  • The journey to the socket has three stages, generation, transmission at 275,000 or 400,000 volts, and distribution stepping down to 230 volts
  • Generation and demand must match at every moment, frequency near 50 hertz is the grid's heartbeat, and a deep fall triggers load shedding
  • Once electrons are on the network, wind, gas, and solar are indistinguishable
  • NESO operates the electricity system it does not own, and 14 licensed DNOs manage the local networks of England, Scotland, and Wales
  • London Grid runs five core systems, SCADA the heart monitor, DMS the satnav, GIS the map, OMS the fault tracker, and ERP the business backbone
  • Three forces drive the company's change, Clean Power 2030, two-way flow from rooftop solar, and the electrification of heat and transport
  • Architecture is a light set of agreed decisions about how the parts of an enterprise fit and change together, applied before the change is made

Stage 1: What enterprise architecture is for and how TOGAF 10 is shaped

The normative Standard set against the explanatory Series Guides

The Standard is TOGAF's normative source of truth and the Series Guides only explain how to apply it, so the Series Guides update faster on single topics but never override the Standard: when the two disagree, the Standard wins.

The normative Standard set against the explanatory Series Guides A two-column comparison matrix. A left label column lists four properties, and each row answers both sides at the same height. The Standard, code C220, is the normative single source of truth and takes the accent tint on its header and every cell as the authoritative side; the Series Guides, code G-series, are explanatory and practitioner-facing on a calm neutral fill. The rows compare status, change rate, audience and role, contrasting normative against explanatory, slow whole-document cycles against faster single topics, auditors and the board against practitioners, and what TOGAF says against how to apply it. The accent marks the Standard as the side that wins when the two disagree. Propertycompared C220The StandardNormative, single source of truthG-seriesSeries GuidesExplanatory, practitioner-facing StatusNormative source of truthExplanatory, not binding Change rateSlow, whole-document cyclesFaster, single topics AudienceAuditors, certifiers, the boardPractitioners on a programme RoleDefines what TOGAF saysShows how to apply it

Hold these distinctions

  • The TOGAF Standard defines architecture as the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
  • If removing an artefact would change no cross-enterprise decision, it is documentation theatre, not architecture
  • Four questions organise the standard: why change, what should exist, how do we move, how do we sustain it
  • TOGAF 10 is three layers: the six C220 Fundamental Content volumes, the Series Guides, and the supporting Library
  • Foundation tests the core Standard, Practitioner tests applied use, and practice is always broader than the syllabus
  • A deliverable is signed off, an artefact is one representation inside it, a building block is the reusable element behind it, and ABBs stabilise before SBBs
  • A repository earns its name through traceability from principle to decision to work package to governance record
  • In the London Grid case, every claim is one of four kinds: verified GB fact, TOGAF concept, enterprise design, or teaching scenario

Stage 2: Opening a cycle: Preliminary Phase and the Architecture Vision

From stakeholder to concern to the viewpoint that answers it

TOGAF binds every viewpoint to a named stakeholder and the concern they own, so a viewpoint with no owning concern is decoration and a concern with no viewpoint is unmet accountability, which is why the regulator's compliance trace is the one that keeps the licence safe.

From stakeholder to concern to the viewpoint that answers it Three labelled lanes, Stakeholder, Concern owned and Viewpoint that answers it, hold five rows traced left to right by accent arrows labelled owns and answers. The Executive board owns strategic outcomes, answered by the capability viewpoint. The Operations director owns live service continuity, answered by the operational viewpoint. The Regulator row, tinted as the structural emphasis, owns licence compliance, answered by the compliance viewpoint. The Chief security officer owns risk and exposure, answered by the security viewpoint. The Finance director owns cost and price control, answered by the cost viewpoint. Stakeholder Concern owned Viewpoint that answers it Executive boardSets directionownsStrategic outcomesAre we building it rightanswersCapability viewpointWhat the enterprise can do Operations directorRuns the serviceownsLive servicecontinuityWill it stay up under loadanswersOperational viewpointRuntime nodes anddependencies RegulatorHolds the licenceownsLicence complianceDoes it meet obligationsanswersCompliance viewpointControls mapped toobligations Chief security officerOwns risk postureownsRisk and exposureWhere can it be attackedanswersSecurity viewpointTrust boundaries andthreats Finance directorOwns the budgetownsCost and price controlIs the spend justifiedanswersCost viewpointRun cost against value

Hold these distinctions

  • The Preliminary Phase has two objectives, determine the Architecture Capability the organisation wants and establish it, and it hands Phase A five named outputs led by the sponsor-issued Request for Architecture Work
  • The enterprise boundary is defined by what materially constrains design and governance, so a regulator can sit inside it while a whole internal division stays out
  • Tailoring is a conscious, recorded adaptation of TOGAF, and skipping the hard parts without recording why is omission, not tailoring
  • Stakeholder, concern, viewpoint, and view form a chain, and a concern only counts when it is specific enough to shape what a view shows
  • A principle needs a name, a statement, a rationale, and implications, and it is only working when it creates productive tension in real decisions
  • A business scenario turns symptoms into architecture-relevant reality by naming actors, environment, constraints, and measurable outcomes
  • Scope is a design decision on four dimensions, breadth, depth, time, and domains, and recorded exclusions are what keep it honest
  • Sponsorship provides access, a path into delivery governance, and conflict-resolution support, none of which budget approval alone provides
  • The Architecture Vision gives direction and the Statement of Architecture Work gives commission, and Phase A ends only when both exist and reinforce each other

Stage 3: Phase B: a business layer that changes real decisions

The Phase B pipeline from Phase A inputs to Phase C and D outputs

Phase A inputs flow down into the in-phase architecture work, pass a single governance gate, and leave as a signed-off business architecture, so Phase C and D inherit only the artefacts that cleared the gate and never a raw draft.

The Phase B pipeline from Phase A inputs to Phase C and D outputs A vertical pipeline of five stages joined by blue flow arrows. Inputs from Phase A, owned by Phase A: Vision, Statement of Work, principles, stakeholder map, scope. An arrow labelled model the business leads to Phase B activities, owned by the Architect: capability map, value streams, gap analysis. An arrow labelled produce leads to Deliverables, owned by Phase B: baseline and target business architecture. An arrow labelled submit for review reaches the accent-tinted Governance gate, reviewed by the architecture board against the principles. An arrow labelled sign off leads to Outputs to Phase C and D: the signed-off architecture and gap list those phases inherit. InInputs from Phase AVision, Statement of Work, principles, stakeholder map, scopePhase Amodel the business WorkPhase B activitiesModel business, capability map, value streams, gap analysisArchitectproduce OutDeliverablesBaseline plus target business architecture, gap analysis reportPhase Bsubmit for review GateGovernance gateArchitecture board reviews the work against the principlesArch boardsign off NextOutputs to Phase C and DSigned-off business architecture, gap list for Phase C and DPhase C / D

Hold these distinctions

  • Phase B develops a target Business Architecture, and the baseline exists only to make the gap visible
  • A business model describes how the enterprise creates, delivers, and captures value, and a regulated utility has one through service obligations, accountability, information duties, and price control funding
  • An organisation map reads actors, roles, and interactions to expose ownership gaps and interface risk, which reporting lines never show
  • A capability is a stable ability tied to a purpose, named independently of systems, teams, and processes, and its name must survive a system replacement
  • A capability map becomes a planning instrument only when its ratings are evidence-anchored and a real investment, governance, or depth decision moves because of it
  • A value stream is an end-to-end collection of value-adding stages for a triggering stakeholder, and a stream without all six elements has been drawn but not mapped
  • Goals drive services, services require capabilities, and measures evaluate both, so a target without measures is an assertion, not an architecture
  • Every significant gap carries why it matters, its consequence, its dependencies, and its intervention type, and not every business gap is a system gap
  • An artefact earns its place by changing a decision, exposing a dependency, or informing a governance outcome, and anything below that bar is theatre

Stage 4: Phase C: data before applications, authority before integration

The two parallel tracks of TOGAF Phase C and their joint gap output

Phase C takes the Phase B handover and runs data architecture and application architecture as two equal workstreams at once, then merges them into one integrated gap analysis, so Phase D gets a single signed-off architecture, not a data gap and an application gap settled apart.

The two parallel tracks of TOGAF Phase C and their joint gap output A converging two-track flow for TOGAF Phase C. A wide accent-tinted input panel holds the Phase B handover: baseline, target and the agreed gap list. Two arrows labelled feeds split down to two equal side-by-side tracks: Data architecture with information domains, a source-of-truth map, models and lineage, and Application architecture with its portfolio, logical components and interfaces, which a centre note says run in parallel. Two arrows labelled converge merge the tracks into one accent-tinted panel, the joint gap analysis, a single integrated gap report owned by Phase C. An arrow labelled signs off leads to an output panel of signed-off architecture handed to Phase D. Shared inputs from Phase B Business architecture handoverBaseline, target and the agreed business gap listPhase B feeds feeds Track one Data architectureInformation domains and source-of-truth mapLogical and physical data models, lineageArchitect Track two Application architecturePortfolio, logical components and interfacesApplication-to-data mapping, integrationsArchitect run in parallel converge converge Joint gap analysisOne integrated data-and-application gap reportPhase C signs off Handover to Phase D Signed-off architectureApproved data and application architecture, ready for Phase DPhase D

Hold these distinctions

  • Phase C develops data and application architecture together because authority, integration, and publication choices are coupled, and separating them produces conflict at the boundaries
  • An information map groups information into business-relevant domains that survive system change, not an inventory of current databases
  • Source of truth is useful only when bounded by entity, attribute, consumer, and purpose, and the five-layer ownership model records the distributed reality
  • Customer MDM settles six decisions before any platform: entity definition, shared attributes, authority, matching rules, stewardship, and the decision use case
  • The CIM is a shared semantic vocabulary, not a mandatory schema, and alignment means documented, governed mappings at the boundaries
  • Metadata carries six minimum concerns, meaning, provenance, stewardship, lifecycle, classification, and quality, and without them technically accurate data can mislead
  • A dashboard is an output of the analytics architecture, and the semantic layer beneath it is the most common failure point
  • An ABB is technology-aware but product-neutral, and an SBB is product-specific and constrained by the ABB it realises
  • The Phase C validation test is end-to-end traceability: a governance board can trace any published figure back to its authoritative source through every layer of the pack

Stage 5: Phase D: technology choices that trace back to the layers above

Phase D technology traceability from need to platform to owner

Phase D records a platform choice only when it traces both ways: back to the application need that drives it and forward to the team that runs it in production, because a platform with no driving need is gold-plating and one with no named owner is an outage waiting to happen.

Phase D technology traceability from need to platform to owner A three-column traceability chain: Application need, Platform choice and Owner who runs it. Four rows run left to right, each joined by a drives arrow then a runs arrow. A data store need drives Postgres, ADX and S3, run by the data platform team. Messaging drives Kafka and RabbitMQ, run by the integration team. Identity drives Entra ID with OAuth, run by the identity team. Runtime drives Kubernetes and Fargate, run by platform engineering. The middle platform column carries the accent tint as the choice Phase D records, sitting between the need that drives it and the owner that runs it. Application needPlatform choiceOwner who runs itdrivesruns Data storeRelational, time-series, objectPostgres, ADX, S3Chosen per data shapeData platform teamBackups, performance MessagingEvent distribution, queuesKafka, RabbitMQChosen per latency needIntegration teamTopic governance, schema IdentityAuthentication, authorisationEntra ID + OAuthStandard single sign-onIdentity teamMFA, account lifecycle RuntimeCompute, schedulingKubernetes, FargateChosen per workloadPlatform engineeringCluster ops, autoscaling

Hold these distinctions

  • Phase D enables the business, data, and application architectures, and the word enables is the test of whether a technology target is genuine architecture
  • The traceability test asks whether the technology target could have been written before the earlier stages existed
  • Controlled variance beats both rigid standardisation and uncontrolled freedom: strong defaults, governed exceptions, and interoperability rules that apply to both
  • TOGAF formally lists three interoperability categories and this course teaches four lenses, all assessed at every major platform boundary
  • Early security changes the architecture, late security mostly raises cost and exception volume
  • Microservices are an enterprise decision, so the four-dimension assessment is recorded before any commitment
  • Sustainability counts only when it changes a recorded trade-off, and it never overrides safety or operability
  • Gaps are missing capabilities, not missing products, and ADRs in the Nygard format keep the trade-offs defensible
  • A landing zone is the enterprise doing its half of the shared responsibility model once and by default

Stage 6: Phases E and F: grouping change and sequencing it by dependency

A migration roadmap sequenced by dependency, not by the calendar

In a core-banking replacement the customer-data migration has to prove out before payments cut over, so a sequence that explains why each step precedes the next stays defensible whatever quarter the steps land in, where a bare calendar of dates does not.

A migration roadmap sequenced by dependency, not by the calendar A dependency chain of four core-banking migration steps, two rows of two, joined by blue arrows carrying the reason each step follows the last. Step 1, Customer data, migrate and reconcile; an arrow labelled prove first leads to Step 2, Account services, move onto the new core. A wrap arrow labelled then rests on it carries the flow to Step 3, Payments, the tinted proof gate, cut over once data is proven; an arrow labelled only after leads to Step 4, Decommission, retire the old core. A marker below names the sequence defensible in any quarter. Ordered by dependency, not by date Step 1Customer dataMigrate and reconcileBalances tie out to the penny Step 2Account servicesMove onto the new coreRuns on the migrated data Step 3PaymentsCut over once data is provenGated on reconciliation Step 4DecommissionRetire the old coreNothing depends on it now prove first only after then rests on it Defensible in any quarter Each step justified by the one before it, so the dates hold up even when a quarter slips

Hold these distinctions

  • Phase E's three objectives are the initial Architecture Roadmap, the decision on an incremental approach with Transition Architectures, and the Solution Building Blocks, while identifying work packages and Transition Architectures are steps, not objectives
  • A real transition architecture passes five tests, a clear reason to exist, known compromises, visible controls, a bounded exit path, and standalone value, with exit conditions stated as testable architectural statements rather than dates
  • A work package is a scope-bounded architecture change with dependencies and a transition-state assignment, not a sprint, project, release, or budget line
  • Phase F balances seven sequencing criteria with dependency the strongest, and the Architecture Roadmap and the Implementation and Migration Plan are different documents for different audiences
  • The ADM is iterative within phases, between phases, and over the whole process, and a governed loop needs an explicit decision, a defined scope, an impact assessment, and time bounds
  • The landscape's three levels are strategic, segment, and capability, and partitioning succeeds only while cross-partition interfaces stay visible and governed
  • Agile and architecture coexist through guardrails, with principles, boundary decisions, authority rules, and transition-state logic stable while detail design iterates inside them
  • Twelve readiness factors are each scored on readiness rating and urgency of improvement, and low readiness with high urgency is a sequencing constraint
  • An evidence gate is a decision point with authority to hold, revise, or proceed on architectural evidence, where a status report can only inform

Stage 7: Phases G and H and the standing capability that governs delivery

Compliance, waiver and contract as one flow ending in audit evidence

These are four stages of one flow, not three separate processes: a compliance check surfaces a gap, a waiver request justifies it, the Architecture Board sets contract terms, and the whole trail is filed, so each stage feeds the next and the record must hold from the first check.

Compliance, waiver and contract as one flow ending in audit evidence Four flat stage panels wrap over two rows, joined by labelled flow arrows, each panel naming its stage, the role that owns it and the artefact it hands on. Top row: Stage 1, Compliance check, owned by the architect, tests a requirement and outputs a named gap. An arrow labelled raises leads to Stage 2, Waiver request, owned by the requester, which outputs a decision request. An arrow labelled decides wraps down to the second row: Stage 3, Contract, owned by the board and tinted to mark the governed decision, setting the agreed terms. An arrow labelled files leads to Stage 4, Audit evidence, owned by the auditor, filing the whole trail as the audit record the auditor reads. Stage 1Compliance checkRequirement testedOwned byArchitectOutput: a named gap Stage 2Waiver requestGap justified, owner setOwned byRequesterOutput: decision request Stage 3ContractScope, expiry, conditionsOwned byBoardOutput: agreed terms Stage 4Audit evidenceWhole trail filedOwned byAuditorOutput: the audit record raises files decides

Hold these distinctions

  • Seven components make an EA capability, sponsorship, governance, method, content and repository, roles and skills, delivery interfaces, and measurement, and a title supplies only one of them
  • The Architecture Board protects cross-enterprise coherence, and decision rights sit at three levels, board decides, domain architect decides with the board informed, delivery team decides within guardrails
  • The six levels of conformance run from irrelevant through consistent, compliant, conformant, and fully conformant to non-conformant, so compliance never collapses into a binary verdict
  • A healthy waiver has six elements, and the expiry condition is the one most commonly missing
  • An Architecture Contract is a joint agreement on deliverables, quality, and fitness-for-purpose, established at the start of Phase G and reused by Phase H
  • G198 gives seven competency categories across four proficiency levels, and a G203 maturity score diagnoses only when it names the weak behaviour, its consequence, and the smallest fix
  • Even the lightest tailoring keeps five controls, a scope statement, active principles, a decision log, an exception register, and a lightweight review path
  • Phase G's Compliance Assessment gates deployment, and Phase H classifies every change as simplification, incremental, or re-architecting to decide where it re-enters the ADM
  • A value scorecard pairs leading measures, lead time and reuse, with lagging measures, risk reduction and cost avoidance, and ties every number to the investment case

Stage 8: Comparing, tailoring, and knowing where TOGAF is the wrong fit

Risk, speed and scale as three independent tailoring dials

Tailoring the ADM is not one dial but three: risk, speed and scale each set how much method to keep, and each is turned on its own, so a fast cadence never forces light governance and a large programme never forces a slow one.

Risk, speed and scale as three independent tailoring dials Three independent tailoring dials shown as three columns drawn alike in the accent, each with an upward axis labelled dial rises and three level panels read low at the bottom to high at the top, the highest tinted. The risk dial, under compliance pressure, runs from skip Phase G and log decisions, through a light Phase G with board oversight, to a full Phase G with gate reviews. The speed dial, for delivery cadence, runs from full sequential deliverables, through parallel trimmed phases, to decisions only on G210 sprints. The scale dial, for programme size, runs from one lead and one phase loop, through domain leads, to federated boards on one catalogue. Risk dialCompliance pressureDialrisesHigh riskFull Phase Ggate reviewsMedium riskLight Phase Gboard oversightLow riskSkip Phase Glog decisions only Speed dialDelivery cadenceDialrisesFast cadenceDecisions onlyG210 sprintsMedium cadenceParallel phasestrimmed workSlow cadenceFull deliverablessequential Scale dialProgramme sizeDialrisesLarge scaleFederated boardsone catalogueMedium scaleCentral plusdomain leadsSmall scaleOne leadone phase loop

Hold these distinctions

  • TOGAF is a method for running architecture work and ArchiMate is a language for expressing it, mapped officially through the W14C harmonization guide
  • ArchiMate 3.2 defines six layers, Strategy, Business, Application, Technology, Physical, and Implementation and Migration, with Motivation as a cross-cutting aspect
  • BIZBOK is business-architecture depth from the Business Architecture Guild, and TOGAF still carries the cross-domain method, governance, migration logic, and repository around it
  • DoDAF expects conformance and FEAF works through reference models, while TOGAF expects tailoring, and the differences follow from operating context rather than quality
  • The official Zachman source calls the framework a schema and ontology, not a methodology, so it compares with TOGAF as classification lens versus method
  • The core diagnostic for TOGAF value: if you removed the architecture work, which enterprise decisions would get worse?
  • Good tailoring keeps decision memory, traceability, and exception governance visible even in the lightest implementation
  • A defensible architecture pack is traceable, proportionate, and decision-bearing, and a stack of individually plausible artefacts is a filing cabinet
  • London is deliberately a high-governance Profile 3 case so the full method can be shown, a teaching reference rather than a universal template

Exam technique for the two papers

The Foundation paper tests precise recall, closed book. Revise the definitions, the purpose of each phase, and the document map above, and in the sitting eliminate the two options that overclaim or say nothing before choosing between the rest. The precise option beats the sweeping one.

The Practitioner paper tests judgement, open book, with four courses of action scored five, three, one, and zero. Rank the options rather than hunting one right answer. The strongest option usually addresses the stakeholder concern, keeps governance in the loop, and asks for evidence; the weakest jumps to a solution or skips governance entirely. Use the reference panel to check, not to read: knowing the map beats reading in the exam.

The official sources behind the course

Version-sensitive claims across the course anchor to The Open Group's published material, and every module cites the specific Series Guides it draws on where they are used. These are the three entry points worth bookmarking.

When the distinctions hold from memory and the figures feel obvious, you are ready to drill the papers and then sit the mocks.