Reference pack

Enterprise Architecture Reference

This page keeps the source ledger, comparison axes, figure and tool registers, and the module coverage view in one place. It is written for auditability and later licensing review as much as for learner convenience.

Source Ledger

TOGAF core and guide spine

TOGAF overview
Official landing page for the TOGAF Standard, 10th Edition.
TOGAF Library
Official Open Group page for library and supporting guidance.
The TOGAF Standard, 10th Edition
Official publication landing page for the core standard.
G184, Leader's Guide to Establishing and Evolving an EA Capability
Leadership and operating-model guidance for enterprise architecture capability.
G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM
Practical guide to working through the ADM.
G152, Integrating Risk and Security within a TOGAF Enterprise Architecture
Risk and security guidance for enterprise architecture.
G176, Business Scenarios
Guide to using business scenarios as an architecture technique.
G178, Value Streams
Guide to value streams and value stages.
G18A, Business Models
Guide to business-model thinking in architecture work.
G190, Information Mapping
Guide to information mapping in enterprise architecture.
G206, Organization Mapping
Guide to mapping organisation structure and responsibilities.
G211, Business Capabilities, Version 2
Guide to business capabilities and their use.
G233, Business Capability Planning
Planning guidance built on capability thinking.
G21B, Information Architecture Customer Master Data Management
Guide to customer master data management in information architecture.
G234, Metadata Management
Metadata management guidance for enterprise information architecture.
G238, Business Intelligence and Analytics
Guide to BI and analytics in enterprise architecture.
G248, Selecting Building Blocks
Guide to architecture and solution building-block selection.
G188, Architecture Project Management
Guide to the relationship between architecture and project delivery.
G198, Architecture Skills Framework
Skills guidance for architecture practitioners.
G203, Architecture Maturity Models
Guide to assessing architecture maturity.
G249, Architecture Roles and Skills
Roles and skills guidance for EA capability building.
G20F, Enabling Enterprise Agility
Guide to agility and enterprise architecture.
G210, Applying the TOGAF ADM using Agile Sprints
Guide to running ADM work with agile sprint structures.
G212, Digital Technology Adoption Readiness Assessment and Roadmap Development
Readiness and roadmap guidance for digital change.
G217, Using the TOGAF Standard in the Digital Enterprise
Guide to using TOGAF in digital-enterprise contexts.
G21D, Government Reference Model
Reference-model thinking for government and regulated settings.
G21H, Digital Business Reference Model
Digital-business reference model guidance from The Open Group.
G21I, Microservices Architecture
Guide to microservices architecture.
G242, Environmentally Sustainable Information Systems
Guide to environmentally sustainable information systems.

Comparison frameworks and companion sources

ArchiMate overview
Official Open Group overview of ArchiMate.
Business Architecture Guild
Official Business Architecture Guild home page.
BIZBOK Guide table of contents
Official Guild-hosted BIZBOK table of contents PDF.
DoD Architecture Framework
Official DoDAF landing page from the DoD CIO.
Federal Enterprise Architecture resources
Official archived federal enterprise architecture landing page.
Common Approach to Federal Enterprise Architecture
Official archived PDF for the Common Approach.
Federal Enterprise Architecture Framework Version 2
Official archived FEA v2 PDF.
Zachman official site
Official Zachman site. Access from this environment is inconsistent, so treat it as source-gated where necessary.

London case grounding sources

Clean Power 2030 Action Plan
DESNZ plan shaping the fictional utility case context.
NESO Connections Reform
NESO page for connections reform activity.
Long Term Development Statement direction
Ofgem LTDS direction relevant to information-publication examples.
ED3 framework decision
Ofgem decision used to ground planning and governance examples.
Regional Energy Strategic Planning (RESP)
NESO strategic-planning source relevant to the London case.
Energy digitalisation framework
DESNZ and Ofgem digitalisation framework used in the London information-architecture case.
Governance of the Data Sharing Infrastructure
Ofgem governance decision for DSI.
Data Best Practice guidance
Ofgem data publication and stewardship guidance.
Cyber Assessment Framework
NCSC collection for cyber resilience and assurance in critical sectors.

Framework Comparison Axes

Primary purpose
Method versus ontology or modelling role
Strength in business architecture
Strength in information and technology architecture
Governance and decision-rights support
Fit for regulated and public-sector contexts
Where it complements TOGAF
Where TOGAF should yield to it

Comparison source posture

