London Grid Distribution orientation and source discipline

London Grid Distribution is a fictional Distribution Network Operator (DNO) used to teach enterprise architecture through one coherent enterprise and one coherent Architecture Repository. The company is fictional. The surrounding GB institutional, regulatory, digitalisation, and cyber environment is grounded in current public sources.

That distinction matters. Without it, the case would drift into generic utility storytelling and the architecture would feel unearned. Every architecture decision in the London case must be defensible against real GB constraints. If the case says London Grid must publish Long Term Development Statements, that obligation traces to a real Ofgem direction, not to something the course author invented.

The case is designed at the scale of a single DNO licence area covering the London region. This gives enough complexity to justify real enterprise architecture without sprawling into a national-sector survey. London provides high-demand urban pressure, constrained infrastructure, a dense mix of OT and IT systems, and the governance density that makes enterprise architecture necessary rather than optional.

What it is. The process by which customers, generators, and developers connect to the electricity distribution network is under intense reform. In recent years, the backlog of connection applications has grown dramatically across GB. The National Energy System Operator (NESO) has led a connections reform programme to streamline queue management, introduce milestones, and remove speculative applications.

For a DNO like London Grid, connections modernisation means redesigning the end-to-end journey from application to energisation. This includes customer-facing portals, internal workflow systems, capacity assessment tools, and the interfaces with NESO and other parties.

What drives it. The connections reform is driven by the need to accelerate the deployment of distributed energy resources (solar panels, batteries, EV charging infrastructure, heat pumps) that are essential for net zero. The Ofgem ED3 framework decision sets the price control parameters that determine how much the DNO can invest and what outcomes it must deliver on connections timelines.

Why it needs architecture. Connections modernisation is not a single IT project. It spans business processes (how applications are assessed), data (capacity models, queue management, customer records), applications (portals, workflow engines, assessment tools), and technology (integration with NESO systems, GIS updates, metering interfaces). Without enterprise architecture, these changes happen in silos. The portal team redesigns the customer interface without knowing what the capacity assessment team is changing. The workflow team automates a process that the business has already decided to restructure. Architecture provides the coordination layer that prevents these collisions.

What it is. DNOs are required to publish detailed information about the state and future plans of their networks. The Long Term Development Statement (LTDS) is the primary vehicle: it describes available capacity at each substation, planned reinforcement work, and demand forecasts. Beyond the LTDS, DNOs increasingly publish real-time and near-real-time data about network conditions.

The Common Information Model (CIM) is the international standard (IEC 61968/61970) that defines how electricity network data should be structured. Adopting CIM means that London Grid's data can be consumed by external parties, regulatory systems, and academic researchers without translation errors. Smart meters add another data dimension: half-hourly consumption data at millions of premises, flowing through the Data Communications Company (DCC) infrastructure.

What drives it. Ofgem's LTDS direction is a regulatory requirement, not a voluntary initiative. The Energy Digitalisation Strategy and the broader push for open data in the energy sector add further pressure. DNOs that cannot publish credible, standards-aligned data face regulatory scrutiny and reputational damage.

Why it needs architecture. Network visibility is a data architecture and information architecture challenge. The data originates in operational systems ( SCADA, DMS, GIS), passes through integration layers, gets transformed into CIM-compliant formats, and is published to external platforms. Each step involves data quality, data ownership, metadata management, and security decisions. Without architecture, the publication pipeline is fragile: a change in one source system can break the entire downstream chain.

What it is. The GB electricity system is shifting from a model where large power stations generate electricity and networks simply deliver it, to a model where millions of small distributed energy resources (DERs) both consume and generate electricity. Rooftop solar panels export power back into the network. Home batteries store cheap overnight electricity and discharge it during peak hours. Electric vehicles draw significant power when charging but could also feed power back through vehicle-to-grid technology.

Flexibility is the ability to adjust electricity consumption or generation in response to network conditions. A Distribution System Operator (DSO) actively manages these two-way power flows, procures flexibility services from DER owners, and coordinates with NESO to balance the wider system. The transition from passive DNO to active DSO is one of the most significant changes in the GB energy sector.

What drives it. The net zero target requires massive electrification of heating (via heat pumps) and transport (via electric vehicles). This will roughly double the electricity demand on distribution networks. Building new infrastructure to meet all of that demand is prohibitively expensive and slow. Flexibility services are cheaper and faster: instead of building a new cable, the DNO can pay local battery owners to reduce their demand during peak periods. Demand response programmes and flexibility markets are emerging rapidly.

Why it needs architecture. Flexibility requires new systems for market platforms, dispatch optimisation, settlement, and monitoring. It requires new data flows between the DNO, aggregators, DER owners, and NESO. It requires new business processes for procurement, dispatch, and payment. And it requires new technology for real-time monitoring and control at the low-voltage network level, where many DNOs currently have limited visibility. Without architecture, these systems will be built in isolation, with incompatible data models, duplicated capabilities, and no coherent interoperability strategy.

