Stage 5 summary. Technology Architecture and Cross-Cutting Design

Phase D does not invite the enterprise to forget everything decided upstream and begin with a blank infrastructure diagram. It translates the business outcomes, information structures, application boundaries, and architecture principles already established into technology services, infrastructure patterns, resilience postures, integration foundations, and operating constraints. C220 Part 1 states two canonical objectives: develop the target Technology Architecture that enables the Architecture Vision and the target business, data, and application architectures, and identify candidate Architecture Roadmap components from the baseline-to-target gaps. The word enables carries the whole idea, because Phase D serves the earlier domains rather than operating independently of them.

The ADM pursues those objectives through nine working steps, the same pattern used in Phases B and C. Select reference models, viewpoints, and tools, develop the baseline and target descriptions, perform gap analysis, define candidate roadmap components, resolve impacts across the architecture landscape, conduct the formal stakeholder review, finalise the architecture, and contribute the technology section of the Architecture Definition Document. The phase inherits more upstream input than almost any other, from principles set in the Preliminary Phase to the business, data, and application outputs of Phases B and C, and every significant decision should be traceable to something in that inheritance.

The quality check is the traceability test. If the target could have been written before the earlier stages existed, it is vendor preference dressed in architecture language. The matching symptom is a target state that reads like a product catalogue, and the diagnosis is simple. Remove the vendor names, and if no coherent enterprise reasoning remains, the technology architecture is weak. In London, the connections reform business case, the LTDS publication obligation, and the OT/IT separation principle are the upstream decisions every technology choice must answer to.

A platform strategy decides how much standardisation the enterprise needs, where exceptions are allowed, and how interoperability is preserved across teams. Picture a bank where every team chose its own message broker: the account, payment, and fraud systems could not exchange data without costly bespoke bridges. The architecture question is never which stack has the best features. It is how much consistency the whole enterprise needs to keep moving together, which is why a platform choice is an architecture decision affecting reuse, interoperability, operating model, and risk.

Two extremes fail. Rigid standardisation ignores real local need, forces workarounds, and breeds shadow IT. Uncontrolled freedom destroys integration and coherence. Controlled variance is the stronger target: strong defaults with clear rationale, an explicit and governed exception process, and interoperability rules that apply to defaults and exceptions alike. The G217 digital enterprise patterns, platform as capability, multi-speed architecture, and guardrail governance, make controlled variance workable across teams that change at different speeds.

Interoperability itself has a formal frame. The TOGAF interoperability requirements framework in the C220 ADM techniques lists three categories, operational or business, information, and technical, and this course splits the combined category to teach four lenses, operational, information, technical, and business. All of them should be assessed at every major platform boundary, and interoperability should appear as an explicit comparison criterion in every platform decision, because feature lists and analyst scores are not enough. In London, the estate spans OT, enterprise IT, publication, and telecom domains, and the strategy must explain what rules hold at each boundary.

Early security changes the architecture. Late security mostly raises cost and exception volume, because by the time a separate review arrives the structure, trust relationships, and technology choices are expensive to reverse. A hospital that separates patient records from the public booking site by design removes a whole class of breach before any control catalogue is opened. The strongest decisions make some risks impossible or much less likely, which is why risk and security belong in the design while boundaries and dependencies are still cheap to alter.

G152 gives this discipline its method, integrating security and risk into each ADM phase from security principles and risk appetite in the Preliminary Phase through to governance. The stage applies six risk categories with it: strategic, operational, technical, compliance, information, and concentration. Four kinds of architecture decision almost always need security input, boundary, dependency, recovery, and governance choices. Controls then follow the structural reasoning rather than replacing it. A risk register records concerns; integrated security changes the design.

Where the enterprise operates critical infrastructure or needs auditable traceability from business security objectives to operational controls, the TOGAF and SABSA Integration white paper (W117) maps SABSA's layered model onto TOGAF phases, so security architects contribute at every level instead of producing a parallel document. In London, the most dangerous risks sit between domains, OT to telecom, telecom to IT, IT to publication, and making those cross-domain dependencies visible is precisely what enterprise architecture is for.

