End-to-end London Grid Distribution capstone

The capstone is not simply a recap. It is a coherence test. If the earlier stages were useful, they should now lock together into a single architecture pack that can be explained from first concern to governed delivery decision.

That means every major artefact has to earn its place. Principles must influence choices. Business architecture must explain why the information architecture looks the way it does. Technology decisions must be traceable to business and information needs. Roadmaps must follow from real gaps and transition logic. Governance must control exceptions and evidence quality.

The three qualities of a defensible pack

• Traceable. Every major decision can be traced back through the architecture layers to the enterprise concern that motivated it. And every enterprise concern can be traced forward through the architecture layers to the delivery decisions that address it.
• Proportionate. Every artefact in the pack earns its place by improving a decision, handoff, or review. There are no decorative artefacts maintained for completeness rather than value.
• Decision-bearing. The pack visibly influences enterprise decisions: technology selection, roadmap sequencing, exception handling, compliance evidence, and investment prioritisation. Architecture that exists but does not influence decisions is ceremonial.

Each of these seven moves corresponds to a stage of the course. The capstone tests whether they connect into one narrative. If any move cannot explain how it relates to the ones before and after it, the pack has a traceability gap.

1. Define the enterprise boundary and architecture vision. London's vision centres on connections reform, operational evidence, publication discipline, and regulatory accountability. This sets the scope for everything that follows. Without it, later decisions have no anchor.
2. Set principles and stakeholder concerns. London's principles include data-as-evidence, single authoritative source, resilience by design, and proportionate security. These principles are not aspirational statements. They are constraints that later architecture decisions must satisfy. Stakeholder concerns from Ofgem, NESO, customers, and internal teams define what the architecture must address.
3. Expose the business architecture. Capabilities, value streams, organisation mapping, and the real business gaps behind slow and fragmented service outcomes. The business architecture explains what the enterprise does and where it fails. Without it, information and technology decisions are built on assumptions rather than evidence.
4. Clarify information authority, metadata, applications, and integration. London's information architecture defines which source owns which data domain, how metadata supports discovery and trust, and how applications create, read, update, and publish data. The application architecture maps the portfolio to business capabilities and identifies integration patterns.
5. Choose technology and resilience patterns. London's technology architecture addresses OT/IT convergence, telecoms, cyber security, platform choices, and operational continuity. These decisions must be traceable to business capability gaps and information authority requirements. A technology decision that floats without business or information rationale is a traceability gap.
6. Sequence work packages and transition states. London's roadmap shows not just the target but the path and evidence needed to reach it. Phase E identifies work packages from gap analysis. Phase F sequences them into transition states with dependencies, assumptions, and evidence requirements.
7. Run governance, compliance, and exceptions. London's governance layer operates through the Architecture Board, architecture contracts, compliance reviews, and a visible repository so change remains controlled after the design phase. Implementation governance ensures delivery stays aligned to architecture decisions. Architecture change management monitors for triggers that require a new cycle.

A defensible pack is not defined by the number of artefacts it contains. It is defined by whether every artefact that exists changes a decision. The following elements should be present in a pack that can withstand critical review.

• A statement of the enterprise problem and the decision horizon. What is the enterprise trying to achieve, and over what timeframe? This anchors the entire pack.
• A principle set that is short enough to guide action and concrete enough to constrain it. Principles that are too vague to test against real decisions are decorative. Principles that are too numerous to remember are ignored.
• Business architecture artefacts that explain capability, value flow, ownership, and pain points. These artefacts should make it clear why the enterprise is changing and where the most important gaps exist.
• Information, application, and technology artefacts that reflect real authority boundaries and dependency logic. These artefacts should be traceable to business capability gaps. A technology decision without a business rationale is a red flag.
• A roadmap with work packages, transition states, and explicit change assumptions. The roadmap should explain sequencing logic, dependencies, and evidence requirements. A roadmap that says "do A, then B, then C" without explaining why that order is a list, not a plan.
• A governance layer that records decisions, exceptions, and evidence. This layer should make it possible to audit why a decision was made, who approved it, and what evidence supported it. Governance that relies on institutional memory disappears when people move on.

The comparison stage (Modules 58-61) matters here because it stops the capstone from becoming framework nationalism. A mature architecture practice recognises that TOGAF is not the only source of useful discipline.

• If London needed formal modelling precision, ArchiMate would help (Module 58).
• If the enterprise wanted a deeper business-architecture lens, BIZBOK-style practice could sharpen Stage 3 (Module 59).
• If viewpoint discipline or reference-model thinking became more important, DoDAF or FEAF ideas could be borrowed carefully (Module 60).
• If descriptive coverage was weak, Zachman could act as a review lens (Module 61).

The tailoring stage (Modules 62-63) matters because London is intentionally a high-governance case. The capstone therefore shows a fuller TOGAF use than every enterprise needs. That is a feature of the teaching design, not a hidden claim that all enterprises should work at London scale. Module 62 identified where TOGAF is inappropriate. Module 63 provided tailoring profiles. The capstone sits at the heavier end of the spectrum because London's regulatory, cross-domain, and multi-year context justifies it.

