London connections modernisation walkthrough

By now the learner has seen the parts. Modules 16 through 23 each introduced a specific method: Phase B orientation, business models, organisation mapping, capabilities, capability-based planning, value streams, footprints, and gap analysis. The walkthrough shows how the parts work together on a single problem.

The walkthrough is not a summary of previous modules. It is a worked example that forces the concepts to interoperate. If any concept does not contribute to the overall argument, it exposes a weakness in the method or in the application. The walkthrough tests whether Stage 3 is truly coherent or merely a collection of individually sound artefacts.

The London connections challenge is a strong test case because it can easily be reduced to a system conversation if the business layer is weak. "Replace the connections portal" is a plausible-sounding programme objective that misses most of the business-architecture substance. The walkthrough demonstrates what the enterprise loses when it skips the business layer and what it gains when the business layer is done properly.

The walkthrough begins where Phase B should begin: with the business-model questions that anchor the entire architecture effort in enterprise purpose. These questions come from the G18A Business Models guide and were introduced in Module 17.

What value is at stake?London Grid Distribution exists to deliver safe, reliable electricity distribution services across London. The connections modernisation affects how the enterprise meets its obligation to connect new demand and generation to the network in a timely, transparent, and evidence-backed manner. The value at stake is not a portal. It is the enterprise's ability to fulfil a core regulatory and commercial obligation.

Who experiences the outcome? Customers waiting for connections. Local planning authorities coordinating infrastructure development. The regulator (Ofgem) assessing performance against licence conditions. NESO managing the connections queue nationally. Internal teams whose operational effectiveness depends on accurate planning data. Each of these stakeholders experiences the connections outcome differently, and a complete business architecture must address all of them.

Which obligations shape the operating logic? Licence conditions governing connection timescales. Connections reform expectations from NESO. LTDS publication accuracy requirements. Price control obligations under the RIIO framework. Cyber resilience standards from the National Cyber Security Centre. These obligations are not optional. They define the operating envelope within which the architecture must work.

What is becoming more important? Information quality, planning transparency, and digital service responsiveness are shifting from secondary concerns to primary obligations. The regulatory environment is tightening. Stakeholder expectations are rising. The architecture must prepare for a future where these concerns are front-line requirements, not back-office activities.

The organisation mapping (from Module 18) reveals the relationships that shape the connections outcome. This is not an org chart. It is a view of who is responsible for what, where handoffs cross team boundaries, and where accountability is unclear.

Three critical interface problems appear in the London case.

1. The planning-to-design handoff loses information. The planning team and the design team use different systems with no shared evidence base. When a connection moves from assessment to detailed study, the design team often re-gathers data that the planning team already assembled. This is not a technology problem at root. It is an organisational-interface problem: two teams that should share a common view of capacity data instead operate in isolated toolsets.
2. The governance review cycle introduces delays. The Architecture Board reviews connections evidence on a fixed monthly schedule rather than on demand. A connection decision that is ready on day two of the month waits twenty-eight days for review. The governance structure was designed for a lower volume of decisions and has not adapted to the current pace of connection requests.
3. The data governance function has responsibility without authority. The data team is accountable for information quality but has no authority over the systems that generate the data. When GIS data is incomplete or DMS records are outdated, the data team can report the problem but cannot compel the system owners to fix it. This responsibility-authority mismatch means data quality improvements stall.

The capability and value-stream views provide the core analytical pair of the walkthrough. They answer two complementary questions: what must the enterprise be able to do (capabilities), and where does the stakeholder outcome get delayed (value stream)?

Key London capabilities

The capability map (from Module 19) identifies the following as architecture-relevant capabilities for the connections transformation: customer connections management, network planning visibility, connection design coordination, information publication, operational resilience governance, evidence-backed decision-making, and data quality management. Each capability has been assessed against the G211 maturity framework, with planning visibility and information publication rated as the weakest.

The connections value stream

The value stream (from Module 21) traces the flow from request through assess, study, decide, publish, connect, operate, and learn. Pain points concentrate at three handoff transitions: assess-to-study (information loss, twelve to fifteen working days added), decide-to-publish (manual transcription errors), and connect-to-operate (incomplete as-built records creating downstream data-quality problems).

The cross-reference

The bidirectional relationship between capabilities and value stages (explained in Module 21) makes the walkthrough coherent rather than fragmented. A weak capability in planning visibility shows up as a bottleneck in the assess-to-study value stage. A weak capability in information publication shows up as errors in the decide-to-publish transition. These cross-references are not decorative. They are the mechanism that connects the "what needs to improve" view (capabilities) to the "where does it hurt" view (value stream).

