Direct Answer
TOGAF Phase D produces the baseline and target technology architecture, a technology gap analysis, and updated roadmap components covering infrastructure change. In Sparx EA, you use the ArchiMate technology layer — nodes, devices, system software, networks, and cloud platform elements — to model the current and target infrastructure landscapes. Cloud target architectures for Azure, AWS, and GCP are modelled using node stereotypes in the ArchiMate technology layer, giving you a vendor-specific view that is still integrated with the vendor-agnostic application and data architecture layers above it. The technology gap analysis identifies platforms to retire, modernise, or replace and produces the decommission schedule that feeds migration planning. Phase D is also where EA GraphLink’s Interface A becomes applicable to the infrastructure layer — exposing technology topology data to Power BI for infrastructure portfolio management.
Phase D Deliverables
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. Phase D answers the question: “What technology platform do we need to run these applications and handle this data?”
Baseline Technology Architecture. The current-state infrastructure landscape: servers (physical and virtual), networks, operating systems, middleware, cloud services, and their relationships. In Sparx EA, this is a set of ArchiMate technology layer diagrams backed by a structured package of technology elements.
Target Technology Architecture. The future-state platform design: what the infrastructure looks like when the target application and data architecture runs on it. This typically involves cloud migration decisions, platform consolidations, and new infrastructure capabilities (e.g., container orchestration, data platforms, API gateway infrastructure).
Technology Gap Analysis. A structured comparison of baseline and target, with a disposition decision for each technology asset: retain, invest, migrate, replace, retire, or tolerate. The gap analysis feeds the decommission plan and the Phase E migration work packages.
Updated Architecture Roadmap. Phase D adds technology-layer work packages to the roadmap that Phase B and C initiated. Infrastructure changes have lead times — hardware procurement, cloud tenancy setup, network changes, security validation — that must be reflected in the roadmap sequence.
ArchiMate Technology Layer in Sparx EA
The ArchiMate technology layer has a richer vocabulary than most practitioners use. Key elements and their Sparx EA implementation:
Node. The fundamental technology element — represents a computational resource. In Sparx EA, use Node elements for physical servers, virtual machines, and cloud compute instances. Add tagged values for environment (Production/Non-Production), hostingmodel (On-Premises/IaaS/PaaS/SaaS), and platformowner.
Device. Physical hardware — data centre servers, network appliances, end-user devices. In Sparx EA, Device elements sit below Node elements in the technology hierarchy. Use Composition relationships to show which devices host which nodes.
System Software. Operating systems, middleware, database engines, application servers, container runtimes. In Sparx EA, model System Software elements within the node they run on using Composition relationships. This creates a complete stack view: Device → Node → System Software → Application Component (from Phase C layer).
Communication Network and Path. Network segments and their connectivity. In Sparx EA, model the DMZ, internal network, management network, and external internet as Communication Network elements. Use Communication Path relationships to show how nodes are connected.
Cloud Services. ArchiMate 3 introduced Technology Service as the abstraction for cloud services. In Sparx EA, 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 remains vendor-neutral.
Modeling Cloud Target Architectures
Cloud migrations are the most common Phase D scenario. The challenge is modeling a cloud target architecture that is specific enough to guide infrastructure decisions but abstract enough to remain an architecture artefact rather than a deployment script.
The recommended approach in Sparx EA:
- Create a
Target Technology Architecturepackage alongside theBaseline Technology Architecturepackage - Use Node stereotypes to represent cloud constructs:
<,> <,> <at the highest level> - Within each cloud account/subscription, model the key resource groupings:
<,> <,> <as sub-nodes> - Model platform services as Technology Service elements:
<,> <,> <> - Use Realisation relationships to connect Application Components (from Phase C) to the cloud Technology Services that host them
This produces a cloud architecture model that is integrated with the business and application architecture above it. When a business capability changes (Phase B), the impact traces through Phase C application components to Phase D cloud services. The full impact chain is visible in the model.
MDG Technology extensions for cloud can be configured in Sparx EA to add cloud-provider-specific stereotypes, tagged values, and diagram types. Sparx Services delivers these as part of the Deploy engagement.
Technology Gap Analysis and Decommission Planning
The technology gap analysis uses the same pattern as Phase B and C gap analyses. For each technology asset in the baseline:
- Assign a disposition: Retain / Invest / Migrate / Replace / Retire / Tolerate
- Link the disposition to the target technology element it maps to (or confirm there is no target equivalent for Retire decisions)
- Tag with
decommission_datefor assets with a Retire disposition - Tag with
migration_targetfor assets with a Migrate disposition - Estimate
decommissioncostandmigrationcostwhere known
The decommission schedule — sorted by decommission_date — is a directly useful output for 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 the infrastructure team’s tracking purposes, but keep the source of truth in the model.
Technology Architecture and Infrastructure Portfolio Management
Phase D produces the infrastructure equivalent of the application portfolio. With tagged values on technology layer elements, EA GraphLink Interface A (GraphQL → Power BI) can expose the technology portfolio to business intelligence tools.
Useful infrastructure portfolio metrics available from a well-tagged Phase D model:
- 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)
- Technology debt index — count of assets tagged Tolerate or Legacy
These are the metrics that make infrastructure conversations with executives productive. Instead of defending a maintenance budget, the infrastructure team can show a decommission trajectory and a cloud migration roadmap backed by architectural evidence.
Frequently Asked Questions
Q: How detailed should the baseline technology architecture be? A: Architecturally significant infrastructure only. The test: does this technology 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.
Q: How do we model multi-cloud architectures in Sparx EA? A: 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. The integration with the application layer is the same regardless of provider — Application Components from Phase C are realised by Technology Services from whichever cloud provider hosts them.
Q: Should Phase D include network security architecture? A: 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 security configuration (firewall rules, specific IAM policies) is engineering detail, not architecture. Model the security zone topology and the placement of security controls as ArchiMate technology elements.
Q: How does Phase D feed the Deploy engagement at Sparx Services? A: The Deploy engagement uses Phase D outputs as the infrastructure design brief. The target technology architecture diagram, cloud platform model, and decommission plan from Phase D are the inputs to infrastructure configuration, cloud landing zone setup, and migration sequencing. Phase D without a Deploy follow-through produces a good diagram; Phase D with Deploy produces a running platform.
Q: What happens when the target technology architecture is not yet decided (e.g., cloud provider not selected)? A: Model the technology architecture at the abstract level: “container platform” rather than “Azure Kubernetes Service.” Use a Technology Service element with a decision_status = Open tagged value. Record the options under consideration in the element notes. Phase D can approve the abstract target architecture with open decisions documented as Architecture Decision Records — the ADRs are resolved during Phase E as procurement decisions are made.
Q: How does EA GraphLink Interface B (MCP) apply to the technology layer? A: Interface B exposes the Sparx EA model to AI tools via the Model Context Protocol. With a well-structured technology layer, an AI assistant can answer questions like: “Which applications run on infrastructure that is scheduled for decommission in the next 12 months?” or “What is the technology stack of our payments platform?” These queries traverse the model from Technology Node through Application Component to Business Capability — possible only when all three layers are in the same model.
Next Step
Phase D produces the target technology architecture. Turning that architecture into a running platform is the Deploy engagement — cloud landing zone setup, infrastructure configuration, and the technical delivery that brings the Phase D design to life.
If your Phase D technology architecture needs to be connected to live analytics — infrastructure portfolio dashboards in Power BI, technology debt reports, decommission tracking — the Connect engagement delivers EA GraphLink Interface A configuration and the Power BI templates for technology layer reporting.
Deploy your technology architecture | Connect EA to Power BI
