Stage 1 summary. Orientation and TOGAF 10 in Practice

The TOGAF Standard defines architecture, in the sense that matters day to day, as the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. The operative words are design and evolution. Architecture governs how an enterprise changes across business, data, application, and technology, so that a decision taken in one domain does not quietly break another. A loyalty pricing redesign touches systems, partners, and obligations at once, and architecture is what keeps those views consistent.

The stage is equally clear about what enterprise architecture is not. It is not solution architecture, which designs one system deeply. It is not project management, which delivers a fixed scope to time and cost. It is not IT strategy, which sets technology direction without the cross-domain model to ground it. And it is not a one-off exercise, because Phase H of the method exists precisely to keep the architecture alive as pressures change.

That leaves the working test you will use for the rest of the course. Start from the decision and the cost of getting it wrong. If an artefact will not change a decision that crosses domains, it is not enterprise architecture, however polished the diagram.

Every TOGAF concept serves one of four questions. Why change? What should exist? How do we move? How do we sustain it? If a piece of the standard ever feels detached, ask which question it answers and it will fall into place. The questions are also the fastest way to brief anyone outside the architecture team on what the work is for.

The Architecture Development Method is the cycle that works through those questions. The Preliminary Phase prepares the framework and principles before any cycle opens. Phase A sets the Architecture Vision. Phases B, C, and D develop the business, information systems, and technology architectures. Phases E and F turn the target into opportunities, work packages, and a migration plan. Phases G and H govern implementation and manage change. At the centre sits Requirements Management, feeding and disciplining every phase, so the cycle stays driven by what the enterprise actually needs rather than by the phases themselves.

TOGAF 10 has three layers. The core is the six Fundamental Content volumes of the C220 document set: Part 0 introduces the standard and its concepts, Part 1 holds the Architecture Development Method, Part 2 the ADM techniques, Part 3 guidance on applying the ADM, Part 4 the Architecture Content framework, and Part 5 EA capability and governance. Around that core sit the Series Guides, which configure the method for specific contexts, and beyond them the TOGAF Library of supporting material.

The move from version 9.2 to 10 was structural rather than cosmetic. The stable backbone now sits apart from the guidance that surrounds it, so the core can stay steady as a reference while the guides evolve on their own cycles. Reading the whole thing straight through as one block is exactly the habit the structure is meant to break.

The reading strategy follows. Stabilise the backbone first: Part 0, Part 1, and the key Part 2 techniques. Then pull a single Series Guide only when a stage of work demands real depth on that topic. The BOK Guide is the navigation map for the body of knowledge, not the standard itself.

TOGAF keeps three things apart: the normative core, the supporting Series Guides, and the certification paths that test only selected portions of that body. TOGAF Enterprise Architecture has two levels. Foundation, examined as Part 1, tests recall and understanding of the core Standard. Practitioner, examined as Part 2, tests applying the Standard in context, supported by the Series Guides. TOGAF Business Architecture Foundation is a separate track with its own credential, not a third level above Practitioner.

The trap is mistaking the syllabus for the full set of skills an architect needs. Certification is most valuable when it enforces a shared vocabulary and a common structure across a team. The repository discipline, stakeholder handling, and tailoring judgement that real work demands sit largely outside what the exams reach, which is why this course teaches past the syllabus and why practice here is broader than exam coverage.

Two ideas keep architecture assets findable and reusable. The Enterprise Continuum classifies assets along a line from generic to specific: Foundation, Common Systems, Industry, and Organisation-Specific, with parallel Architecture and Solutions tracks. The Architecture Repository is the navigable system that holds the principles, models, requirements, building blocks, standards, and governance records those classifications organise.

Naming the parts does not create the capability. A shared drive full of architecture files is still a heap, whatever the folders are called. The standard a working repository should meet is practical: a board member or delivery lead can answer in minutes what was decided, which principle or requirement it relates to, which baseline and target it affects, and what delivery work or exception follows from it. Traceability from principle to decision to work package to governance record is what makes a repository real, not folder depth.

