London transformation roadmap and evidence gates

Stage 6 concepts become real only when the learner sees them operate together. A student who can define Phase E grouping, transition architecture, migration sequencing, and evidence gates separately but cannot show how they combine in one case has understood the vocabulary without understanding the discipline.

The London walkthrough serves three purposes. First, it tests whether each concept can survive contact with a realistic enterprise problem. Second, it reveals the dependencies between concepts that are invisible when each is studied in isolation. Third, it produces a reference roadmap that demonstrates the standard of work the course expects.

The walkthrough does not introduce new theory. Every element used below was taught in Modules 44 through 50. What is new is the integration: the four work packages sitting inside three transition states, governed by three evidence gates, shaped by readiness findings, and connected to the architecture governance structures that Stage 7 will formalise.

The four work packages were grouped in Phase E using the architectural logic taught in Module 44. Each package represents a coherent set of gaps that belong together because they share dependencies, affect the same domains, or must be delivered as a unit to produce recognisable value.

Work Package 1: Case spine and evidence model

This package comes first in the sequence because customer-facing improvement without evidence discipline simply amplifies inconsistency. The package closes the gaps between the current fragmented evidence approach and a governed case-management backbone that provides traceability from connection request through to energisation. It establishes the evidence-quality rules that all subsequent work packages depend on.

Domains affected: Business (process redesign for connection workflow), Information (evidence model and data authority rules), Application (case-management platform integration).

Work Package 2: Authority and publication controls

This package stabilises the information foundation before transparency promises and larger model-led improvements scale up. It implements the data authority rules, the publication pipeline, and the quality controls that make LTDS and regulatory data publication reliable rather than heroic.

Domains affected: Information (authority model, metadata governance), Technology (publication pipeline infrastructure), Business (publication review and approval processes).

Dependency on WP1: The publication pipeline consumes evidence from the case spine. If the evidence model is not stable, the publication pipeline amplifies whatever inconsistency currently exists.

Work Package 3: Model and standards pipeline

This package turns publication and planning into a more governed, repeatable flow rather than a patchwork of local effort. It establishes the network modelling standards, validation rules, and handoff protocols that make planning outputs consistent across London's operational areas.

Domains affected: Technology (modelling platforms and integration), Information (model data standards and validation), Business (planning workflow standardisation).

Dependency on WP2: The model pipeline feeds into the publication pipeline. Models that are not governed to publication standards will fail at the publication gate.

Work Package 4: Cross-layer assurance hardening

This package protects the new state by bringing OT, IT, telecom, cyber, and governance discipline into one operating view. It closes the assurance gaps identified in the technology architecture, particularly at the OT/IT boundary where operational safety and cyber resilience intersect.

Domains affected: Technology (OT/IT boundary controls, monitoring), Business (operational assurance processes), Information (security event data and audit trails).

Dependency: Cross-layer assurance protects the state created by WP1 through WP3. It can start in parallel with WP2 for foundational security controls but reaches full operating capability only after the other packages have stabilised their domains.

The London roadmap uses three transition architectures between the baseline and the target. Each transition state delivers recognisable business value in its own right, as required by the Phase E objectives from C220 Part 1 (Architecture Development Method).

Transition State 1: Evidence foundation

WP1 (case spine and evidence model) is complete. The enterprise has a governed case-management backbone with evidence-quality rules. Connection requests can be traced from receipt through to energisation. The evidence model is stable enough for WP2 to consume.

Business value delivered: Connection process visibility, evidence traceability, reduced rework from lost or inconsistent case data.

Transition State 2: Publication and modelling discipline

WP2 (authority and publication controls) and WP3 (model and standards pipeline) are complete. The enterprise has governed data publication, authoritative data sources, and consistent network modelling across operational areas. LTDS publication is reliable and governed. Foundational WP4 controls are in place.

Business value delivered: Reliable regulatory data publication, consistent planning outputs, reduced manual reconciliation.

Transition State 3: Full operating capability (target state)

WP4 (cross-layer assurance hardening) is complete. The enterprise has integrated OT, IT, telecom, cyber, and governance assurance in one operating view. All four work packages are operational and governed. The target architecture is reached.

Business value delivered: End-to-end operational assurance, integrated cyber and architecture governance, full regulatory compliance confidence.