Microservices change more than code structure. They change operating demands, team coordination, observability requirements, and governance complexity, so the decision belongs to the enterprise, not to a single code base. One well-known example saw a streaming company move a monitoring workload back from microservices to a single deployable component because the cost of distribution outweighed the benefit for that problem. The choice is about operating capability and domain fit, not the elegance of a diagram.

The stage's discipline is the four-dimension assessment, completed and recorded before the architecture commits: domain quality, deployment pressure, operating capability, and team structure. When domain boundaries are unclear, deployment pressure is absent, or operating maturity is insufficient, a modular monolith with clear internal boundaries is often the stronger choice. The monolith-first strategy is not anti-microservice, it is pro-evidence, earning service boundaries through operational experience rather than assuming them from theory. Conway's Law is not optional either, because service boundaries that ignore team boundaries and communication patterns buy coordination overhead that offsets the architectural benefit.

The same restraint governs emerging technologies. AI, IoT, and edge computing should be assessed through the ADM, not around it, with architecture-governed experimentation and explicit graduation criteria rather than innovation theatre that bypasses governance. In London, publication may benefit from service separation because its regulatory cadence is distinct, while OT telemetry should stay tightly coupled because its change rate is low and reliability is paramount.

Sustainability becomes architecture when it changes a real trade-off about workload, hosting, data retention, or operation. A streaming service that shifts heavy video transcoding to the hours and regions with cleaner power has made a carbon-aware design choice, because the system now behaves and consumes differently. The weak version is a strategy-level branding paragraph that never touches a concrete lever. If a sustainability claim never changes a decision, it is aspiration, not architecture.

Four working principles keep it practical: measure before you manage, proportionality, lifecycle design, and record where sustainability changed the decision. The carbon-aware design patterns give architects specific levers, demand shifting, demand shaping, right-sized retention, workload matching, and infrastructure efficiency. This working framework sits alongside G242, the Series Guide on environmentally sustainable information systems, and the record matters because the Architecture Board should be able to point at the design choices sustainability reasoning influenced.

Sustainability is one input to the trade-off, not a trump card. When sustainability and safety conflict, safety wins, and the same holds for resilience and governance obligations. In London, the telemetry pipeline, data retention policies, and batch processing schedules are concrete levers, and the public-value context of grid decarbonisation makes it a poor place for decorative claims.

Reference models give common language, comparability, and interoperability in regulated settings, and on the Enterprise Continuum they sit towards the generic end. A government department can borrow a national service-classification model for shared vocabulary while still designing its own benefits or tax systems to fit how it actually operates. The model earns its place by reducing argument about common structure, freeing effort for the local differences that genuinely matter. The TOGAF Government Reference Model (G21D) shows what shared public sector structure looks like.

The stage adds four practical recommendations for government and regulated sectors. Treat reference models as accelerators, test cross-organisation interoperability in practice rather than assuming it, keep accountability evidence local and specific, and expect multi-tier governance. Regulated-sector patterns, regulatory reporting, multi-regulator environments, OT governance, and cross-sector data exchange, tell the enterprise what to look for in a model before borrowing it.

The working discipline is the adopt, adapt, or resist framework, a deliberate recorded position on each reference-model element. Copying wholesale produces compliant-looking but hollow architecture, and the strongest test is blunt. Would removing the reference-model labels reveal a gap in the enterprise's own thinking? In London, CIM and the NCSC CAF should be adopted, cross-sector digital infrastructure models adapted for enterprise IT while local OT and telecom vocabulary is developed, and generic office-enterprise reference models resisted.

A technology gap names a missing capability or property, not a missing product. Saying a retailer lacks an event-streaming product is weak because it names a tool. Saying it cannot keep processing orders during a regional outage names the real capability gap, and that framing lets reviewers reason about cost, risk, and the target instead of debating a shopping list. A gap log written as an inventory of products the enterprise has not yet bought hides the reasoning, so the target cannot defend itself when challenged.

