London OT, IT, and telecom resilience architecture

This module is the Stage 5 proof point. Each earlier module introduced a concept. This module shows them working together. The synthesis is deliberate.

Phase D translation (Module 36). Every London technology choice traces back to upstream business, information, and application decisions. The connections reform business case, the LTDS publication obligation, and the OT/IT separation principle all create specific inputs that Phase D translated into technology terms.

Platform strategy (Module 37). London uses controlled variance: strong enterprise IT defaults, justified OT exceptions, and interoperability rules that apply at every domain boundary. The four TOGAF interoperability categories (operational, information, technical, business) are all tested at the OT/IT, IT/publication, and telecom/OT boundaries.

Risk and security integration (Module 38). Security is structural, not decorative. The G152 risk categories (especially concentration and dependency risk) shape the architecture design itself. The SABSA layers provide the security architecture structure from contextual (business resilience needs) through logical (trust zones) to physical (enforcement mechanisms).

Microservice restraint (Module 39). London does not decompose everything into microservices. The four-dimension assessment shows that OT telemetry should stay monolithic (tight coupling, low change rate) while publication may benefit from separation (distinct regulatory cadence, clear domain boundaries).

Sustainability (Module 40). Carbon-aware design patterns apply to specific London levers: tiered telemetry ingestion (demand shaping), right-sized data retention (regulatory vs. analytical), and demand-shifted batch processing. Safety always takes precedence.

Gap analysis and trade-offs (Module 42). Every London gap is described as a missing capability with consequence, constraints, and an ADR-format trade-off record. The gaps carry enough information for Stage 6 roadmap sequencing.

Reference models (Module 41). London adopts the CIM and NCSC CAF, adapts cross-sector digital infrastructure guidance for enterprise IT, and resists generic office-enterprise models that would hide OT and telecom realities.

London Grid Distribution operates across several technology domains that are often managed by separate specialist teams. The resilience architecture must make the dependencies between them visible in a single view.

OT layer

Operational platforms and control environments whose availability and recoverability affect core service reality directly. SCADA, distribution management systems, protection relay management, and substation automation all sit here. These systems have the longest change cycles (three to five years), the highest safety criticality, and the strictest security requirements. They must recover independently of enterprise IT.

Telecom layer

Field communications, smart-meter networks, control-system links, and enterprise communications paths whose trust boundaries and availability shape operational resilience. The telecom layer is often the hidden dependency. It carries SCADA telemetry, smart-meter data, fault-reporting signals, and enterprise communications. A single carrier outage can degrade all four simultaneously. The architecture must make this dependency as visible as the OT and IT dependencies.

Enterprise IT and data layer

Applications, data flows, publication services, and enterprise controls that support visibility, governance, and cross-domain coordination. The LTDS publication pipeline, asset-management systems, geographic information systems, analytical workloads, and the customer connections workflow all sit here. These systems have faster change cycles and benefit from enterprise platform standardisation.

Governance and assurance layer

Architecture Board decisions, dispensations, evidence, and recovery expectations that sit above the estate but must still reflect its real dependencies. Governance cannot challenge what it cannot see. The governance layer depends on accurate, timely information flowing up from operational systems. If the information flow is compromised, governance decisions are made on stale or inaccurate data.

The most important thing the resilience architecture must show is how failures propagate across domain boundaries. Each dependency path is a potential failure chain.

OT to Telecom. SCADA systems depend on telecom links for remote monitoring and control. Smart-meter infrastructure depends on wide-area networks for data collection. Protection relays communicate status through telecom paths. Each of these dependencies creates a failure path from the telecom layer into the OT layer. If the telecom link fails, the control room loses visibility of remote substations. That is not just an IT problem. It is a safety problem.

Telecom to Enterprise IT. Enterprise network infrastructure carries both OT traffic and IT traffic in some configurations. If the same network path serves SCADA and enterprise email, a congestion or security event in one can affect the other. The architecture must specify whether OT and IT traffic share paths, and if so, what priority and isolation mechanisms protect OT traffic.

Enterprise IT to Publication. The LTDS publication pipeline depends on data from analytical systems, which depend on telemetry from OT, which depends on telecom. A single failure in any upstream layer can degrade publication timeliness or accuracy. The architecture must specify the data-freshness requirements and the fallback behaviour when upstream data is delayed.

Enterprise IT to Connections. The digital connections workflow depends on real-time network capacity data from the DMS and GIS. If those systems are unavailable, the connections process either stalls or makes capacity decisions based on stale data. The architecture must specify the acceptable staleness window and the fallback process.

All layers to Governance. The Architecture Board, risk committee, and regulatory reporting all depend on the accuracy and timeliness of information flowing up from operational systems. If the information flow is compromised by a telecom outage, governance decisions are made on incomplete data. The architecture must make this dependency visible.

A governance-ready resilience architecture should answer four questions that specialist silos typically cannot.