A critical review of any architecture pack, not just London's, should follow a structured approach. These five steps provide a practical review method.

1. Pick one concern and trace it end-to-end. Start with a real enterprise concern (for example, "connections delivery is too slow") and test whether you can trace it across principles, business design, information design, technology choices, roadmap, and governance. If the trace breaks at any point, the pack has a gap.
2. Challenge each artefact's decision purpose. Ask whether each artefact changes a decision or merely repeats what another artefact already says. Redundant artefacts dilute attention and create maintenance cost without value.
3. Test target-state claims against evidence. Check whether any target-state claim lacks a visible gap, transition assumption, or evidence requirement. A target state that is asserted without evidence is an aspiration, not an architecture.
4. Test exception governance. Check whether exceptions and compensating controls are governed visibly or hidden in delivery practice. If a material exception was accepted but nobody can find the record, the governance is not functioning.
5. Assess proportionality. Decide whether the pack is proportionate to the enterprise problem or whether it still contains decorative residue. A proportionate pack serves the enterprise. A disproportionate pack serves the architecture team's idea of what architecture should look like.

A mature assessment of the London capstone requires honesty about what TOGAF contributed and what still depended on professional judgement outside the standard.

Where TOGAF helped

• Structure and sequence. The ADM provided a structured sequence for developing the architecture from vision through business, information, technology, migration, and governance. Without that structure, the work would have been ad hoc.
• Content metamodel. The metamodel structured the repository and defined how entities relate to one another. This made the architecture traceable.
• Governance framework. The governance guidance defined decision rights, compliance reviews, exception handling, and Architecture Board behaviour. This made the architecture governable.
• Series Guides. The Series Guides (G211, G178, G186, G190, G210, and others) deepened specific areas beyond what the core standard addresses.
• Common vocabulary. TOGAF provided a shared vocabulary that the course used to teach enterprise architecture consistently across 64 modules.

Where judgement still did the work

• Domain knowledge. TOGAF does not teach energy distribution, OT/IT convergence, regulatory obligations, or network asset management. That domain knowledge came from outside the standard.
• Stakeholder engagement quality. TOGAF provides guidance on stakeholder identification but does not teach the interpersonal skills needed to run effective workshops, manage conflicting concerns, or build trust with sceptical stakeholders.
• Design trade-offs. Every architecture involves trade-offs: cost versus resilience, speed versus traceability, standardisation versus flexibility. TOGAF structures the decision but does not make it. Professional judgement makes it.
• Proportionate tailoring. TOGAF expects tailoring but does not make the tailoring decision for you. The practitioner must judge what is proportionate for the specific enterprise context.
• Critical self-assessment. TOGAF does not tell you when your own architecture is weak. That requires honest self-assessment, peer review, and the willingness to acknowledge gaps.

London Grid Distribution is the course's working proof that TOGAF can be taught as a practical enterprise discipline rather than as a document inventory. The fictional enterprise gives the course enough realism to test scope, principles, business architecture, information authority, resilience, migration, and governance as connected concerns.

The final teaching outcome is not that London has the perfect architecture. It is that learners can now explain what a defendable TOGAF-led architecture pack looks like, where the standard helped, where supporting guides deepened the work, and where professional judgement still had to do the real thinking.

The capstone summary for London

• The capstone turns the London repository from a set of examples into one architecture narrative with traceable connections between stages.
• If the course has worked, the learner should now be able to critique the pack as well as describe it.
• The strongest test of understanding is not whether you can repeat what each stage said, but whether you can explain why each stage connected to the ones around it.

Over sixty-four modules and eight stages, the course has taken you from the basic question of what enterprise architecture is, through the full ADM cycle, across business, information, technology, migration, and governance architecture, and into honest framework comparison and tailoring.

What you should be able to do now

• Explain what TOGAF is for, how the standard is structured, and how the ADM, content framework, and governance model work together.
• Walk a real enterprise problem from preliminary framing through business, information, technology, migration, and governance architecture using the London case as a reference.
• Compare TOGAF accurately with ArchiMate, BIZBOK, DoDAF, FEAF, and Zachman without reducing the comparison to slogans.
• Tailor the method proportionately and recognise when TOGAF is not the right tool.
• Build and critique a defensible architecture pack with traceable decisions and governed exceptions.
• Distinguish between what the standard provides and where professional judgement, domain knowledge, and stakeholder engagement do the real work.

What to do next

• Workspace tools. Use the interactive tools in this course (capability heatmap builder, gap analysis matrix, stakeholder mapping, governance simulator, maturity assessor, and others) to practise with your own enterprise problems.
• Course assessment. Take the timed or practice assessment to test your understanding across all eight stages.
• CPD tracking. Record your completion for professional development. This course covers approximately 64 hours of structured enterprise architecture learning aligned to the TOGAF Standard, 10th Edition.
• Keep reading. The TOGAF Standard, the Series Guides, and the TOGAF Library are living resources. The course has given you a reading method. Use it to stay current as guidance evolves.

Architecture is not a destination. It is a discipline that stays useful only when it keeps earning its place in real enterprise decisions.