ArchiMate comparison claims are grounded in current official Open Group pages, including the Open Group explanation of how the ArchiMate language complements the TOGAF Standard.
BIZBOK comparison claims are intentionally high-level because official Guild resources were partly challenge-gated from this environment. The course stays within what the official Guild pages and official guide references support visibly.
DoDAF comparison claims are grounded in the official DoD CIO framework page and its published viewpoint structure and conformance posture.
FEAF comparison claims are grounded in official archived federal materials, especially the Common Approach and FEAF v2 reference-model material. The course treats these as authoritative public-sector references, not as a fast-moving current product.
Zachman comparison claims are grounded in the official Zachman owner page, which explicitly characterises the framework as a schema and ontology and explicitly says it is not a methodology.

Quality Gates

Every version-sensitive claim must point to an official current or clearly archived source.
Short quotations only. The course should rely mainly on precise paraphrase and citation.
No protected TOGAF question-bank content may be copied or closely paraphrased.
Every figure placeholder must identify the official source or explicitly state that it is a course-native teaching aid.
Every module must include a required check, a diagram placeholder, and a future tool placeholder.
Framework comparison claims must remain within what the official framework-owner sources can support.

Figure Register

Figure 3-1 ADM cycle, planned as an exact TOGAF figure placeholder with London annotations around, not inside, the official structure.
Figure 3-5 architecture repository structure, planned as an exact TOGAF figure placeholder tied to the London repository atlas.
Figure 1-1 deliverables, artefacts, and building blocks, planned as an exact TOGAF figure placeholder with London examples.
Figure 1-3 content framework by ADM phase, planned as an exact TOGAF figure placeholder connected to the course stage outputs.
Additional TOGAF figures will remain placeholder-only until the figure-use and permission path is complete.

Tool Register

Repository atlas explorer
Value-stream bottleneck analyser
ABB and SBB selector
ADM iteration planner
TOGAF tailoring advisor
Capstone repository reviewer

Publication controls

Published references must point to official external URLs, never to downloaded local copies in the repo or the user's filesystem.
Exact TOGAF diagram work remains placeholder-only until the figure-permission path is settled.
The course should favour precise paraphrase over extended quotation, with short quotation used only where legally and educationally necessary.
Assessment material must be written from the authored course body and public objectives only, never from the protected TOGAF question material held locally.

Coverage Matrix