What it is. GB DNOs operate under a price control regime set by Ofgem. The current framework, ED3, determines how much each DNO can charge customers, what outcomes it must deliver, and how its performance is measured. The Regional Energy Strategic Planner (RESP) role, managed through NESO, introduces whole-system coordination that means the DNO cannot plan in isolation.

For London Grid, this means every significant investment must be justified against the price control framework. The Architecture Board must demonstrate that architecture decisions are traceable to regulatory requirements, customer outcomes, and efficient use of allowances.

What drives it. Ofgem expects DNOs to publish evidence of how they spend customer money, what outcomes they achieve, and how their plans align with whole-system objectives. The National Cyber Security Centre (NCSC) Cyber Assessment Framework (CAF) adds cyber resilience expectations for operators of essential services. Open data requirements mean that internal planning data must be published in accessible, standards-compliant formats.

Why it needs architecture. Architecture governance in a regulated utility is not optional. It is the mechanism through which the enterprise demonstrates that its technology investments are justified, its data is reliable, its systems are resilient, and its decisions are traceable. Without governance, the enterprise cannot satisfy Ofgem's evidence requirements, cannot demonstrate CAF compliance, and cannot show that its architecture decisions serve customer outcomes rather than internal convenience.

Each anchor listed below is a real, named, public source. When the London case references any of these, the reference is traceable. When the case needs to go beyond what the source says, the source discipline rules (Section 7.8) require that the extension is labelled as enterprise design or teaching scenario.

Policy. DESNZ (Department for Energy Security and Net Zero) strategy documents, including the Clean Power 2030 Action Plan, the smart-meter policy framework, and the Energy Digitalisation Strategy. These shape what the fictional enterprise has to take seriously at the strategic level.

Regulation. Ofgem decisions including the ED3 framework decision, the LTDS direction, data-sharing infrastructure governance expectations, and wider digitalisation requirements. These create hard constraints, reporting obligations, and accountability structures that the fictional enterprise must respect.

Planning and operation. NESO planning structures including RESP and related whole-system coordination mechanisms. These mean the DNO cannot behave as if it operates in a sealed local world. Its plans must align with regional and national objectives.

Cyber and trust boundaries. NCSC Cyber Assessment Framework (CAF) expectations, smart-meter communications realities via the Data Communications Company (DCC), and data-sharing controls that turn OT security and data architecture into first-order enterprise concerns rather than technical afterthoughts.

Standards. IEC 61968/61970 ( CIM), IEC 62351 (security for power systems), and the broader interoperability standards that shape how the enterprise's data and systems connect to the wider energy ecosystem.

London was chosen for specific pedagogical and architectural reasons. Each reason connects to a quality that makes the case useful for teaching:

• High-demand urban pressure. London has some of the highest electricity demand density in GB. New connections for housing developments, commercial buildings, and EV charging hubs create constant pressure on the network. This gives the case realistic business drivers without requiring the course to cover every type of DNO territory.
• Constrained infrastructure. London's distribution network is mature, dense, and difficult to expand. Many cables and substations are decades old. New routes for cables are expensive and disruptive. This creates a genuine need for smart solutions, flexibility, and careful capacity management rather than simply building more infrastructure.
• Complex technology landscape. A London DNO operates SCADA systems for real-time monitoring, DMS for network management, GIS for asset location, metering systems for smart meters, customer portals for connections, and enterprise IT systems for finance, HR, and corporate functions. This gives the case a believable mix of OT, telecoms, enterprise IT, and data-complexity issues in one place.
• Governance density. The combination of Ofgem price control, NESO coordination, NCSC cyber expectations, and customer scrutiny creates enough governance pressure to justify real enterprise architecture rather than a lightweight project method. Architecture exists at London Grid because the organisation cannot make coordinated investment decisions without it.

Every important London case section separates four different kinds of material. This separation is not optional. It is part of the architecture discipline itself.

Layer 1: Verified GB fact. A real public-source fact, date, body, decision, or obligation drawn from an authoritative GB source (Ofgem, DESNZ, NESO, NCSC) or an Open Group publication. When the course says "Ofgem requires DNOs to publish LTDS data," that is a verified GB fact. It can be checked against the source.

Layer 2: TOGAF concept. A concept, method element, or vocabulary item grounded in the TOGAF Standard or official guides. When the course says "the Preliminary Phase establishes the architecture framework for the enterprise," that is a TOGAF concept. It can be verified against C220 Part 1.

Layer 3: London Grid Distribution enterprise design. The course's fictional but internally coherent architecture choices, artefacts, and governance records. When the course says "London Grid's Architecture Board meets quarterly," that is enterprise design. It is fictional but consistent with how real DNOs operate.