Each evidence gate sits between two transition states. The gate is a governed review point where the Architecture Board tests whether the conditions for proceeding are actually met. It is a decision point, not a reporting checkpoint. The board has three options at each gate: proceed, proceed with conditions, or hold and revise.

Gate 1: Between baseline and Transition State 1

What this gate tests:

• Is the current problem framing (actors, obligations, connection workflow) still correct and properly dated?
• Has the case spine been designed with evidence-quality rules that the publication pipeline can consume?
• Are the readiness factors for WP1 (vision, need, information readiness, accountability) strong enough to proceed?
• Has an architecture contract been agreed between the architecture function and the WP1 delivery team?

Gate 2: Between Transition State 1 and Transition State 2

What this gate tests:

• Does the evidence model from WP1 actually work? Is case data traceable and are evidence-quality rules enforced?
• Is the publication pipeline from WP2 designed to preserve the information authority rules? Will it consume data from authoritative sources only?
• Does the modelling pipeline from WP3 meet the data standards required for publication?
• Are the readiness factors for WP2 and WP3 (IT capacity, enterprise capacity, desire) strong enough to proceed at the planned pace?
• Are foundational WP4 security controls in place for the components being deployed?

Gate 3: Between Transition State 2 and Target State

What this gate tests:

• Do the publication and modelling pipelines operate reliably under production load?
• Does the cross-layer assurance model from WP4 integrate OT, IT, cyber, and governance signals in one operating view?
• Are release conditions and compliance evidence strong enough for the enterprise to operate in the target state without hidden debt?
• Has an architecture compliance review (TOGAF Standard, EA Capability and Governance) confirmed conformance across all four work packages?
• Are all active waivers time-bounded with compensating controls and governance approval?

The readiness assessment from Module 50 does not exist in isolation. Its findings flow directly into the evidence gate criteria. When a readiness factor is rated as low with high urgency, the corresponding gate must include a condition that tests whether readiness has improved before the enterprise proceeds.

Example: information readiness and Gate 1

Module 50 identified information readiness as a weak factor for WP1 (the existing evidence model has quality gaps). Gate 1 therefore includes a specific condition: has the evidence model been tested with real case data and do the quality rules produce consistent results? If the answer is no, the board can hold and require an information-readiness improvement before WP2 begins consuming the evidence model.

Example: enterprise capacity and Gate 2

Module 50 identified enterprise capacity as a weak factor for WP2 and WP3 (the organisation is simultaneously managing multiple regulatory programmes). Gate 2 therefore includes a condition: is the enterprise still able to absorb WP2 and WP3 at the planned pace, or should the transition be slowed to avoid overwhelming the organisation? This condition gives the board explicit authority to adjust the pace based on evidence rather than optimism.

Example: IT capacity and Gate 3

Module 50 identified IT capacity as a weak factor for WP4 (OT/IT boundary work requires specialist knowledge concentrated in few people). Gate 3 therefore includes a condition: has the specialist capacity been sufficient to complete WP4 to the required standard, or are there assurance gaps that need to be closed before the enterprise can operate safely in the target state?

A project plan and an Architecture Roadmap can look similar. Both show work items over time. The difference is governance authority and the type of evidence that drives decisions.

• A project plan is governed by delivery progress. Milestones measure whether tasks are complete, on time, and within budget. The decision at each milestone is: are we on track to deliver what was promised?
• An architecture roadmap is governed by architectural evidence. Evidence gates measure whether the enterprise state is safe, coherent, and ready for the next transition. The decision at each gate is: is the enterprise in a governed state that can support the next change?

The London roadmap is architecture-controlled because the evidence gates test architectural conditions (information authority, evidence quality, assurance integration, compliance conformance), not just delivery milestones (tasks complete, budget consumed, timeline met). A project can be on time and on budget while producing an architecturally ungoverned state. The evidence gate catches that situation; a project milestone does not.

The roadmap is also adjustable. If Gate 2 reveals that enterprise capacity is more constrained than expected, the board can slow the transition pace, defer WP3, or add resources. The adjustment is based on evidence, not on political negotiation. This is the practical value of architecture control: the enterprise can change its mind rationally, based on what has been learned, rather than being locked into a plan that ignores what has been learned.