Stage	Module	Official anchors	London focus	Key caution
Stage 0. Foundations	EA0A What electricity is and how it reaches you
Stage 0. Foundations	EA0B What London Grid Distribution does
Stage 0. Foundations	EA0C Why architecture matters
Stage 1. Orientation and TOGAF 10 in Practice	EA1 What enterprise architecture is and is not	The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM, G217, Using the TOGAF Standard in the Digital Enterprise	London Grid Distribution uses enterprise architecture because connections reform, LTDS publication, cyber resilience, and delivery governance all cut across business, information, application, and technology decisions.	The phrase enterprise architecture is often used to label strategy slides, solution design, or governance ritual. This course keeps those related but distinct.
Stage 1. Orientation and TOGAF 10 in Practice	EA2 TOGAF 10 structure and what changed	TOGAF overview, The TOGAF Standard, 10th Edition, TOGAF Library, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	The London course implementation uses this structure directly. Phase work comes from the core. Business scenarios, capabilities, information mapping, agility, and governance depth come from the guides.	People sometimes describe TOGAF 10 as merely a repackaging. That misses the practical value of separating stable method from evolving guidance.
Stage 1. Orientation and TOGAF 10 in Practice	EA3 Core, Series Guides, Library, and certification map	TOGAF overview, TOGAF Library, The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM, G184, Leader's Guide to Establishing and Evolving an EA Capability, G217, Using the TOGAF Standard in the Digital Enterprise	The London case uses the official publication set as working material, not as a memorisation target. Each stage shows where an exam-relevant topic becomes a real enterprise decision.	A course that teaches only to the exam will under-serve anyone who actually has to run an architecture board or shape a migration roadmap.
Stage 1. Orientation and TOGAF 10 in Practice	EA4 Enterprise continuum, repository, and enterprise services	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM, TOGAF Library	The London repository is deliberately atlas-like: principles, stakeholder concerns, requirements, decisions, baseline, target, and governance all point to one another so the learner can follow the architecture logic.	Teams often repeat the repository vocabulary without ever designing a usable repository structure. That is why architecture knowledge becomes unfindable.
Stage 1. Orientation and TOGAF 10 in Practice	EA5 Deliverables, artefacts, building blocks, and viewpoints	The TOGAF Standard, 10th Edition, G248, Selecting Building Blocks	In the London case, the roadmap pack is a deliverable, the integration-authority map is an artefact, and the reusable identity, telemetry, or publication patterns are building blocks.	If a team cannot distinguish these terms, review conversations become muddy and reuse becomes harder to manage.
Stage 1. Orientation and TOGAF 10 in Practice	EA6 Reading TOGAF without getting lost	TOGAF overview, TOGAF Library, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	The London course data model follows the same principle. Each stage lists the core anchors first, then the guides that deepen the exact problem being taught.	Anxiety-driven reading is common with TOGAF. People often keep collecting publications instead of applying the ones that matter to their immediate architecture problem.
Stage 1. Orientation and TOGAF 10 in Practice	EA7 London Grid Distribution orientation and source discipline	TOGAF overview, G217, Using the TOGAF Standard in the Digital Enterprise, Clean Power 2030 Action Plan, Long Term Development Statement direction, ED3 framework decision	The case is fictional, but the pressures are grounded in official GB energy-sector sources: connections reform, LTDS publication direction, ED3 planning, digitalisation coordination, and cyber resilience expectations.	If the case study is not disciplined, the learner cannot tell where TOGAF ends and the author's invention begins. That is why the source-governance rule is explicit.
Stage 2. Preliminary Phase and Architecture Vision	EA8 Preliminary Phase and the enterprise boundary	The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability, G176, Business Scenarios	For London Grid Distribution, the architecture enterprise includes the distributor's internal business and technology functions, but it also touches Ofgem obligations, NESO planning interfaces, data-publication duties, and external delivery partners.	A sloppy enterprise boundary causes later confusion about which baseline matters, which requirements count, and who has authority to approve change.
Stage 2. Preliminary Phase and Architecture Vision	EA9 Stakeholders, concerns, and viewpoints	The TOGAF Standard, 10th Edition, G176, Business Scenarios	In the London case, executive, planning, operations, regulatory, cyber, data-governance, and delivery audiences do not need the same architecture view, even when they are discussing the same initiative.	When teams use one master diagram for everyone, they usually satisfy nobody.
Stage 2. Preliminary Phase and Architecture Vision	EA10 Architecture principles that change decisions	The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability	London principles might include publish-once-use-many for network information, design for regulated traceability, or resilience before convenience for operationally critical control paths. Each has direct implications for systems and governance.	Principles that say things like customer first or innovation matters sound good but usually fail the implication test.
Stage 2. Preliminary Phase and Architecture Vision	EA11 Business scenarios and problem framing	G176, Business Scenarios, The TOGAF Standard, 10th Edition	A London connections-modernisation scenario describes applicants, planners, network designers, approval checkpoints, data handoffs, response-time pressures, and the consequences of slow or inconsistent information flow.	Scenario work fails when it becomes a fiction-writing exercise instead of a disciplined way to surface architecture-relevant reality.
Stage 2. Preliminary Phase and Architecture Vision	EA12 Scope: breadth, depth, time, and domains	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	In the London case, the first architecture cycle does not solve every possible utility challenge. It narrows onto connections modernisation, data-publication discipline, and resilience dependencies that affect the current transformation agenda.	Architecture teams often claim they will start broad and narrow later. In practice that usually means they produce broad diagrams and never narrow enough to guide change.
Stage 2. Preliminary Phase and Architecture Vision	EA13 Sponsorship, governance, and capability kickoff	G184, Leader's Guide to Establishing and Evolving an EA Capability, G249, Architecture Roles and Skills, The TOGAF Standard, 10th Edition	The London kickoff needs executive support because the case crosses planning, operations, data governance, security, delivery, and regulatory interfaces. Without that support, the repository would fragment by department.	Sponsorship often gets mistaken for passive endorsement. Real sponsorship includes decision backing, access, and conflict resolution authority.
Stage 2. Preliminary Phase and Architecture Vision	EA14 Architecture Vision and the Statement of Architecture Work	The TOGAF Standard, 10th Edition, G176, Business Scenarios, G184, Leader's Guide to Establishing and Evolving an EA Capability	For London Grid Distribution, the vision clarifies the enterprise shift toward better connections responsiveness, stronger information publication, and more controlled resilience architecture. The work statement defines what this first cycle will and will not produce.	Teams sometimes write a polished vision that cannot be traced to a deliverable, a constraint, or a review path. That weakens the whole ADM cycle.
Stage 2. Preliminary Phase and Architecture Vision	EA15 London kickoff: principles, stakeholders, and vision	The TOGAF Standard, 10th Edition, G176, Business Scenarios, G184, Leader's Guide to Establishing and Evolving an EA Capability, Clean Power 2030 Action Plan, ED3 framework decision	The London kickoff creates the opening repository assets for the fictional distributor. It clarifies why connections reform, LTDS publication, resilience, and governance are architecture problems rather than isolated project issues.	When learners treat the early-phase artefacts as separate homework items, they miss the way TOGAF expects them to reinforce one another.
Stage 3. Business Architecture	EA16 Phase B and the point of business architecture	The TOGAF Standard, 10th Edition, G18A, Business Models, G206, Organization Mapping, G211, Business Capabilities, Version 2, G178, Value Streams	For London Grid Distribution, this means explaining how connections, planning, delivery, operations, and governance work now, what outcomes are required, and where the current enterprise arrangement cannot support those outcomes.	Business architecture becomes weak when it collapses into process mapping without strategic purpose or when it becomes so abstract that it cannot inform delivery priorities.
Stage 3. Business Architecture	EA17 Business models in TOGAF practice	G18A, Business Models, The TOGAF Standard, 10th Edition	The London utility case uses business-model thinking to distinguish network obligations, service outcomes, regulated accountability, and the growing role of digital information as an enabler of service performance.	Teams sometimes leap from business model directly to system design. The missing middle is business architecture: capabilities, services, organisation, and value streams.
Stage 3. Business Architecture	EA18 Organisation mapping	G206, Organization Mapping, The TOGAF Standard, 10th Edition	In London Grid Distribution, organisation mapping exposes how planning, operations, IT, data governance, cyber, and programme delivery relate to one another, and where those relationships weaken the transformation effort.	An organisation map becomes misleading when it is treated as the business architecture instead of one important input into it.
Stage 3. Business Architecture	EA19 Business capabilities	G211, Business Capabilities, Version 2, The TOGAF Standard, 10th Edition	The London case uses capability language to discuss network planning, connection design, data publication, operational resilience, and decision governance without getting trapped inside current application boundaries.	The most common error is confusing system ownership with capability ownership. That mistake leads architecture effort back into application inventory instead of enterprise ability.
Stage 3. Business Architecture	EA20 Capability-based planning	G233, Business Capability Planning, G211, Business Capabilities, Version 2, The TOGAF Standard, 10th Edition	The London case uses capability-based planning to prioritise the capabilities that most affect connection speed, planning visibility, LTDS publication quality, and resilience governance.	Heatmaps can become theatre when the colour choices are not anchored to evidence or when they lead to no actual planning consequence.
Stage 3. Business Architecture	EA21 Value streams	G178, Value Streams, The TOGAF Standard, 10th Edition	The London value-stream work focuses on the flow from initial connection request through planning, design, approval, build coordination, and energisation, with special attention to data handoffs and governance friction.	Value streams are not the same thing as detailed process maps. Confusing them leads to either oversimplification or unusable detail.
Stage 3. Business Architecture	EA22 Business footprints, goals, services, and measures	The TOGAF Standard, 10th Edition, G18A, Business Models, G211, Business Capabilities, Version 2	In the London case, footprint thinking helps show how customer-facing service outcomes, internal planning responsibilities, external reporting duties, and resilience commitments sit on the same architectural page.	Teams often attach measures too late. That makes it harder to judge whether a target business architecture is actually better than the baseline.
Stage 3. Business Architecture	EA23 Gap analysis in the business layer	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	London business gap analysis highlights where current planning, data handoff, and accountability structures cannot support the required service and governance outcomes.	A weak gap analysis merely lists what is different. A strong one shows why the difference matters and what action it suggests.
Stage 3. Business Architecture	EA24 London connections modernisation walkthrough	G18A, Business Models, G206, Organization Mapping, G211, Business Capabilities, Version 2, G233, Business Capability Planning, G178, Value Streams, NESO Connections Reform	The case focuses on connections responsiveness, planning visibility, governance friction, and the need to support change with better data and system architecture later in the ADM.	It is easy to let the business walkthrough slide into an application discussion too early. This module resists that and keeps the business layer in charge of the narrative.
Stage 3. Business Architecture	EA25 When business architecture becomes theatre	The TOGAF Standard, 10th Edition, G211, Business Capabilities, Version 2, G233, Business Capability Planning, G178, Value Streams	The London case avoids this by tying each artefact to a real transformation question, a downstream dependency, or a governance need.	Common signs include capability maps with no planning consequence, value streams with no bottleneck evidence, and endless workshops that do not tighten the architecture scope.
Stage 4. Information Systems Architecture	EA26 Phase C orientation: data and applications together	The TOGAF Standard, 10th Edition, G190, Information Mapping, G21B, Information Architecture Customer Master Data Management, G234, Metadata Management, G238, Business Intelligence and Analytics, G248, Selecting Building Blocks	In the London case, LTDS publication, customer and asset data authority, analytics, and application boundaries all depend on one another.	Splitting data and application work too early can produce local optimisations that do not fit together at enterprise scale.
Stage 4. Information Systems Architecture	EA27 Information mapping and information domains	G190, Information Mapping, The TOGAF Standard, 10th Edition	The London information map distinguishes customer, connection, network, asset, planning, telemetry, and publication information domains, then asks which consumers and responsibilities sit around each one.	If the information map mirrors current databases too closely, it stops being an enterprise view and becomes a technical inventory.
Stage 4. Information Systems Architecture	EA28 Source of truth and information authority	G190, Information Mapping, G21B, Information Architecture Customer Master Data Management, G234, Metadata Management	In London Grid Distribution, customer, planning, asset, and network data each have different authority and stewardship characteristics. The architecture must make those explicit before it can claim trustworthy publication or analytics.	The phrase source of truth becomes dangerous when it hides the fact that multiple systems may be authoritative for different aspects of the same business entity.
Stage 4. Information Systems Architecture	EA29 Customer master data management	G21B, Information Architecture Customer Master Data Management, G190, Information Mapping, The TOGAF Standard, 10th Edition	The London case uses customer master-data thinking for connection applicants, account relationships, and service interactions across planning, operational, and reporting functions.	MDM programmes often promise one master system without first clarifying identity logic, authority boundaries, or the specific decisions that depend on better customer data.
Stage 4. Information Systems Architecture	EA30 Asset and network data architecture for utilities	G190, Information Mapping, Long Term Development Statement direction, Energy digitalisation framework, Data Best Practice guidance	This module uses the London case to show why network topology, asset condition, planning assumptions, telemetry, and publication views cannot be treated as isolated technical datasets.	A common mistake is to let operational-system boundaries dictate the architecture of enterprise information. That makes it harder to publish, analyse, or govern the data coherently.
Stage 4. Information Systems Architecture	EA31 Metadata management and information publication	G234, Metadata Management, G190, Information Mapping, Data Best Practice guidance, Long Term Development Statement direction	The London case uses metadata management to support LTDS-style publication, data best practice, and internal discoverability across planning and operational consumers.	Metadata work often gets postponed because it looks administrative. Later the enterprise discovers that publication and analytics are much harder without it.
Stage 4. Information Systems Architecture	EA32 Business intelligence, analytics, and decision support	G238, Business Intelligence and Analytics, G190, Information Mapping, G234, Metadata Management	The London case uses analytics architecture to support planning visibility, operational insight, publication obligations, and board-level governance over transformation progress and resilience posture.	Dashboards often arrive before semantics, authority, or metadata are settled. That can create fast but misleading decision support.
Stage 4. Information Systems Architecture	EA33 Application architecture, ABBs, and SBBs	G248, Selecting Building Blocks, The TOGAF Standard, 10th Edition	In the London case, application architecture clarifies responsibilities for planning, publication, telemetry, customer interaction, and governance support before platform choices are finalised.	A common failure is to treat the selected vendor product as the architecture. That skips the layer where responsibilities and reuse should have been decided first.
Stage 4. Information Systems Architecture	EA34 Integration, interoperability, and coupling decisions	The TOGAF Standard, 10th Edition, G190, Information Mapping, G248, Selecting Building Blocks	The London case uses integration decisions to connect planning, operations, publication, telemetry, and governance flows without letting one system boundary dominate the whole architecture.	If integration is designed only service by service, the enterprise loses sight of cross-system dependency risk and publication discipline.
Stage 4. Information Systems Architecture	EA35 London LTDS and CIM information architecture walkthrough	G190, Information Mapping, G21B, Information Architecture Customer Master Data Management, G234, Metadata Management, G238, Business Intelligence and Analytics, G248, Selecting Building Blocks, Long Term Development Statement direction, Energy digitalisation framework	The London case focuses on LTDS-style publication expectations, CIM alignment pressure, internal information reuse, and the need to support both public and operational consumers without confusing authority.	If the walkthrough is treated as a data-model lesson only, the learner misses the enterprise-architecture value of deciding authority, reuse, publication scope, and governance roles.
Stage 5. Technology Architecture and Cross-Cutting Design	EA36 Phase D and technology architecture in context	The TOGAF Standard, 10th Edition, G152, Integrating Risk and Security within a TOGAF Enterprise Architecture, G21I, Microservices Architecture, G242, Environmentally Sustainable Information Systems, G21D, Government Reference Model	In the London case, technology architecture must support resilience, publication, interoperability, governance, and future change, not merely stand up more systems.	Technology architecture becomes weak when it ignores the earlier phases and behaves as if vendor capability alone is enough to justify the target state.
Stage 5. Technology Architecture and Cross-Cutting Design	EA37 Platform strategy and interoperability	The TOGAF Standard, 10th Edition, G21D, Government Reference Model, G217, Using the TOGAF Standard in the Digital Enterprise	In London Grid Distribution, platform strategy affects integration consistency, operational support, resilience posture, publication capability, and the ease with which new planning or governance demands can be absorbed.	Platform strategy often swings between two bad extremes: total standardisation that ignores local need, or total freedom that destroys enterprise coherence.
Stage 5. Technology Architecture and Cross-Cutting Design	EA38 Integrating risk and security into architecture	G152, Integrating Risk and Security within a TOGAF Enterprise Architecture, Cyber Assessment Framework, The TOGAF Standard, 10th Edition	In the London case, cyber resilience is inseparable from data publication, OT and IT dependency management, identity, governance, and operational change sequencing.	Security-only review language often arrives too late and speaks only in control terms. Architecture needs earlier, structural risk thinking.
Stage 5. Technology Architecture and Cross-Cutting Design	EA39 Microservices and when not to use them	G21I, Microservices Architecture, The TOGAF Standard, 10th Edition	The London case asks where service decomposition helps planning, publication, or telemetry capabilities, and where a simpler modular approach would create less operational overhead.	Architecture teams often discuss microservices in technical purity terms instead of enterprise-operating terms. That usually leads to a costly mismatch.
Stage 5. Technology Architecture and Cross-Cutting Design	EA40 Sustainable information systems and carbon-aware design	G242, Environmentally Sustainable Information Systems, The TOGAF Standard, 10th Edition	The London case uses sustainability mainly through infrastructure intensity, data retention, analytical workload, operational monitoring, and the broader public-value context of grid transformation.	Sustainability work becomes weak when it is left as generic aspiration rather than tied to concrete architecture levers.
Stage 5. Technology Architecture and Cross-Cutting Design	EA41 Government and regulated-sector reference models	G21D, Government Reference Model, Federal Enterprise Architecture resources, Common Approach to Federal Enterprise Architecture, DoD Architecture Framework	London Grid Distribution sits in a strongly governed environment where reference-model thinking matters, but it still needs local architecture choices shaped by actual utility reality.	If a reference model is used as a substitute for enterprise-specific analysis, the architecture effort becomes compliant-looking but weak.
Stage 5. Technology Architecture and Cross-Cutting Design	EA42 Technology gap analysis, constraints, and trade-offs	The TOGAF Standard, 10th Edition, G152, Integrating Risk and Security within a TOGAF Enterprise Architecture, G242, Environmentally Sustainable Information Systems	The London case uses this logic for resilience, interoperability, security, publication support, and operational dependency management.	A technology gap log becomes weak when it names missing tools instead of missing architectural properties or capabilities.
Stage 5. Technology Architecture and Cross-Cutting Design	EA43 London OT, IT, and telecom resilience architecture	G152, Integrating Risk and Security within a TOGAF Enterprise Architecture, Cyber Assessment Framework, G21I, Microservices Architecture, The TOGAF Standard, 10th Edition, Long Term Development Statement direction	This walkthrough examines London Grid Distribution's OT, IT, telecom, data, and governance dependency structure as one architectural problem rather than a set of separate domain silos.	If resilience is treated as a security-only topic or an operations-only topic, the architecture misses the cross-domain dependency picture that TOGAF is supposed to surface.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA44 Opportunities and solutions	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	For the London case, opportunities and solutions combine business, information, application, and technology changes into packages that improve connections, publication, resilience, and governance together.	This phase becomes weak when it degenerates into procurement discussion before the enterprise has grouped the architecture change coherently.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA45 Transition architectures and work packages	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM, G212, Digital Technology Adoption Readiness Assessment and Roadmap Development	London Grid Distribution needs transition states because data publication, planning, application boundaries, and resilience controls cannot all change at once without operational risk.	Teams often treat transition architecture as a project schedule. It is more than that. It is an interim architectural state with its own logic and constraints.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA46 Migration planning and roadmap logic	The TOGAF Standard, 10th Edition, G212, Digital Technology Adoption Readiness Assessment and Roadmap Development, G188, Architecture Project Management	The London roadmap must balance service pressure, data-publication duties, operational resilience, and delivery feasibility without overloading the enterprise.	A roadmap with no explicit dependency model often becomes a calendar of wishful thinking.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA47 Iteration inside and across ADM cycles	The TOGAF Standard, 10th Edition, G210, Applying the TOGAF ADM using Agile Sprints, G20F, Enabling Enterprise Agility	The London case uses iteration because business, information, technology, and governance questions mature at different times and under different delivery pressures.	The most common mistake is to talk about iteration while still managing the architecture as if every phase must be fully closed before the next can start.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA48 Architecture landscape and partitioning	The TOGAF Standard, 10th Edition, G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM	The London case needs partitioning because connections, publication, resilience, and governance work progress at different levels and with different rhythms, yet still depend on one another.	Partitioning becomes harmful when it is used to push difficult cross-cutting problems out of sight.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA49 Agile sprints, project management, and architecture change	G210, Applying the TOGAF ADM using Agile Sprints, G20F, Enabling Enterprise Agility, G188, Architecture Project Management	The London transformation uses agile-style delivery for some system and data changes, but it still needs explicit architecture gates, repository updates, and transition-state discipline.	A common failure mode is using agile language to avoid architectural accountability or using architecture language to resist incremental learning.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA50 Readiness assessment and adoption sequencing	G212, Digital Technology Adoption Readiness Assessment and Roadmap Development, The TOGAF Standard, 10th Edition	The London case uses readiness assessment to judge how quickly planning, publication, resilience, and governance changes can be introduced without overwhelming the organisation.	If readiness is assessed only at the end, it becomes an excuse for delay rather than a design input.
Stage 6. Opportunities, Solutions, Migration, and Delivery	EA51 London transformation roadmap and evidence gates	The TOGAF Standard, 10th Edition, G188, Architecture Project Management, G210, Applying the TOGAF ADM using Agile Sprints, G212, Digital Technology Adoption Readiness Assessment and Roadmap Development, NESO Connections Reform, ED3 framework decision	The walkthrough shows how connection-service improvement, publication discipline, resilience strengthening, and governance capability are sequenced as a transformation, not as isolated projects.	The risk here is collapsing back into project language without preserving the architecture logic that justifies the roadmap.
Stage 7. Running EA as a Capability	EA52 EA capability, roles, and operating model	G184, Leader's Guide to Establishing and Evolving an EA Capability, G249, Architecture Roles and Skills, The TOGAF Standard, 10th Edition	The London case uses capability design to decide how architecture interacts with planning, operations, cyber, data, and delivery teams over time.	Architecture capabilities often fail because their remit is broad but their authority, interfaces, and measures are vague.
Stage 7. Running EA as a Capability	EA53 Architecture Board and decision rights	The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability	The London board must deal with cross-cutting decisions on data authority, roadmap changes, resilience trade-offs, and exceptions that affect regulated outcomes or major dependencies.	A board that reviews everything usually decides little and teaches delivery teams to work around it.
Stage 7. Running EA as a Capability	EA54 Compliance, waivers, and architecture contracts	The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability	The London case uses compliance and waiver logic to control changes that affect publication quality, resilience posture, or cross-enterprise interoperability.	A rigid no-waiver posture usually pushes non-compliant decisions into the shadows. A no-compliance posture creates drift. TOGAF needs a managed middle path.
Stage 7. Running EA as a Capability	EA55 Skills, roles, and maturity models	G198, Architecture Skills Framework, G203, Architecture Maturity Models, G249, Architecture Roles and Skills	The London case uses role and maturity thinking to judge whether the utility can sustain repository quality, governance discipline, information-architecture control, and roadmap stewardship.	Maturity language can quickly become vanity language if no operational consequence follows from it.
Stage 7. Running EA as a Capability	EA56 Running TOGAF without bureaucracy	TOGAF overview, The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability, G20F, Enabling Enterprise Agility	The London case shows that even a regulated enterprise needs proportionate governance, not blanket process weight. Some decisions deserve deep review. Many do not.	The phrase tailored often hides two different behaviours: smart simplification or method erosion. The difference is whether the architecture can still defend its decisions.
Stage 7. Running EA as a Capability	EA57 London governance repository and assurance model	G184, Leader's Guide to Establishing and Evolving an EA Capability, G198, Architecture Skills Framework, G203, Architecture Maturity Models, G249, Architecture Roles and Skills, The TOGAF Standard, 10th Edition	The London case shows how repository quality, board choices, compliance decisions, and evidence expectations interact to sustain the architecture over a longer transformation horizon.	Governance pictures that look tidy but do not show decision rights, evidence, or exception handling are usually incomplete.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA58 TOGAF with ArchiMate	TOGAF overview, ArchiMate overview	The London case does not implement final ArchiMate models in this stage, but it identifies where the repository artefacts would benefit from a formal modelling language later.	A common mistake is to think using ArchiMate automatically means doing TOGAF well or that TOGAF automatically gives you a modelling notation with enough precision on its own.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA59 TOGAF with BIZBOK	TOGAF overview, Business Architecture Guild, BIZBOK Guide table of contents, G211, Business Capabilities, Version 2, G178, Value Streams	The London case already shows where deeper business-architecture practice matters, especially around capabilities and value streams. This module clarifies where BIZBOK would deepen that work and where TOGAF still carries the method backbone.	A shallow comparison says one framework is business-focused and the other is enterprise-focused. A better comparison asks what each one is for, how much method it provides, and how it supports governance or cross-domain work.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA60 TOGAF with DoDAF and FEAF	TOGAF overview, DoD Architecture Framework, Federal Enterprise Architecture resources, Common Approach to Federal Enterprise Architecture, Federal Enterprise Architecture Framework Version 2	The London case is not a defence or federal case, but it does benefit from understanding how stronger viewpoint discipline and reference-model logic can complement TOGAF in a regulated setting.	A weak comparison ignores the purpose and audience each framework was designed for and reduces the exercise to a feature checklist.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA61 TOGAF with Zachman	TOGAF overview, Zachman official site	The London case could use Zachman as a completeness check for questions and perspectives, but it still needs TOGAF or another method to run the architecture work coherently.	The main comparison risk is overstating Zachman as if it were simply another end-to-end method on the same terms as TOGAF.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA62 Common misconceptions and where TOGAF is inappropriate	TOGAF overview, The TOGAF Standard, 10th Edition, G184, Leader's Guide to Establishing and Evolving an EA Capability, G20F, Enabling Enterprise Agility	The London case is a strong TOGAF fit because it crosses business, information, application, technology, governance, and regulated-change concerns. A smaller or faster problem might not justify the same method weight.	Misconceptions often come from bad implementation. That does not mean every criticism is unfair. It means the criticism should be directed at the right layer: method design, tailoring, governance behaviour, or organisational culture.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA63 Tailoring TOGAF by size, speed, and risk	TOGAF overview, The TOGAF Standard, 10th Edition, G20F, Enabling Enterprise Agility, G184, Leader's Guide to Establishing and Evolving an EA Capability	The London case demonstrates a relatively full TOGAF use because the problem is wide and regulated. A smaller enterprise or a more contained initiative would reduce the artefact set and governance surface.	Tailoring fails when it is framed only as cutting documentation rather than as redesigning the method around the enterprise's real constraints.
Stage 8. Comparison, Tailoring, Limitations, and Capstone	EA64 End-to-end London Grid Distribution capstone	TOGAF overview, The TOGAF Standard, 10th Edition, TOGAF Library, Clean Power 2030 Action Plan, NESO Connections Reform, Long Term Development Statement direction, ED3 framework decision	The London capstone walks through the repository as an integrated architecture pack for the fictional distributor, with explicit notes on what each artefact is for and what decision it supports.	The main risk is to treat the capstone as a recap only. Its real value is in proving that the pieces connect and that the method produces a defendable architecture story.