Phase D and technology architecture in context

Phase D is not a fresh start. It does not invite the enterprise to forget everything decided in Phase B, Phase C, and the Preliminary Phase and begin with a blank infrastructure diagram. Its purpose is to translate the business outcomes, information structures, application boundaries, and architecture principles already established into concrete technology services, infrastructure patterns, resilience postures, integration foundations, and operating constraints.

That translation is what gives Phase D its value. A target architecture that cannot trace itself back to upstream decisions is usually just an implementation preference with architecture language applied afterwards. The word "translate" is deliberate. A translator does not invent new content. A translator takes meaning from one domain and expresses it faithfully in another. Phase D translates enterprise meaning into technology terms.

Consider the difference. A technology architecture that says "we recommend Kubernetes on AWS with a service mesh" without explaining why those choices support the business architecture, information authority model, or resilience principles is not a translation. It is a product preference. A technology architecture that says "the information authority model requires separated OT and IT data stores; the resilience principle requires OT recovery independent of enterprise IT availability; the publication obligation requires analytical data available without coupling to OT uptime; therefore the federated platform model with independent data stores is the better enterprise fit" is a translation. The reasoning runs from upstream to technology, not the other way around.

The word "support" in that definition carries real weight. Technology architecture supports the other domains. It does not override them, replace them, or operate independently of them. If the technology target could have been written without any reference to the business, information, or application work, it is not supporting those domains. It is ignoring them.

C220 Part 2 of the TOGAF Standard lists the objectives of Phase D. Every one of them reinforces the translation principle. The enterprise should be able to read each objective and see that it connects technology work to upstream architecture reasoning. Here they are in full, with a plain-English explanation of each.

Objective 1: Develop the target technology architecture

This is the primary output. The target technology architecture describes the technology estate the enterprise is moving towards. It must describe that estate in terms that are traceable to business, information, and application decisions, not in terms that only make sense to infrastructure specialists. In London Grid Distribution, the target technology architecture would describe the platform landscape, resilience posture, and integration foundations needed to support the connections reform business case, the LTDS publication obligation, and the OT/IT separation principle.

Objective 2: Develop the baseline technology architecture, if not already done

The baseline is a description of the technology estate as it exists today. Without a baseline, the enterprise cannot run a meaningful gap analysis because it has nothing to compare the target against. In London, the baseline would capture the current SCADA platform, enterprise IT landscape, telecom dependencies, and data infrastructure.

Objective 3: Identify technology architecture gaps

Gap analysis compares the baseline and target to identify what is missing, what is surplus, and what needs to change. A technology gap should be described as a missing capability or property, not as a missing product. "We lack the ability to recover publication services independently of OT system uptime" is a gap. "We do not have Product X" is a procurement statement.

Objective 4: Select and develop candidate architecture roadmap components

This objective connects Phase D directly to the architecture roadmap that will be developed more fully in Phase E and Phase F. Phase D does not produce the full roadmap, but it identifies the major technology change components that the roadmap will need to sequence. In London, candidate roadmap components might include the OT/IT network separation, the publication pipeline build, and the telecom resilience programme.

Objective 5: Resolve impacts across the architecture landscape

Technology choices do not exist in isolation. They affect other parts of the architecture landscape. A platform change that improves resilience but breaks an existing integration pattern has a cross-landscape impact. Phase D must identify these impacts and resolve them, or at least make them visible for governance to address.

Objective 6: Develop transition architectures where appropriate

Not every technology target can be reached in a single step. Transition architectures describe stable intermediate states the enterprise passes through on its way to the target. Each transition must be operationally viable. In London, a transition might involve separating OT and IT networks before migrating the publication pipeline, because the publication pipeline depends on the separated network being in place.

Objective 7: Generate the Architecture Definition Document contribution

The Architecture Definition Document is the primary deliverable that captures baseline, target, and gap information across all four domains. Phase D contributes the technology section. That section must be readable alongside the business, information, and application sections, not as a separate document that uses different vocabulary and references none of the upstream decisions.

Every significant Phase D decision should be traceable to something decided or discovered earlier. The main inheritance paths are described below. These are not optional references. They are the inputs that give technology architecture its enterprise justification.

From the Preliminary Phase and Phase A

Architecture principles. Principles established in the Preliminary Phase should visibly influence Phase D. If a principle says "prefer open standards for cross-domain exchange," that principle should be traceable in how Phase D selects integration technology. If a principle says "operational technology must recover independently of enterprise IT," that principle should be traceable in how Phase D designs resilience boundaries. Principles that exist in a separate document but appear nowhere in the technology target are governance decoration.