The continuum also explains why reuse compounds. Generic assets prove themselves in one context, then migrate leftwards into shared foundations that later work draws on, which is how an architecture function stops solving the same problem twice.

Three layers of work products are easy to confuse and must be kept apart. A deliverable is the formally reviewed, contractual package that gets signed off. An artefact is a specific representation inside it, a catalogue, a matrix, or a diagram. A building block is a reusable element behind the design. A flat-pack kit makes the last distinction concrete: the generic specification is the architecture building block, and the particular product chosen against it is the solution building block. Architecture building blocks stabilise before solution choices, never the other way round.

Views and viewpoints complete the vocabulary. A view shows the architecture; a viewpoint shapes that showing for a stakeholder concern, the way a camera position frames a scene. One master diagram pushed at every audience satisfies nobody, which is why the standard insists views are constructed per concern.

When these words blur, one diagram gets called all three at once, governance acts on the wrong object, and reuse becomes unmanageable. The vocabulary is a hygiene test: a capability map is an artefact, the review pack that contains it may be the deliverable, and the reusable elements it describes inform building blocks.

The publications are a method and a reference library at the same time, and the way in is the live problem. A confusing stakeholder landscape points to the Preliminary Phase and Phase A together with the Business Scenarios technique. A roadmap question points to Phases E and F and the migration guidance. A governance dispute points to Part 5 and the compliance material. Enter by the problem and each publication earns its place by answering the question in hand.

Read straight through like a novel and anxiety takes over; people keep collecting publications instead of applying the few that fit. The habit this stage builds is deliberate: stabilise the backbone once, then treat everything else as a reference to be pulled on demand. Reading stays purposeful instead of becoming an end in itself.

London Grid Distribution is fictional, but the public environment around it is deliberately real. The case serves 2.3 million customers across Greater London and faces pressures every GB network operator recognises: connections reform, scrutiny of network data publication, tightening cyber expectations, and a net zero target. Because the environment is real, every claim in the case is sorted into one of four categories: verified GB facts traceable to named sources, TOGAF concepts, London Grid enterprise design, and synthetic teaching scenarios.

That sorting is the source discipline, and it is a working skill, not case furniture. Architecture work constantly mixes verified fact, framework concept, design intent, and illustration, and practitioners who cannot tell them apart end up defending invented numbers in front of regulators. The evidence chain the stage teaches runs every claim through five checkpoints back to its source.

The case opens with a small repository of four artefacts: the repository atlas, the source ledger, the terminology translation sheet, and the opening problem frame. Four transformation threads recur from here to the capstone, connections modernisation, network visibility and data publication, flexibility and distributed energy, and governance and accountability, each mapping to one of the four architecture domains.

Requirements Management is not a phase you visit once; it is the hub the whole cycle turns on. Every phase raises requirements, consumes requirements, and returns changed requirements to the centre, and the discipline is keeping that flow explicit rather than letting each phase hold private lists that drift apart.

The practical consequences run through the whole course. A requirement raised in Phase B about capability gaps must still be traceable when Phase F sequences work packages and when Phase G checks delivery against the contract. When stakeholders change their minds, the change enters through Requirements Management and its impact is assessed against every phase it touches, which is what stops architecture decisions resting on requirements nobody still owns.

The stage closes by making the four questions concrete for London Grid. Why change: connections reform, Ofgem scrutiny of network data publication, tightening cyber expectations, and a net zero target, all arriving at once. What should exist: coherent business, data, application, and technology targets rather than isolated project artefacts. How do we move: staged transitions that each leave the network safe and the lights on. How do we sustain it: an Architecture Board, a traceable repository, principles, and compliance checks that outlast any single programme.

Hold that mapping. Every stage that follows deepens one slice of it, and the scenario practice at the end of each stage keeps returning to these four questions under different pressure.