TOGAF Phase D: Technology Architecture and Infrastructure Design

Every application runs somewhere. Every database is stored on something. Every API call travels across a network. Phase D Technology Architecture is where the enterprise architecture practice defines what that "somewhere" looks like: the hardware, cloud platforms, networks, middleware, and infrastructure standards that form the foundation everything else depends on.

Technology Architecture is the final core domain in the TOGAF ADM. By the time Phase D begins, the Business Architecture from Phase B has defined what the organization does, and Phase C has specified the applications and data models that support it. Phase D connects all of that to the physical and virtual infrastructure that makes it run.

What Technology Architecture Covers

Technology Architecture in TOGAF describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services.

More practically, it covers:

The infrastructure platforms the enterprise will use: on-premises data centres, public cloud, private cloud, or hybrid combinations
The technology standards approved for use across the enterprise
Network topology, connectivity, and security zones
Middleware and integration infrastructure
Security and resilience architecture
Operational capabilities: monitoring, backup, disaster recovery, and change management tooling

The Objectives of Phase D

Develop a Baseline Technology Architecture that documents the current infrastructure landscape
Develop a Target Technology Architecture that meets the requirements from Phases B and C
Perform a Gap Analysis between the two states
Identify candidate roadmap components to close technology gaps
Finalize the Architecture Requirements Specification for the technology domain

Like all other ADM phases, Phase D does not design technology for its own sake. Every infrastructure decision must trace back to an application or data requirement from Phase C, which in turn traces to a business capability from Phase B.

The Technology Standards Catalogue

The Technology Standards Catalogue is the foundational Phase D deliverable. It defines which technologies are approved for use across the enterprise, organized into categories.

A typical Technology Standards Catalogue covers:

Operating systems: Approved server and client operating systems (for example, RHEL Linux for servers, Windows 11 for workstations)
Database platforms: Approved relational and non-relational databases (for example, PostgreSQL, SQL Server, MongoDB)
Middleware and integration: Approved message brokers, API gateways, and integration platforms
Cloud platforms and services: Approved public cloud providers and specific managed services within them
Development frameworks and languages: Approved languages and frameworks for application development
Security tooling: Approved security products, identity platforms, and vulnerability management tools
Monitoring and operations: Approved observability, logging, and incident management platforms

Each entry in the catalogue has a status: Current (approved for use in new projects), Containment (still in use but not approved for new projects), Retirement (being actively phased out), or Emerging (under evaluation for future approval).

The Technology Standards Catalogue Lives in the Repository

The Technology Standards Catalogue is stored in the Standards Information Base (SIB) section of the Architecture Repository. It is maintained as a living document, reviewed regularly by the Architecture Board as new technologies emerge and old ones reach end of life.

Infrastructure Design Patterns

Phase D uses established infrastructure design patterns to guide the Target Technology Architecture. Understanding these patterns is essential for both the exam and real-world practice.

On-Premises Architecture

All compute, storage, and networking is owned and managed by the enterprise within its own facilities. This pattern offers maximum control but requires significant capital investment and operational expertise.

Cloud-Native Architecture

All infrastructure is consumed as managed services from one or more public cloud providers (AWS, Microsoft Azure, Google Cloud). This pattern offers elasticity, speed of provisioning, and reduced operational overhead, but requires a shift in skills and introduces cloud vendor dependency.

Hybrid Architecture

A combination of on-premises and cloud infrastructure, with workloads distributed based on cost, compliance, performance, and security requirements. Most large enterprises operate hybrid architectures during their cloud journey.

Multi-Cloud Architecture

The use of multiple public cloud providers, either to avoid vendor lock-in, to leverage best-of-breed services from different providers, or to meet geographic data residency requirements.

Edge Architecture

Processing capability is distributed to locations close to where data is generated, reducing latency. Common in manufacturing, retail, and IoT contexts where millisecond response times matter.

Network and Security Architecture in Phase D

Network architecture defines how the enterprise's systems connect to each other and to external parties. Phase D documents:

The network topology: which systems sit in which network zones
Security zone definitions: demilitarized zones, internal networks, management networks
Connectivity to external parties: internet, partner connections, regulatory reporting networks
WAN connectivity between locations: dedicated lines, SD-WAN, internet VPN
Cloud network architecture: VPCs, subnets, peering, and egress controls

Security architecture in Phase D defines the technical controls that protect the infrastructure:

