London LTDS and CIM information architecture walkthrough

The walkthrough uses the London case to prove that the individual concepts taught across Stage 4 can be assembled into a single defensible architecture view. A Phase C pack is the combined set of information-architecture and application-architecture outputs that together describe what information the enterprise depends on, who is authoritative for it, which applications support it, how CIM alignment is maintained, how it is integrated and published, and how the whole arrangement is governed.

The pack is not a collection of separate modelling exercises. It is one coherent answer to the enterprise question: can we trust what we publish, and can we prove why?

The London Phase C pack follows a deliberate six-layer sequence. Each layer builds on the one before it and answers a question that the next layer depends on.

1. Information-domain map (Module 27). The enterprise can see the core information groupings in plain language. The London map includes customer, connection, planning, asset, network, telemetry, and publication domains. Each domain is named in enterprise language, has identified consumers and producers, and follows a G234 data architecture pattern (centralised, federated, replicated, or hybrid).
2. Authority map (Module 28). Each domain has visible stewardship, publication, attribute, and lifecycle authority boundaries using the five-layer information authority ownership model. The London authority map shows, for example, that planning-assumption authority sits in the modelling tool while publication authority for the same information sits in the LTDS layer.
3. CIM alignment decisions (Module 30). The pack documents where CIM mappings exist, where CIM is used natively, and where the enterprise has deliberately chosen proprietary structures with rationale. CIM alignment is particularly important at the planning-to-publication and network-to-external boundaries.
4. Metadata and publication rules (Module 31). Every published London output carries the six G234 metadata concerns: meaning, provenance, stewardship, lifecycle, classification, and quality confidence. The pack specifies which metadata fields are mandatory for each publication type.
5. Application responsibilities and key interactions (Module 33). The London ABB catalogue names the enterprise services: planning-evidence preparation, publication management, telemetry ingestion, customer-data stewardship, network-model management, and governance reporting. Each ABB has metamodel relationships showing which data entities it interacts with and which capabilities it supports. SBB mappings trace each product choice back to an ABB with explicit rationale.
6. Integration and governance notes (Module 34). Each integration has a decision record stating purpose, C220 Part 3 interoperability level, authority assumptions, coupling choice, and failure consequences. The London telemetry flows use loose coupling with buffering. Publication flows require semantic and organisational interoperability. Governance reporting flows tolerate batch latency but need strong semantic consistency.

The sequence is not arbitrary. Each layer answers a question that the next layer depends on. Starting with application responsibilities before the information domains are clear tends to produce platform-driven answers rather than enterprise-driven ones.

The strongest test of a Phase C pack is whether a governance board can trace any published figure from the consumer back to its authoritative source. Here is how that trace works for a London network capacity figure published under LTDS obligations.

1. Published output. A network capacity headroom figure appears in the LTDS publication portal. The metadata states it is a planning estimate based on the 2024Q3 scenario, produced on a specific date, stewarded by the planning team, and carrying a stated confidence level.
2. Publication ABB. The publication management service (an ABB) prepared and validated the output. The SBB mapping shows which specific platform performed the preparation.
3. CIM alignment. The published figure uses CIM-aligned structures at the publication boundary. The CIM mapping documentation shows how the internal planning-model output was translated to CIM-compatible format.
4. Integration path. The planning-to-publication integration uses a governed batch transfer with semantic interoperability. The integration decision record states the coupling choice, failure handling, and authority assumptions.
5. Authority chain. The planning-evidence preparation service (another ABB) produced the forecast. The authority map shows that planning-assumption authority sits with the planning team and the modelling tool. Asset and network input data were authoritative from their respective domain owners.
6. Source domains. The information-domain map shows which domains fed the forecast: asset information, network topology, planning assumptions, and telemetry observations. Each domain has its own authority, stewardship, and data architecture pattern documented in the pack.

If the governance board can follow this trace from published output back to source domains, the Phase C pack has done its job. If any link in the chain is missing or unclear, the pack is incomplete.

The London case faces four external pressures that test the quality of the Phase C pack.

Model alignment pressure. The enterprise needs its published and reusable information to align with CIM expectations closely enough to remain interpretable and useful. CIM alignment is not about technical schema compliance alone. It is about whether the enterprise's internal information structure can produce outputs that external consumers can interpret correctly.

Publication pressure. LTDS-style publication requires the enterprise to share network development information that is current, traceable, and trustworthy. That is a higher standard than internal reporting because external consumers cannot ask the data team for context. The published output must carry its own context through metadata.

Application pressure. The participating applications need clear responsibilities so model alignment does not collapse into hidden point-to-point workarounds. If no ABB is named for publication preparation, the work tends to distribute across several teams with no single point of accountability.

Consumer pressure. Public and internal consumers need information that is not only available but also understandable, current, and responsibly described. The architecture must serve both the producers who create information and the consumers who interpret it.

A governance board reviewing the London Phase C pack should be able to answer six questions without leaving the room.

• Which information domains matter and how they relate. The board should see the enterprise information structure in plain language.
• Where authority, stewardship, and publication responsibility sit. The board should know who is accountable for every major information asset, using the five-layer ownership model.
• How CIM alignment is maintained. The board should understand where CIM mappings exist, where CIM is used natively, and where proprietary choices were made with rationale.
• What metadata travels with published outputs. The board should see that every publication type has mandatory metadata fields covering the six G234 concerns.
• Which application responsibilities support those information needs. The board should see the logical services (ABBs) involved, the SBB mappings, and the metamodel relationships.
• How integration, interoperability, and governance make the outputs trustworthy. The board should see integration decision records with interoperability levels, coupling choices, and failure consequences.

The Phase C pack produced in this walkthrough provides the information and application architecture foundation that the rest of the course depends on.

Stage 5 (Technology Architecture, Phase D) builds on the Phase C pack by selecting the technology services, platforms, and infrastructure that will host the application responsibilities defined here. If the Phase C reasoning is strong, technology choices can be traced back to enterprise needs rather than floating free as platform preferences.

Stage 6 (Migration and Delivery, Phase E and Phase F) uses the Phase C pack to sequence information, application, and technology changes in a coherent order. The roadmap needs to respect the authority boundaries, integration dependencies, and CIM alignment decisions documented in the pack.

Stage 7 (Governance, Phase G and Phase H) uses the Phase C pack as the reference architecture against which implementation work is governed. If the pack is clear and complete, governance reviews can ask precise questions about whether implementation is following the agreed architecture.

Without a strong Phase C, the roadmap becomes a technology project list without an enterprise anchor. With a strong Phase C, every subsequent decision has a traceable justification.

This module is the London translation in its fullest form for Stage 4. It uses LTDS-style publication expectations, CIM alignment pressure, internal planning reuse, and governance needs to show what Phase C looks like when the enterprise problem is real enough to matter.

• The London walkthrough is the flagship Stage 4 case because it forces all six Phase C layers to work together.
• If the pack is clear here, Stage 5 can move into technology choices without losing the enterprise reasoning underneath them.
• A London governance board should be able to pick up the Phase C pack, ask where any published figure comes from, and trace the answer through authority, CIM mapping, metadata, application responsibility, and integration back to the enterprise information domain.
• If the pack supports that trace, Phase C has done its job.
• The seven London information domains (customer, connection, planning, asset, network, telemetry, publication) with their authority assignments, CIM alignment decisions, metadata requirements, ABB catalogue, and integration records form the complete Stage 4 output.