London kickoff: principles, stakeholders, and vision

A coherent kickoff pack is one where every artefact traces to every other artefact. That is not the same as repetition. Each artefact should add something the others do not. The scenario adds specificity about the problem. The principles add decision rules. The stakeholder map adds accountability structure. The work statement adds governance and boundaries. Coherence means that all of these pieces point in the same direction and that a reader can follow a thread from any one artefact to any other.

In practice, coherence is tested by asking three questions. First: does every concern in the stakeholder map appear in the scenario, the vision, or the work statement? If a concern is important enough to register but not important enough to address or explicitly defer, the pack has a gap. Second: does every principle trace to a tension visible in the scenario or stakeholder map? A principle without a traceable origin is decoration. Third: does the work statement's scope align with the vision's direction and the scenario's problem description? If the vision says one thing, the work statement says another, and the scenario describes a third, the pack is incoherent and Phase B will inherit that confusion.

The London case is useful precisely because it has enough complexity to demonstrate real coherence challenges. The enterprise touches regulatory interfaces, operational technology, telecoms infrastructure, data governance, cyber security, and customer-facing services. Without explicit traceability across the opening artefacts, each domain team will interpret the pack differently and the architecture will fragment before Phase B is half-way done.

The London kickoff pack contains six artefacts. Here is each one, its purpose, and what it must contain for the London case specifically. This is a complete walkthrough: it pulls together the content developed across Modules 8 through 14 and shows how the pieces fit together.

1. Boundary statement (Module 8). Defines the effective enterprise boundary for the first ADM cycle. For London, the boundary includes internal business and technology functions (planning, network design, commercial assessment, works scheduling, data stewardship, cyber security, telecoms operations) plus regulated interfaces (Ofgem reporting obligations, NESO data-exchange requirements) and external delivery partners (contractors, field service providers). The boundary deliberately excludes generation connection assessment, wholesale market interfaces, and long-term network investment planning. Each exclusion has a rationale documented in the boundary statement.

2. Stakeholder concern map (Module 9). Separates the stakeholder landscape into distinct blocs, each with specific concerns that require different architecture views. For London Grid:

• Ofgem (regulatory compliance, connections performance reporting, published data accuracy, enforcement risk).
• NESO (planning data for national network coordination, data-exchange format compliance, timeliness of submissions).
• Operations leadership (network safety, supply continuity, outage management, OT system reliability).
• Cyber security (OT and telecoms estate protection, SCADA interface security, NIS Directive compliance, vulnerability management).
• Telecoms operations (private telecoms network reliability, bandwidth for SCADA and protection systems, migration from legacy communication protocols).
• Connections team (process efficiency, data quality at handoff points, response time against the 65-day target, applicant communication).
• Data stewardship (single authoritative source for published data, data-quality monitoring, metadata management, publication traceability).
• Connection applicants (response time, transparency of progress, accuracy of published capacity information).

Each stakeholder bloc maps to specific architecture outputs. Ofgem's concerns drive the information-publication architecture. The connections team's concerns drive the process and integration architecture. Cyber security's concerns drive the OT/telecoms resilience assessment.

3. Principles pack (Module 10). Six hard-edged principles that shape later design, evidence, and exception decisions. Each principle carries a statement, rationale, and implications that can be tested against real trade-offs. For London:

• "One published truth per data item per date." Rationale: contradictory publications undermine regulatory standing. Implication: every published data item must have one authoritative source and one publication path.
• "No operational change without documented rollback." Rationale: network safety depends on reversibility. Implication: every architecture transition must include a tested rollback procedure.
• "Structured handoff at every integration point." Rationale: manual data re-entry causes errors and delays. Implication: all five connections handoff points must use structured, validated data exchange.
• "Separate operational governance from delivery governance." Rationale: operational decisions (network safety) and delivery decisions (project timelines) follow different risk profiles. Implication: architecture governance must distinguish between operational exceptions and delivery exceptions.
• "Cyber evidence before operational deployment." Rationale: OT systems cannot be patched as easily as IT systems. Implication: every change to an OT or telecoms asset must have a cyber-security assessment before deployment.
• "Regulatory traceability from source to publication." Rationale: Ofgem expects auditable data chains. Implication: every published figure must be traceable to its source data, transformation logic, and publication date.