Stakeholder concerns and Architecture Vision scope. Phase A defined which concerns the architecture must address and which areas are in scope. Phase D must respect that scope. A technology team that expands its remit beyond the agreed scope without governance approval is not doing better architecture. It is creating ungoverned work.

From Phase B: Business Architecture

Business outcomes, capabilities, and service expectations. These explain what the technology estate must support and at what level of performance, availability, and resilience. A technology target that ignores business expectations is architecturally orphaned. In London, the connections reform business case, the regulatory publication obligation, and the grid decarbonisation strategy all set expectations that Phase D must meet.

Value streams and business process constraints. These shape how technology services need to support end-to-end business flows. If the connections value stream requires automated customer self-service, the technology architecture must provide the platform capabilities that make self-service possible.

From Phase C: Information Systems Architectures

Information authority, metadata, publication, and integration realities. These constrain technology choices because the platforms chosen must be capable of supporting data governance, exchange patterns, and publication obligations already identified. In London, the LTDS publication obligation requires technology that can combine operational, planning, and analytical data reliably. The Common Information Model adoption decision from Phase C shapes which integration technology Phase D selects.

Application responsibilities and boundary decisions. These shape platform needs, runtime requirements, connectivity demands, and deployment patterns. Technology choices that contradict application boundaries create expensive rework. If the application architecture separated the publication pipeline from the operational data store, the technology architecture must provide the infrastructure that supports that separation.

Phase D is not one question. It is a family of related questions that must be answered coherently. Each question should be answered in enterprise terms first and platform terms second.

Platform and infrastructure

Which technology services, runtime environments, and shared capabilities will form the backbone of the target state? Hosting, compute, storage, and networking decisions live here, but they should follow enterprise need rather than lead it. The question is not "which cloud provider is best?" The question is "what platform characteristics does the enterprise need to support the application boundaries, data governance model, and resilience posture already decided?"

In London, platform questions include whether OT platforms and enterprise IT should share infrastructure or be physically separated, what level of compute and storage the publication pipeline needs, and whether analytical workloads should run on the same platform as operational systems.

Security and resilience

How will technology choices protect the enterprise against failure, compromise, and slow recovery across real dependencies? Security is not an appendix. It is a structural concern that shapes boundary design, dependency management, and recovery architecture. The question is not "which security products should we buy?" The question is "which trust boundaries, dependency chains, and recovery paths does the enterprise need, and how do they map to the OT security posture, cyber assessment framework, and resilience principles already established?"

In London, security and resilience questions span the OT/IT boundary, the telecom dependency on field communications, the smart-meter network integrity, and the publication pipeline availability. Each of these crosses traditional team boundaries, which is precisely why they need enterprise architecture treatment.

Interoperability and integration

How will the technology estate support data exchange, process coordination, and consistent interfaces across boundaries? Interoperability is not a vague aspiration. It is a measurable property that Phase D must make explicit. The question is "can the technology choices support the integration patterns and data exchange formats that Phase C defined, and can operations teams monitor and support the result using existing tools?"

Operability and changeability

How easy will the estate be to run, observe, support, and evolve once delivery pressure arrives? A target that is elegant on paper but impossible to operate is a weak architecture. The question is "can the enterprise actually support this technology target with the skills, processes, and tooling it has or can realistically acquire?"

Governance and traceability

Can the enterprise explain why these technology choices exist and how they trace back to upstream architecture decisions? If the reasoning is invisible, governance becomes ritual rather than discipline. The Architecture Board should be able to pick up any technology choice in the Phase D output and follow the reasoning back to a business outcome, information-authority decision, application boundary, or architecture principle.

C220 Part 2 lists the inputs that Phase D should receive. Understanding these inputs is essential because they define the traceability paths that make technology architecture governable. The full list is:

1. Request for Architecture Work or equivalent trigger from Phase A.
2. Capability assessments from the Preliminary Phase and Phase A.
3. Communications plan from the Architecture Vision phase.
4. Organisation model for enterprise architecture from the Preliminary Phase.
5. Tailored architecture framework from the Preliminary Phase.
6. Approved Statement of Architecture Work from Phase A.
7. Architecture principles including technology principles from the Preliminary Phase.
8. Enterprise continuum and architecture repository content.
9. Architecture Vision from Phase A.
10. Business, data, and application architecture outputs from Phases B and C (the most important inheritance).
11. Draft Architecture Definition Document containing baseline and target content from earlier phases.
12. Draft architecture requirements specification from Phases B and C.

The length of that list is itself instructive. Phase D does not operate in a vacuum. It receives more upstream input than almost any other ADM phase because its job is to translate those inputs into technology terms.

Weak technology architecture tends to share a few recognisable symptoms. Learning to spot them is a practical skill that every architect needs.