Which shared dependencies could damage several capabilities if they fail together? The telecom carrier example is the clearest case. A single carrier outage affects SCADA telemetry, smart-meter collection, fault reporting, and publication. The enterprise needs to see this concentration risk in a single view and make an explicit governance decision about whether to accept it, mitigate it through diversification, or stage a migration.

Where do trust boundaries need to be explicit instead of assumed? The boundary between OT and IT is often assumed rather than drawn. The boundary between enterprise IT and the publication pipeline is rarely discussed in security terms. The boundary between internal analytics and external regulatory interfaces may not exist at all. Each of these boundaries should be drawn, labelled, and the enforcement mechanism stated.

What recovery evidence should exist before a design can be accepted as resilient enough? Resilience claims without recovery evidence are aspirations. The architecture should specify what evidence is needed: tested failover procedures, documented recovery time objectives for each dependency chain, and evidence that recovery priorities follow the dependency sequence.

Which cross-domain design compromises need enterprise governance rather than local technical approval? A decision to share an identity provider across OT and IT is an enterprise risk decision, not a local technical convenience. A decision to route OT and IT traffic over the same telecom path is a resilience decision that the Architecture Board should review. The architecture must flag these decisions for enterprise-level governance.

OT experts, telecom specialists, cyber teams, and enterprise architects each see a different slice of the problem. The enterprise loses important signal when those slices are never combined.

The OT team knows that SCADA depends on telecom links but may not know which carrier paths are shared with enterprise IT. The telecom team knows the network topology but may not know which business processes depend on which paths. The cyber team knows where controls are deployed but may not see the full failure chain that a single compromised link could trigger. The enterprise IT team knows the application landscape but may not understand the OT recovery sequence that must precede application recovery.

The resilience architecture is the place where the combination happens. Its value is not in adding new information. It is in connecting information that already exists in separate teams into a single dependency picture that governance can use. That is the fundamental contribution of enterprise architecture to resilience: not deeper specialist knowledge, but broader cross-domain visibility.

A governance-ready technology architecture view for London should meet four tests.

Dependency visibility. The most critical dependency chains are drawn, labelled, and explained. A reviewer can trace from a business outcome through the technology layers to the dependencies that could disrupt it. The telecom carrier dependency, the OT/IT data path, and the publication pipeline chain should all be visible in the same view.

Trust boundary clarity. The boundaries between OT, IT, telecom, and external services are explicitly marked. Where boundaries are enforced, the mechanism is stated (firewall, network segmentation, identity separation). Where boundaries are assumed but not enforced, the gap is flagged for governance attention.

Recovery specificity. Recovery expectations are attached to specific dependency chains, not stated as generic targets. "Restore telecom path to SCADA within one hour; restore analytical data feed within two hours; restore publication pipeline within four hours if telecom path is available" is an architecture target with recovery sequencing. "99.9 per cent availability" without dependency-chain context is an aspiration.

Governance traceability. The view shows which decisions were made by the Architecture Board, which were made locally under delegated authority, and which have not yet been decided. Undecided items should be flagged as open risks, not left invisible.

Bringing together the gap analysis from Module 42, here are the priority London gaps that feed into Stage 6 roadmap planning.

Gap 1: OT/IT network separation. The enterprise cannot guarantee independent OT recovery while OT and IT traffic share network paths. Priority: highest (prerequisite for other changes). Constraint: migration must not disrupt operational systems. ADR decision: staged separation starting with critical SCADA paths.

Gap 2: Telecom carrier diversification. A single carrier outage degrades SCADA, smart-meter, fault-reporting, and publication capabilities simultaneously. Priority: high. Constraint: 12 to 18 months for infrastructure changes. ADR decision: local SCADA fallback within six months; full diversification over 18 months.

Gap 3: Publication pipeline independence. The enterprise cannot publish LTDS data within regulatory timescales if the OT data store is unavailable. Priority: high (regulatory). Constraint: must not compromise data integrity. ADR decision: event-driven analytical data copy with four-hour consistency window.

Gap 4: Cross-domain observability. No single view shows dependency chains across OT, telecom, IT, and governance. Priority: medium-high (governance enabler). Constraint: OT monitoring and IT monitoring use different tools. ADR decision: cross-domain dashboard aggregating alerts from both toolsets, with dependency-chain context.

Gap 5: Identity separation. A single identity provider serves OT and IT, creating concentrated dependency risk. Priority: medium. Constraint: OT systems require specific access patterns that enterprise identity tools may not support natively. ADR decision: federated identity with domain-specific access policies, reviewed at next architecture cycle.

These gaps carry enough information for Stage 6 to sequence the roadmap: Gap 1 precedes Gap 3 (publication depends on separated network). Gap 2 can run in parallel with Gap 3. Gap 4 can proceed independently. Gap 5 can be staged after Gap 1.