Insight · TOGAF ADM

TOGAF Phase D: Technology Architecture in Sparx EA — Infrastructure, Cloud and Platforms

By Sparx Services · December 18, 2025

The short version: TOGAF TOGAF Phase D produces the baseline and target technology architecture, a technology gap analysis, and the roadmap components that cover infrastructure change. You build it on the ArchiMate technology layer — nodes, devices, system software, networks, and cloud platform services — to model the current and target landscapes. The gap analysis identifies what to retire, modernize, or replace, and produces the decommission schedule that drives migration planning.

Phase D is the most concrete of the ADM phases. By this point the business architecture (Phase B) and information systems architecture (Phase C) are approved, and Phase D answers one question: what technology platform do we need to run these applications and handle this data?

Phase D deliverables

Output 01

Baseline technology architecture

The current-state infrastructure: physical and virtual servers, networks, operating systems, middleware, cloud services, and their relationships — a structured package of ArchiMate technology elements, not a Visio sketch.

Output 02

Target technology architecture

The future-state platform: what the infrastructure looks like when the target application and data architecture runs on it. Usually cloud migration decisions, platform consolidations, and new capabilities like container orchestration or API-gateway infrastructure.

Output 03

Technology gap analysis

A baseline-to-target comparison with a disposition for each asset: retain, invest, migrate, replace, retire, or tolerate. It feeds the decommission plan and the Phase E migration work packages.

Output 04

Updated architecture roadmap

Technology-layer work packages added to the roadmap Phases B and C began. Infrastructure has lead times — procurement, tenancy setup, network changes, security validation — that have to shape the sequence.

The ArchiMate technology layer in Sparx EA

The ArchiMate technology layer has a richer vocabulary than most practitioners use. The key elements and their Sparx EA implementation:

Node. The fundamental technology element — a computational resource. Use Node elements for physical servers, virtual machines, and cloud compute instances. Add tagged values for environment (Production/Non-Production), hosting_model (On-Premises/IaaS/PaaS/SaaS), and platform_owner.

Device. Physical hardware — data-center servers, network appliances, end-user devices. Device elements sit below Node elements; use Composition relationships to show which devices host which nodes.

System Software. Operating systems, middleware, database engines, application servers, container runtimes. Model these within the node they run on using Composition relationships, producing a complete stack view: Device → Node → System Software → Application Component (from the Phase C layer).

Communication Network and Path. Model the DMZ, internal network, management network, and external internet as Communication Network elements, and use Communication Path relationships to show how nodes connect.

Technology Service. ArchiMate 3 introduced Technology Service as the abstraction for cloud services. Model AWS EC2, Azure App Service, or GCP Cloud Run as Technology Service elements with a cloud_provider tagged value. This keeps the model vendor-aware at the technology layer while the application layer above stays vendor-neutral.

Modeling a cloud target architecture, step by step

Cloud migrations are the most common Phase D scenario. The challenge is a target model that is specific enough to guide infrastructure decisions but abstract enough to stay an architecture artifact rather than a deployment script.

Separate baseline from target

Create a Target Technology Architecture package alongside the Baseline Technology Architecture package. Keeping the two distinct is what makes the gap analysis possible.

Model the cloud account hierarchy

Use Node stereotypes for the top-level constructs — <<AzureSubscription>>, <<AWSAccount>>, <<GCPProject>> — then model resource groupings (<<AzureResourceGroup>>, <<AWSVPC>>) as sub-nodes.

Add platform services

Model managed services as Technology Service elements: <<AzureKubernetesService>>, <<AWSRDSInstance>>, <<GCPCloudStorage>>. This is the level that guides decisions without drifting into deployment config.

Connect to the application layer

Use Realization relationships to connect Application Components (from Phase C) to the cloud Technology Services that host them. Now a Phase B capability change traces through Phase C components to Phase D services — the full impact chain is visible in one model.