The cross-reference also prevents the walkthrough from becoming a capability exercise disconnected from stakeholder impact. Every capability weakness that the architecture identifies should be traceable to a specific value stage where the stakeholder outcome is affected. If a capability is weak but no value stage depends on it, the capability gap may not be relevant to this transformation.

The footprint view (from Module 22) connects goals, services, capabilities, and measures on one page. In the walkthrough, it serves as the synthesis layer that combines the outputs of the preceding steps into an evaluable argument for change.

The London footprint connects five goals (reduce connection elapsed time, achieve LTDS accuracy, establish planning data completeness, reduce governance cycle time, achieve traceable incident response) to seven business services, the enabling capabilities that support them, and specific observable measures that make the target testable.

The footprint is where the walkthrough becomes evaluable rather than descriptive. Without the footprint, the walkthrough could describe the business problem clearly but could not answer the governance question: "How will we know if this is better?" With the footprint, every goal has a measure, every service has a performance expectation, and every capability has a connection to the outcomes it enables.

The gap analysis (from Module 23) brings the walkthrough to its conclusion by identifying where the current arrangement cannot support the required outcomes, and by attaching consequence, dependency, and intervention logic to each gap.

Gap 1: Planning-data visibility. Consequence: continued planning delays and inaccurate connection offers. Dependencies: foundational, blocking Gaps 3 and 4. Intervention: information architecture change supported by application integration.

Gap 2: Accountability clarity. Consequence: rework and finger-pointing at handoff points. Dependencies: independent, can proceed in parallel. Intervention: governance change and organisation-interface redesign.

Gap 3: Publication quality. Consequence: regulatory non-compliance risk and industry loss of confidence. Dependencies: partially depends on Gap 1. Intervention: data governance strengthening and system-of-record clarification.

Gap 4: Governance confidence. Consequence: slow decision-making and inability to demonstrate responsive governance. Dependencies: partially depends on Gaps 1 and 3. Intervention: governance process redesign with supporting architecture tooling.

The gap view also reveals the sequencing logic. Gap 1 and Gap 2 should be addressed in the first transition state because Gap 1 is foundational (unblocking Gaps 3 and 4) and Gap 2 is independent (can proceed in parallel). Gaps 3 and 4 follow once the planning-data and accountability foundations are in place.

The strongest discipline in the walkthrough is resisting the pull toward system language before the business layer is complete. This pull is strong because system conversations feel concrete and business-architecture conversations can feel abstract. But yielding to the pull too early means the business layer never gets established, and later technology decisions have no business anchor.

Four practical disciplines help maintain the boundary.

1. Stay with service, ownership, handoff, and evidence problems until the business pack is coherent. Systems are supporting examples, not the main story.
2. Ask whether the business gap could remain even if a current system were replaced. If the answer is yes, the discussion belongs at the business layer. In the London case, three of four major gaps would survive a complete system replacement because their root causes are in accountability, governance, and data quality, not in technology.
3. Use capability language rather than product language. "Improve network planning visibility" is capability language that guides architecture. "Implement Vendor X's planning module" is product language that constrains architecture.
4. Test every statement against the footprint measures. If a proposed change does not improve any of the footprint measures, it may not belong in the current architecture scope.

A coherent Stage 3 business-architecture pack for the London connections modernisation includes the following elements, each connected to the others.

1. Business-model frame anchoring the transformation in enterprise purpose, regulatory obligations, and stakeholder outcomes.
2. Organisation relationship view showing interface problems at handoff points, not just reporting lines.
3. Capability map with assessment results identifying the enterprise abilities that need to improve, rated against a maturity framework.
4. Value stream with pain points showing where the stakeholder outcome is delayed, degraded, or made expensive, cross-referenced to capabilities.
5. Footprint view with measures connecting goals, services, capabilities, and specific observable measures into an evaluable argument for change.
6. Gap log with consequence, dependency, and intervention providing the change logic that feeds later phases.

The test of coherence is whether each element refers to and reinforces the others. The capability weaknesses should appear as value-stream bottlenecks. The value-stream bottlenecks should appear as gaps in the gap log. The gaps should connect to services and goals in the footprint. And the footprint measures should provide the success criteria that the whole pack is working toward.

If any element stands alone without connections to the others, the pack is a collection, not an architecture. The walkthrough discipline is to follow each connection and verify that it holds.