Stage 1. Orientation and TOGAF 10 in Practice: phase summary

TOGAF defines enterprise architecture as a conceptual blueprint that defines the structure and operation of an organisation, with the intent of helping it achieve its current and future objectives. The operative word is effectiveness, not documentation. The test that runs through the phase is blunt: if you removed an artefact tomorrow, would any cross-enterprise decision move differently? If not, it is documentation theatre. Enterprise architecture is also not solution architecture (one system), not project management (delivering a fixed scope), not IT strategy (technology direction only), and not a one-off exercise, because Phase H exists to keep the architecture alive as pressures change.

Every TOGAF concept serves one of four questions: why change, what should exist, how do we move, and how do we sustain it. For London Grid these become concrete. Why change covers connections reform, Ofgem scrutiny of LTDS publication, tightening cyber expectations and a net zero target. What should exist means coherent business, data, application and technology targets rather than isolated project artefacts. How do we move means staged transitions that each leave the network safe and the lights on. How do we sustain it means an Architecture Board, a traceable repository, principles and compliance. If a piece of the standard feels detached, ask which question it answers.

The shift from 9.2 to 10 was structural, not cosmetic. The standard now has three layers: the six Fundamental Content volumes of the core (C220 Part 0 concepts, Part 1 the ADM, Part 2 techniques, Part 3 applying the ADM, Part 4 content, Part 5 capability and governance), the 26 official Series Guides that configure the core for specific contexts, and the supporting TOGAF Library. The reading strategy follows from this: stabilise the backbone first (Part 0, Part 1, key Part 2 techniques, plus G186 and G184 to make the method practical), then add a guide only when it changes a decision you are about to make. The BOK Guide (02.1) is the navigation map, not the standard.

Three layers of work products are easy to confuse and must be kept distinct: a deliverable is the formally reviewed and signed-off package, an artefact is a specific representation inside it (catalogues, matrices, diagrams), and a building block is a reusable element behind the design. ABBs state the required capability; SBBs name the product that implements it, and architecture decisions should stabilise before solution decisions. Views show the architecture while viewpoints shape that showing for a stakeholder concern. The enterprise continuum classifies assets from Foundation through Common Systems and Industry to Organisation-Specific, across parallel Architecture and Solutions tracks. The repository has six components, and traceability from principle to decision to work package to governance record is what makes it useful, not folder depth.

London Grid Distribution is fictional, but the public environment around it is deliberately real and traceable to named GB sources. The phase enforces source discipline: every claim is sorted into verified GB facts, TOGAF concepts, London Grid enterprise design, or synthetic teaching scenarios, so a learner can always tell what is real from what is invented. Four transformation threads recur (connections modernisation, network visibility and data publication, flexibility and distributed energy, and governance and accountability), each mapping to a TOGAF domain. The opening repository holds four artefacts: the repository atlas, source ledger, terminology translation sheet, and opening problem frame.

• Treating TOGAF as the ADM wheel plus templates, when the ADM is only Part 1 of six and ignores the techniques, content, governance and guide layers.
• Reading TOGAF cover to cover in publication order, which builds vocabulary but not the ability to apply it; start from the problem instead.
• Using one master diagram for every audience, which satisfies nobody, instead of shaping views to each stakeholder's concern.
• Building a repository as a folder hierarchy with no traceability, so nobody can trace a decision back to its principle and rationale.