4. Business scenario (Module 11). The connections-modernisation scenario documents the specific enterprise situation: 90-day average response time against a 65-day target, five handoff points with manual data re-entry at two of them, a legacy network planning tool using pre- CIM format, contradictory published data, and a shared works management system with a conflicting upgrade timeline. The scenario names eight human actors (from connection applicants to NESO) and five computer actors (from the customer portal to the GIS). This scenario grounds every other artefact: without it, the principles would be generic, the vision would be aspirational, and the work statement would lack justification.

5. Architecture Vision (Module 14). Explains the directional shift toward more credible connections responsiveness, stronger information-publication discipline, and controlled resilience across OT, IT, and telecoms. The vision is traceable to the scenario (which documented the problem), the stakeholder map (which identified the concerns), and the principles (which provide the decision rules). It is directional, not encyclopaedic: it says where London Grid is heading without pretending every target-state detail is already known.

6. Statement of Architecture Work (Module 14). Defines the first-cycle commission: connections process end-to-end, information-publication chain, and OT/IT/telecoms resilience interfaces. Names the deliverables for each phase. Explicitly excludes generation connection assessment, wholesale market interfaces, long-term network investment planning, and smart-meter data integration. Specifies the governance path (fortnightly Architecture Review), the repository stewardship, the resource plan, and the acceptance criteria.

The six artefacts form a chain. Each one depends on the others and adds something the others do not.

1. The scenario explains why the architecture effort exists. Without the scenario, the direction is aspiration. With it, the direction is grounded in actors, handoffs, data failures, and regulatory pressure.
2. The boundary explains what the first cycle is responsible for. Without the boundary, the scope is either everything (which is unmanageable) or undefined (which causes arguments). With it, the architecture team knows which interfaces, systems, and organisations are in play.
3. The stakeholder map explains whose concerns must be answered. Without the map, the architecture team guesses at priorities. With it, every architecture view has a named audience and a documented concern.
4. The principles explain how trade-offs should be governed. Without principles, every contested decision is resolved by whoever has the most influence. With them, the Architecture Board has explicit rules to apply.
5. The vision explains the direction of change. Without the vision, the work statement is a list of tasks. With it, the work is connected to a purposeful transformation.
6. The work statement explains what architecture effort is authorised now. Without it, the architecture team has direction but not commission. With it, the team knows what to produce, what to exclude, and how the work will be governed.

The traceability links between artefacts should be explicit, not implied. The scenario should reference specific stakeholders. The principles should reference specific tensions from the scenario. The vision should reference specific concerns from the stakeholder map. The work statement should reference specific principles that govern its scope decisions. When these links are explicit, any reviewer can follow a thread from a stakeholder concern through the scenario to a principle to the vision to a specific deliverable in the work statement. That end-to-end traceability is what separates a coherent pack from a filing exercise.

The Statement of Architecture Work for London Grid's first ADM cycle should contain the following. Each section traces to the artefacts developed in earlier modules.

Project description. An architecture engagement to design and govern the connections-modernisation transformation, information-publication reform, and OT/IT/telecoms resilience baseline for London Grid Distribution. The engagement is commissioned because the connections process does not meet the Ofgem performance target, published data is inconsistent, and the organisation lacks a shared architecture authority across operational domains.

Vision reference. The engagement is governed by the Architecture Vision approved on [date], which sets direction toward credible connections responsiveness, single-source information publication, and governed resilience.

Scope. In scope: connections process (application to works scheduling), information-publication chain (source data to regulatory submission), OT/IT/telecoms resilience interfaces (assessment and baseline only in cycle one). Excluded from cycle one (with rationale): generation connection assessment (lower regulatory priority and fewer data-quality issues), wholesale market interfaces (managed by a separate programme), long-term network investment planning (strategic planning cycle on a different timeline), smart-meter data integration (pending national programme alignment).

Method. TOGAF ADM Phases B through E, tailored for a single-cycle engagement with London-specific domain focus. Phase B: business architecture (connections value stream, capability assessment, organisation mapping). Phase C: information systems architecture (data authority, information flow, integration patterns). Phase D: technology architecture (OT/IT/telecoms resilience baseline). Phase E: opportunities and solutions (work-package identification and priority sequencing).