The target state reads like a product catalogue. Named vendors and features dominate. Capability reasoning and traceability are absent. The document could have been written by a sales engineer rather than an enterprise architect. The test is straightforward: remove all product and vendor names from the document. If what remains has no coherent enterprise reasoning, the technology architecture is weak.

The technology choices could have been made without any reference to the business, information, or application work. That usually means the earlier stages were either skipped or ignored. If the technology team started its work before Phase B and Phase C were complete, the traceability was probably invented after the fact rather than built into the process.

Security, resilience, and operability appear as afterthoughts. A separate security review arrives late and produces a long list of exceptions rather than a short list of structural changes. Resilience is stated as a target number (99.9 per cent availability) without any explanation of the dependency chains, trust boundaries, or recovery paths that would achieve it. Operability is assumed rather than assessed.

Governance cannot explain why the technology shape is right for this enterprise. The Architecture Board can approve the document but not challenge the reasoning, because the reasoning was never made explicit. When a board member asks "why did we choose this platform over the alternatives?" the answer is "the team preferred it" rather than "the platform supports the interoperability, resilience, and governance needs that the architecture principles require."

The transition path is missing or trivial. The target is described as though the enterprise can jump to it in one step. No transition architectures, no sequencing logic, and no acknowledgement that the baseline constrains what can change first.

A useful quality test for any Phase D output is straightforward: could this technology target have been written before the business, information, and application stages existed? If the answer is yes, the traceability is too weak.

A distribution network operator needed to choose between a single integrated SCADA-historian platform and a federated model with separate OT and IT data stores. The Phase D analysis traced the choice back to three upstream inputs: the information-authority model, which required clear separation of operational and analytical data ownership; the resilience principle, which demanded that OT recovery not depend on enterprise IT availability; and the publication obligation, which required timely analytical data without coupling publication to OT system uptime.

The federated model won, not because it was technically simpler, but because it was the better enterprise fit. That is the traceability test in practice. The reasoning runs from enterprise need through architecture principles to technology choice. Anyone reading the decision can follow the chain.

The traceability test also works in reverse. If you pick up a technology choice from the Phase D output and ask "which upstream decision does this support?" and the answer is silence, the choice is architecturally orphaned. It may still be technically reasonable. But it cannot be governed as an enterprise decision because the rationale that connects it to the wider architecture is missing.

C220 Part 2 also lists the outputs of Phase D. These outputs are what the rest of the ADM and the enterprise governance structure depend on. The full list includes:

• Refined Architecture Vision, updated to reflect technology architecture decisions and any new constraints discovered during Phase D.
• Draft Architecture Definition Document, now including the technology architecture contribution alongside business, data, and application content.
• Draft architecture requirements specification, updated with technology-specific requirements.
• Technology architecture components of an architecture roadmap, identifying major change initiatives and their sequencing dependencies.
• Impact analysis results, showing how technology choices affect other parts of the architecture landscape.
• Transition architectures where needed, describing stable intermediate states.

Notice that every output is either an update to a cross-domain document or a contribution to a cross-phase process. None of the outputs is a standalone technology-team document. That design is deliberate. Phase D outputs are meant to be read alongside the outputs of Phases B and C, not in isolation.

In London Grid Distribution, Phase D has to support publication, interoperability, cyber resilience, telecom dependency, governance evidence, and future change at the same time. That makes traceability essential. The technology choices cannot be defended only on technical grounds.

Consider the specific upstream decisions that shape London's Phase D work. The connections reform business case (from Phase B) requires a digital customer self-service channel, automated workflow, and real-time network capacity assessment. Those business requirements translate into platform needs: a workflow engine, an API gateway for customer access, and integration with the distribution management system.

The LTDS publication obligation (from Phase C) requires that operational, planning, and analytical data can be combined, validated, and published on a regulatory timetable. That information requirement translates into technology needs: a data pipeline with clear separation between operational sources and publication outputs, an audit trail for published data, and recovery capability that does not depend on OT system availability.

The OT/IT separation principle (from the Preliminary Phase) requires that operational technology can recover independently of enterprise IT. That principle translates into infrastructure requirements: separate network paths, independent identity management for OT systems, and recovery procedures that do not assume enterprise IT is available.

• London Phase D is about resilience, operability, and coherence, not just more modern platforms.
• Every major technology choice should be explainable in enterprise language before it is explained in platform language.
• The connections reform business case, LTDS publication obligations, and OT/IT separation principle all feed directly into Phase D decisions.
• The telecom dependency on field communications is a technology architecture concern that crosses traditional team boundaries and requires explicit treatment in Phase D.
• Transition architectures are essential for London because the enterprise cannot take the control room offline for six months while it upgrades infrastructure. Each transition must leave the network safe and the lights on.