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

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 estates. 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?

For an architect, Phase D is where design choices meet infrastructure reality: cloud decisions, platform consolidation and what to retire. Today the architect builds the baseline and target technology models by hand and collects asset details from infrastructure teams. The AI-augmented way is to state the platform decisions and dispositions, let AI build and link the technology models, and bring in the asset facts that other systems already hold. The skill is making the platform and disposition decisions clearly and checking that hosting relationships in the model mean what they should.

Phase D deliverables

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) and hosting_model (On-Premises/IaaS/PaaS/SaaS). Owner, lifecycle and cost facts are held by other systems, and AI-augmented work connects them to the model instead of typing them in.

Device. Physical hardware: data-center servers, network appliances, end-user devices. Device elements are physical hardware; use Composition to show which devices a node is composed of.

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 Path elements to show how nodes connect.

Technology Service. Technology Service represents externally visible technology functionality, which suits cloud platform 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.

An MDG Technology extension can add cloud-provider-specific stereotypes, tagged values, and diagram types to Sparx EA. We can help you configure these as part of building 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:

1. Assign a disposition: Retain / Invest / Migrate / Replace / Retire / Tolerate.
2. Link the disposition to the target element it maps to (or confirm there is no target equivalent for Retire decisions).
3. Tag decommission_date for Retire assets, and link Migrate assets to their target element by relationship.
4. Bring in cost estimates from your financial management systems where known, rather than typing them into the model.

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 portfolio

Phase D produces the infrastructure equivalent of the application portfolio. With the technology layer modeled and connected to the systems that hold asset data, the same data can drive a Prolaborate or Power BI dashboard (see reporting and Power BI). The metrics that make infrastructure conversations with executives productive include:

• Infrastructure asset count by hosting model, on-premises versus cloud versus hybrid
• Assets by lifecycle status and planned decommission date
• Cloud spend by provider and service type, when cost data is connected from billing and financial management systems
• A technology-debt index, the count of assets tagged Tolerate or Legacy

Frequently asked questions

What this means for the architect

Phase D produces the target technology architecture. Connecting it to analytics and AI tools makes the portfolio, technology-debt, and decommission views queryable, and which tools help depends on the job: AI tools for Sparx EA compares the options, and they sit alongside the wider AI-Augmented Architecture practice. For a migration, see cloud migration, AI-augmented. The architect's part is the platform and disposition decisions, and the review of what AI builds.