The C220 Part 2 gap analysis technique uses a baseline-target matrix, and the stage enriches it with consequence, constraints, and priority so comparison becomes architecture reasoning. Constraints matter because they reshape the option space, and four categories recur: operational, regulatory, skills, and time/migration pressure. Ignoring them produces wish lists. Trade-offs must also be explicit enough to survive Architecture Board review, because benefits-only records are not defensible and every option has weaknesses the board should see.

Architecture Decision Records in the Nygard format hold that reasoning: context, options, reasoning, consequences, and rationale. The point of the whole exercise is what it carries forward. Good gap analysis hands Stage 6 the consequence, dependency, and constraint information that roadmap sequencing needs, which is why the table matters far less than the quality of thinking it forces into view.

The walkthrough module synthesises every Stage 5 concept against London Grid Distribution: Phase D translation, controlled variance, security integration, microservice restraint, carbon-aware patterns, decision records, and adopt-adapt-resist thinking, applied to one enterprise at once. Its central finding is that resilience risk usually lives in the joins between OT, telecoms, IT, data, and governance, not inside any single domain, which is why specialist silos each miss it. Technology architecture proves its value when it surfaces the cross-domain dependency chains no silo can see individually.

The output that matters is a governance-ready view, one picture showing dependency chains, trust boundaries, recovery sequencing, and governance traceability together, so the Architecture Board can reason about the whole rather than approving fragments.

The walkthrough closes with five priority London gaps: OT/IT separation, telecom diversification, publication pipeline independence, cross-domain observability, and identity separation. Each carries enough consequence, constraint, and dependency detail to feed Stage 6 roadmap sequencing, which makes this module the stage's strongest bridge into the migration, governance, and capstone work later in the course.

Cloud is a Phase D technology decision, not a strategy of its own. A cloud target architecture is a normal Phase D output that must trace back to the business, information, and application work and feed roadmap components forward, exactly like any other technology choice in the stage. A landing zone is the pre-built, governed foundation that makes cloud adoption repeatable: a platform landing zone publishes five baselines, subscription and resource organisation, identity and access, network, security, and logging with governance, which application landing zones inherit rather than re-invent.

The shared responsibility model divides security of the cloud, the provider's infrastructure, from security in the cloud, the customer's identity, configuration, and data. Most cloud breaches happen on the customer side of that line, in misconfiguration the provider was never responsible for, and a landing zone is the enterprise doing its half once and by default. Well-architected pillars are balanced, not maximised, so the design should state per workload which pillar it favours and what it trades away, keeping the trade-off governable.

Because cloud spend follows usage, cost is a continuous decision rather than a procurement event. A FinOps posture, visibility, optimisation, and accountability tied to the landing zone's tenancy scopes, keeps the cost pillar honest over time. For London, moving the asset-data platform to a landing zone is defensible because the platform is analytical and off the operational control path, and every baseline, trade-off, and cost line is stated as evidence a regulator can follow.

London's Phase D work starts from three upstream decisions. The connections reform business case from Phase B demands customer self-service and workflow the platforms must carry. The LTDS publication obligation from Phase C demands that operational, planning, and analytical data combine and publish on a regulatory timetable without coupling publication to OT uptime. The OT/IT separation principle from the Preliminary Phase demands that operational technology recover independently of enterprise IT. Every module tested its concept against that inheritance, across an estate spanning OT, enterprise IT, publication, and telecom domains.

The walkthrough then showed where the danger concentrates, in the joins rather than the domains, and named the five priority gaps, OT/IT separation, telecom diversification, publication pipeline independence, cross-domain observability, and identity separation, each with the consequence and constraint detail Stage 6 needs. The cloud module closed the loop by moving the asset-data platform to a landing zone with every baseline, trade-off, and cost line stated as evidence a regulator can follow. Hold that pattern, because the scenario practice and the later stages keep returning to it.