An MDG Technology extension can add cloud-provider-specific stereotypes, tagged values, and diagram types to Sparx EA. Sparx Services configures these when helping you build the practice.

Gap analysis and decommission planning

The technology gap analysis follows the same pattern as Phases B and C. For each technology asset in the baseline:

Assign a disposition: Retain / Invest / Migrate / Replace / Retire / Tolerate.
Link the disposition to the target element it maps to (or confirm there is no target equivalent for Retire decisions).
Tag decommission_date for Retire assets and migration_target for Migrate assets.
Estimate decommission_cost and migration_cost where known.

The decommission schedule — sorted by decommission_date — is directly useful to the infrastructure team. It tells them what to turn off and when, with the architectural justification (which target technology replaces it) preserved in the model. In Sparx EA this is a SQL report or a model search result; export to Excel for tracking, but keep the source of truth in the model.

Instead of defending a maintenance budget, the infrastructure team can show a decommission trajectory and a cloud migration roadmap backed by architectural evidence.

Technology architecture as a live portfolio

Phase D produces the infrastructure equivalent of the application portfolio. With tagged values on the technology-layer elements, the same data can drive a live Power BI dashboard. The metrics that make infrastructure conversations with executives productive include:

Infrastructure asset count by hosting model — on-premises vs. cloud vs. hybrid
Assets by lifecycle status and planned decommission date
Cloud spend by provider and service type, when cost tagged values are populated
A technology-debt index — the count of assets tagged Tolerate or Legacy

How detailed should the baseline technology architecture be?

Architecturally significant infrastructure only. The test: does this element host a business-critical application, represent a significant cost, create a technology risk, or affect security posture? If yes, model it. Individual developer laptops are not Phase D material. A typical enterprise technology architecture has 50–200 significant infrastructure elements — not thousands.

How do we model multi-cloud architectures in Sparx EA?

Use a single Technology Architecture package with sub-packages per cloud provider. At the top level, model the cloud connectivity (ExpressRoute, Direct Connect, Interconnect) as Communication Path elements. Within each provider sub-package, use provider-specific node stereotypes. Integration with the application layer is the same regardless of provider — Application Components from Phase C are realized by Technology Services from whichever cloud hosts them.

Should Phase D include network security architecture?

Yes, at the architecture level. Security zones (DMZ, trusted internal, management), firewall positions, identity-and-access-management platform architecture, and encryption points are all Phase D concerns. Implementation-level configuration — firewall rules, specific IAM policies — is engineering detail. Model the security-zone topology and the placement of controls as ArchiMate technology elements.

What if the target architecture is not yet decided — e.g. the cloud provider is unselected?

Model at the abstract level: "container platform" rather than "Azure Kubernetes Service." Use a Technology Service element with a decision_status = Open tagged value and record the options in the element notes. Phase D can approve the abstract target with open decisions documented as Architecture Decision Records, resolved during Phase E as procurement decisions are made.

Can an AI assistant query the technology layer?

Yes — through the Model Context Protocol. Sparx EA core has no built-in MCP server, but two paid products supply one: a read-only server deployed for enterprise-wide access, and a local server that adds full read/write plus diagram validation through the EA interface. With a well-structured technology layer, an assistant can answer questions like "which applications run on infrastructure scheduled for decommission in the next 12 months?" — traversing from Technology Node through Application Component to Business Capability, which only works when all three layers live in one model. These tools are new in 2026, so treat them as an emerging capability rather than a long-established one.

From target architecture to a running platform

Phase D produces the target technology architecture. Turning it into a running platform means cloud landing-zone setup, infrastructure configuration, and the technical delivery that brings the design to life — and connecting it to live analytics so the portfolio, technology-debt, and decommission views stay current. That integration layer is what AI Power Tools for EA provides, and it sits naturally alongside the wider AI Augmented Architecture practice.

Turn your target technology architecture into a running platform.

Talk to a practitioner about modeling your infrastructure and cloud target in Sparx EA — and the delivery work that follows.

Book a call →

Keep reading