Layer 4: Synthetic teaching scenario. A teaching device used to make a concept understandable, without pretending it is a direct extract from official sources or a real company record. When the course says "imagine a new architect arriving at London Grid on their first day," that is a teaching scenario.

The discipline requires that each claim in the course can be traced to one of these four layers. If a learner asks "is this real or made up?" the answer should always be clear.

The London case frequently references real GB sources. The referencing discipline follows strict rules:

• Name the source explicitly. Do not say "regulators require" when you mean "Ofgem's LTDS direction requires." Vague attribution breeds confusion and makes claims uncheckable.
• Distinguish obligation from interpretation. If Ofgem requires LTDS publication, say so. If the course interprets that obligation as meaning London Grid needs a CIM-compliant data pipeline, label that interpretation as enterprise design, not as regulatory fact.
• Do not claim fictional authority for real bodies. The course never says "Ofgem told London Grid to do X." Ofgem does not interact with fictional enterprises. The course says "Ofgem's published direction on LTDS creates an obligation that London Grid inherits as a fictional DNO operating under GB regulatory conditions."
• Keep sources current and checkable. Every reference to a real GB source includes enough information for the reader to find and verify the original. If a source is updated or superseded, the course should note the change.
• Separate the enterprise's interpretation from the source's content. London Grid might decide to exceed regulatory minimums on data publication. That decision is enterprise design (Layer 3), not regulatory fact (Layer 1). The course must label it accordingly.

Stage 1 of this course puts four foundational artefacts into the London Grid Architecture Repository. Every subsequent stage builds on these. By the capstone in Stage 8, they form a complete, traceable architecture repository for one fictional enterprise.

1. Repository atlas. The map that shows how principles, requirements, landscapes, standards, decisions, transitions, and governance records fit together. Think of it as the table of contents for the entire repository. It does not contain architecture content itself; it shows where each type of content lives and how the pieces connect.

2. Source ledger. The record of what came from official TOGAF sources (Layer 2), what came from official GB sources (Layer 1), and what was introduced by the case design (Layer 3). The source ledger is the traceability tool that prevents the case from drifting. When a learner asks "where did this come from?" the source ledger provides the answer.

3. Terminology translation sheet. The plain-language bridge between TOGAF terms and the practical language of the London case. For example: " Architecture Vision" becomes "the one-page case for why London Grid needs architecture work now and what it aims to achieve." " Gap analysis" becomes "the comparison between London Grid's current systems and the target state for connections, data publication, flexibility, and governance." This sheet prevents the common problem where learners know TOGAF vocabulary but cannot apply it in a specific enterprise context.

4. Opening problem frame. The agreed statement of why this enterprise needs architecture work at all. For London Grid, the opening problem frame describes the convergence of regulatory pressure (ED3, LTDS, CAF), market change ( flexibility markets, DER growth), technology complexity (OT/IT convergence, legacy replacement), and customer expectations (faster connections, better data) that makes enterprise architecture necessary. The problem frame becomes the input to Phase A when Stage 2 begins.

Good source discipline prevents four failure modes that weaken architecture teaching and, by extension, architecture practice:

• Inventing regulatory obligations. When a case invents obligations without labelling them as fictional, learners cannot tell what is real constraint and what is teaching convenience. They lose the ability to challenge architecture decisions against external evidence.
• Paraphrasing TOGAF loosely. When a course paraphrases the standard and later treats the paraphrase as if it were the standard, learners absorb incorrect definitions that they then carry into certification exams and professional practice.
• Building plausible but indefensible cases. A case that sounds reasonable but cannot withstand challenge from someone who knows the real regulatory or market context teaches learners to trust architecture outputs without evidence. That is the opposite of the discipline enterprise architecture requires.
• Creating impressive but hollow repositories. A repository that looks comprehensive but has no evidence model or authority structure behind it teaches form without substance. The source ledger and repository atlas prevent this by requiring every entry to trace its origin.

This module is the translation. It explains why the course keeps returning to the same fictional operator rather than switching examples every time a new TOGAF concept appears.

The case is the continuity device. It lets later stages deepen the same principles pack, the same stakeholder map, the same capability map, the same information-authority problem, and the same governance model until the learner can see enterprise architecture as one connected discipline rather than a collection of isolated techniques.

The four threads map directly to the four architecture domains that the ADM addresses:

• Connections modernisation drives the business architecture thread: business processes, capabilities, value streams, and organisational design.
• Network visibility and data publication drives the information systems architecture thread: data entities, data quality, application interactions, and publication pipelines.
• Flexibility and distributed energy drives the technology architecture thread: platforms, infrastructure, real-time systems, and integration technology.
• Governance, regulation, and accountability drives the cross-cutting governance thread: Architecture Board control, compliance, evidence traceability, and change management.