Identity and Access Management (IAM): Who can access which systems and under what conditions
Network controls: Firewalls, Web Application Firewalls, DDoS protection
Encryption: Data in transit and data at rest encryption standards
Key management: How cryptographic keys are generated, stored, and rotated
Endpoint security: Protection for servers, workstations, and mobile devices
Security monitoring: SIEM platforms, intrusion detection, and security operations centre tooling

Security Must Be an Architecture Input, Not an Afterthought

Technology Architecture that treats security as a layer added after infrastructure is designed consistently produces weaker, more expensive security outcomes. TOGAF recommends that security requirements are defined early and drive infrastructure design decisions, not the reverse.

Resilience and Recovery Design

Technology Architecture must explicitly address how the enterprise will continue to operate when things go wrong. Phase D defines:

Availability targets: How much downtime each system can tolerate (expressed as percentages like 99.9% or 99.99% availability)
Recovery Time Objective (RTO): How quickly a system must be restored after a failure
Recovery Point Objective (RPO): How much data the enterprise can afford to lose in a failure (expressed as a time window)
Redundancy design: How critical systems are duplicated to eliminate single points of failure
Backup and restore: How data is backed up, how often, and how restore procedures are tested
Disaster recovery: What happens if an entire data centre or cloud region becomes unavailable

These requirements are derived from the application and business service criticality established in Phase C and Phase B respectively.

The Technology Portfolio Catalogue

Like Phase C's Application Portfolio Catalog, Phase D maintains a Technology Portfolio Catalogue of all infrastructure components. This includes physical servers, storage systems, network devices, SaaS subscriptions, cloud accounts, and infrastructure software.

Each component is documented with:

Vendor and product name
Version and license status
End of support / end of life dates
Applications and services that depend on it
Strategic disposition (retain, upgrade, replace, retire)

Managing technology lifecycle proactively is one of the most important outcomes of maintaining this catalogue. Organizations that do not track end-of-life dates consistently find themselves running unsupported, vulnerable systems.

Gap Analysis in Phase D

Phase D's Gap Analysis compares the Baseline and Target Technology Architectures to identify:

Technology gaps: capabilities required in the target that the baseline does not have (for example, no Kubernetes platform for cloud-native workloads)
Technology debt: components in the baseline that carry risk due to age, lack of support, or security vulnerability
Capability gaps: skills or operational processes the target requires that the organization does not currently have
Standards non-compliance: components in use that are outside the approved Technology Standards Catalogue

Phase D Deliverables

Catalogs

Technology Standards Catalogue (within Architecture Repository SIB)
Technology Portfolio Catalogue

Matrices

Application/Technology Matrix: Which applications run on which infrastructure components

Diagrams

Environments and Locations Diagram: Physical and virtual environments and their geographic locations
Platform Decomposition Diagram: Hierarchical breakdown of the technology platform
Processing Diagram: How workloads are processed across infrastructure components
Network Computing/Hardware Diagram: Physical or logical network topology

Real-World Example: Financial Services Cloud Migration

A major insurance company is migrating from a legacy on-premises data centre to a hybrid cloud architecture. Their Phase D work includes:

Target platform standards: AWS as primary cloud provider, with on-premises infrastructure retained for regulatory data-processing workloads that must remain in-country
Network architecture: AWS Direct Connect for private connectivity between on-premises and cloud. Separate VPCs for production, staging, and development environments. WAF in front of all customer-facing applications
Security design: AWS IAM with federated single sign-on via existing Microsoft Active Directory. All data encrypted at rest using AWS KMS. All traffic between services encrypted via TLS
Resilience: Claims processing systems require 99.99% availability. Multi-AZ deployment with automatic failover. RTO of 15 minutes, RPO of 1 hour for core systems
Technology gap identified: The IT team has no Kubernetes expertise. A training and recruitment plan is added to the Architecture Roadmap as a prerequisite for the cloud-native workload migration

Summary

Phase D Technology Architecture defines the infrastructure, platforms, networks, and standards that support every application and data asset in the enterprise.

Its core work includes:

Building and maintaining the Technology Standards Catalogue
Selecting infrastructure patterns (on-premises, cloud, hybrid)
Designing network and security architecture
Defining resilience and recovery requirements
Performing the Gap Analysis between baseline and target infrastructure

With Phase D complete, the four core architecture domains have been fully defined. The next stage of the ADM shifts from design to planning and implementation. The next post covers Phase E and F: Opportunities, Solutions, and Migration Planning, where the transition from the current state to the target state is carefully planned and sequenced.

This post is part of the TOGAF 9.2 Masterclass series on Topictrick. Review Phase C: Application Architecture and Phase C: Data Architecture for the context that drives Phase D decisions.