Deliverables.

• Connections value-stream map with handoff assessment (Phase B, week 6).
• Capability assessment for connections, data governance, and cyber resilience (Phase B, week 6).
• Organisation mapping showing accountability for each process stage (Phase B, week 6).
• Information-flow model with data-authority assignments (Phase C, week 14).
• Publication-chain design with traceability from source to regulatory output (Phase C, week 14).
• Integration-pattern specification for the five handoff points (Phase C, week 14).
• OT/IT/telecoms resilience baseline assessment (Phase D, week 18).
• Work-package catalogue with priority sequencing and dependency mapping (Phase E, week 22).

Roles. Lead architect (named, accountable for pack coherence and traceability). Two domain architects (data/information and operations/technology). Repository steward (named, accountable for evidence quality and versioning). Sponsor delegate at fortnightly reviews.

Governance. Fortnightly Architecture Review with the sponsor (or delegate), lead architect, repository steward, and rotating domain representatives from operations, cyber, data, and regulatory affairs. Decisions recorded in the repository with traceability to principles and scenario evidence. Principle exceptions require a formal waiver approved by the governance forum. Escalation path through the sponsor to the programme board.

Constraints and dependencies. Works management system shared with another programme (conflicting upgrade timeline). Legacy CIM format in the network planning tool. Regulatory reporting deadlines that constrain transition timing. Architecture team limited to three people for the first cycle. Cyber-security assessment capacity shared with BAU vulnerability management.

Acceptance criteria. The first cycle is complete when: all eight deliverables are versioned in the repository; each deliverable has been reviewed by the governance forum; the sponsor has confirmed that the work-package catalogue is sufficient to inform investment decisions; and the exclusion rationale has been reviewed and confirmed as still valid.

A coherent London pack passes the following tests. Each test is specific enough to use as a review checklist.

• Concern traceability: every concern in the stakeholder map appears in at least one other artefact (the scenario, a principle, the vision, or a deliverable in the work statement). No concern is registered and then ignored.
• Principle grounding: every principle traces to a specific tension visible in the scenario or stakeholder concerns. "One published truth per data item per date" traces to the contradictory publications described in the scenario. "No operational change without documented rollback" traces to the operations team's concern about network safety during transition.
• Scope consistency: the work statement's scope aligns with the vision's direction and the scenario's problem description. If the vision says "connections responsiveness," the work statement includes connections process artefacts. If the scenario identifies OT resilience as a pressure, the work statement includes a resilience baseline.
• Exclusion justification: every exclusion in the work statement has a documented rationale that traces to a scope decision, a resource constraint, or a dependency that prevents coverage in the first cycle.
• Governance connection: the governance arrangements in the work statement reference the principles (which govern design decisions) and the stakeholder map (which determines who participates in reviews).
• Forward readiness: someone reading the pack end to end can explain what Phase B will produce, for whom, under what rules, and what it will not cover.

The simplest way to verify coherence is to pick any single concern from the stakeholder map and trace it through every other artefact. If the thread is continuous from concern to scenario to principle to vision to deliverable to governance review, the pack is coherent. If the thread breaks at any point, the pack has a gap.

The opening story described a pack that was a collection of standalone documents. It is worth being explicit about what distinguishes a coherent pack from a pile of documents, because the difference is not always visible on a document title page.

A pile of documents has artefacts written by different people at different times without cross-referencing. The stakeholder register lists roles but not the concerns that the architecture must address. The principles have statements but no implications. The scenario could apply to any organisation in the sector. The vision references transformation language without connecting to specific pressures. The work statement lists deliverables without explaining what is excluded. Each document passes a standalone quality review but none of them depends on the others.

A coherent pack has artefacts that were developed in sequence, each building on the previous one. The stakeholder map identifies specific concerns that the scenario substantiates. The principles address specific tensions visible in the scenario. The vision traces to specific concerns and drivers. The work statement names deliverables that correspond to stakeholder needs and scope boundaries. The exclusions are justified by resource constraints, dependencies, or deliberate deferral decisions documented in the boundary statement.

The practical consequence is significant. A pile of documents requires the Phase B team to rediscover the connections between artefacts before they can start work. A coherent pack allows Phase B to begin immediately because the connections are already explicit.