5.3 Phase D: Technology Architecture
Key Takeaways
- Phase D develops the Target Technology Architecture that enables business, data, and application building blocks to be delivered through technology components and technology services.
- Phase D identifies candidate Architecture Roadmap components based on gaps between the Baseline and Target Technology Architectures.
- TOGAF defines a technology service as a technical capability required to provide enabling infrastructure that supports the delivery of applications.
- The Standards Library, called the Standards Information Base in TOGAF 9, captures the standards new architectures must comply with.
- Phase D outputs include a draft Architecture Definition Document, a draft Architecture Requirements Specification, and Technology Architecture roadmap components.
5.3 Phase D: Technology Architecture
Phase D develops the Technology Architecture that supports the agreed Architecture Vision. The Foundation syllabus asks you to describe the objectives of Phase D.
Objectives of Phase D
- Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
The glossary definitions behind the objectives:
- Technology Architecture — a description of the structure and interaction of the technology services and technology components
- Technology Service — a technical capability required to provide enabling infrastructure that supports the delivery of applications
- Technology Component — a technology building block: a generic infrastructure technology that supports and enables application or data components by providing technology services; or an encapsulation of technology infrastructure representing a class of technology product or a specific product
The 10th Edition's core concepts describe Technology Architecture broadly: the digital architecture and the logical software and hardware infrastructure capabilities and standards needed for business, data, and application services — including digital services, IoT, social media infrastructure, cloud services, IT infrastructure, middleware, networks, communications, processing, and standards. The Phase D approach also calls for attention to emerging technologies, which may create new business opportunities as well as constraints.
Steps of Phase D
- Select Reference Models, Viewpoints, and Tools
- Develop Baseline Technology Architecture Description
- Develop Target Technology Architecture Description
- Perform Gap Analysis
- Define Candidate Roadmap Components
- Resolve Impacts Across the Architecture Landscape
- Conduct Formal Stakeholder Review
- Finalize the Technology Architecture
- Create/Update the Architecture Definition Document
Core Technology Architecture Elements
1. Compute, Storage, and Virtualization Platforms
Technology architects define compute and storage profiles based on workload demands:
- Compute: Sizing and architectural patterns for bare-metal physical servers, hypervisor-based virtual machines (VMs), container runtimes, and event-driven serverless compute platforms.
- Storage Architectures: Categorizing storage into high-performance block storage (SAN/NVMe for transaction databases), scale-out file storage (NAS), and globally distributed object storage (S3-compatible tiers for unstructured data, logs, and backups).
2. Cloud Service Models and Shared Responsibility
Modern Phase D architectures heavily integrate cloud computing paradigms. Architects must navigate the Cloud Shared Responsibility Model:
| Cloud Service Model | Architecture Scope Managed by Cloud Provider | Architecture Scope Governed by Enterprise Architect in Phase D |
|---|---|---|
| Infrastructure as a Service (IaaS) | Physical data centers, server hardware, power/cooling, hypervisor virtualization. | Operating system selection, patch management, network subnets, firewalls, middleware, data encryption, and application runtimes. |
| Platform as a Service (PaaS) | Physical hardware, virtualization, OS, database engine provisioning, container runtime maintenance. | Database schema design, API gateway configuration, identity access policies, network interconnects, and application code deployment. |
| Software as a Service (SaaS) | Complete technical infrastructure, operating systems, application code, high availability, and platform upgrades. | Identity federation, data classification and export policies, interface integration contracts (Phase C), and SLA compliance monitoring. |
3. Networking, Connectivity, and Zero-Trust Perimeters
Network architecture establishes how distributed components communicate securely and efficiently:
- Software-Defined Networking (SDN): Programmable, decoupled network fabrics that automate routing, load balancing, and network micro-segmentation.
- Enterprise Connectivity: Structuring corporate WANs using Software-Defined WAN (SD-WAN), low-latency dedicated cloud interconnects (e.g., AWS Direct Connect, Azure ExpressRoute), and content delivery networks (CDNs).
- Zero-Trust Security Perimeters: Replacing obsolete "castle-and-moat" perimeter security with identity-aware micro-segmentation, mutual TLS (mTLS) encryption for all inter-service communications, and continuous verification.
4. Operating Environments, Middleware, and Container Orchestration
Phase D standardizes the intermediate runtime layers that host software applications:
- Container Orchestration: Defining enterprise Kubernetes architectures, ingress controllers, service meshes (e.g., Istio), and GitOps-driven deployment agents.
- Middleware and Event Streaming: Platform specifications for enterprise message brokers, distributed event logs, and API gateways.
- Operating Systems: Standardizing certified enterprise Linux and Windows distributions, enforcing standardized base container images.
5. Physical and Logical Deployment Topologies
Architects model how systems are physically deployed across geographies to guarantee resilience:
- Availability Zones (AZs): Deploying across isolated data centers within a single geographic region to ensure zero-downtime automated failover.
- Multi-Region Topologies: Architecting active-passive or active-active cross-region configurations to support disaster recovery objectives, including Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
- Edge Computing: Placing lightweight compute nodes physically adjacent to retail stores, manufacturing factory floors, or IoT sensor grids to minimize latency.
Technology Standards and the Standards Library
Phase D relies heavily on the Standards Library in the Architecture Repository (called the Standards Information Base in TOGAF 9.x). It captures the standards with which new architectures must comply — industry standards, selected products and services from suppliers, and shared services already deployed. In Phase D architects:
- Check whether an existing standard or shared service already meets a requirement before introducing something new
- Identify where a new standard is needed and take it through the enterprise's governance process
- Record technology standards decisions so that implementation projects can be held to them through Architecture Contracts and compliance reviews in Phase G
Keeping a governed set of standards prevents technology proliferation — for example, five teams independently introducing five different message brokers.
Architecture Building Blocks (ABBs) vs. Solution Building Blocks (SBBs)
A fundamental TOGAF exam topic is the distinction between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) in Phase D:
| Characteristic | Architecture Building Block (ABB) | Solution Building Block (SBB) |
|---|---|---|
| Core Nature | A logical, vendor-neutral specification of a required technical service and its interfaces. | A concrete, physical product, appliance, commercial SKU, or vendor-specific service. |
| Focus | Defines what capability and quality attributes are required (requirements-driven). | Defines how and with what specific product the capability is realized (procurement-driven). |
| Phase Focus | Defined in the architecture definition phases, including Phase D. | Candidate SBBs identified and grouped in Phase E; delivered through Phases F and G. |
| Enterprise Examples | • "Managed Relational Database Service"<br/>• "High-Throughput Distributed Message Bus"<br/>• "Cloud-Native Container Orchestration Platform" | • "Amazon RDS PostgreSQL 16 Multi-AZ"<br/>• "Apache Kafka Cluster on Red Hat AMQ Streams"<br/>• "Red Hat OpenShift Platform Plus on AWS" |
Why Phase D Emphasizes ABBs
Novice architects often make the mistake of immediately selecting vendor brand names during architecture definition. Defining ABBs before choosing SBBs is valuable because:
- It ensures platform decisions are driven strictly by business and technical requirements rather than aggressive vendor sales pitches.
- It preserves organizational flexibility, preventing premature vendor lock-in.
- It provides an objective evaluation matrix against which candidate SBBs can be scored during Phase E Opportunities and Solutions.
Baseline vs. Target Technology Architectures & Gap Analysis
Phase D systematically bridges the current physical estate with the desired future platform through Technology Gap Analysis:
| Infrastructure Element | Baseline Technology Architecture | Target Technology Architecture | Gap Description | Architectural Action |
|---|---|---|---|---|
| Database Hosting | On-prem bare-metal servers; end-of-support Oracle 11g; manual backups | Multi-AZ Managed PostgreSQL PaaS; automated point-in-time recovery | Obsolete / Unsupported | Retire on-prem database hardware; migrate schemas to cloud PaaS database |
| Application Runtime | Monolithic VM instances per app; manual shell script deployments | Elastic Kubernetes container platform with automated GitOps pipelines | Missing / Inefficient | Commission container platform ABB; containerize application workloads |
| Network Security | Static perimeter firewall; unencrypted internal subnet traffic | Zero-Trust architecture with mutual TLS (mTLS) and micro-segmentation | Vulnerability Gap | Deploy enterprise service mesh and identity-aware proxy perimeters |
| Disaster Recovery | Active-Cold secondary site; RTO = 36 hours, RPO = 24 hours | Active-Warm multi-region deployment; RTO < 15 minutes, RPO < 5 seconds | SLA Non-Compliance | Provision multi-region asynchronous database replication and global traffic routing |
Realistic Enterprise Scenario: PulseHealth SaaS Platform
PulseHealth, an innovative digital healthcare SaaS provider managing electronic medical records (EMR) for 15 million patients, experienced 400% annual customer growth. However, their technology infrastructure was on the brink of collapse: systems were hosted in a private colocation facility on aging physical blade servers, provisioning new compute nodes took six weeks of procurement delay, database failover required four hours of manual intervention, and impending international expansion required strict compliance with European health data sovereignty laws.
During Phase D, the enterprise architecture team conducted the following:
- Defined Technology ABBs: Formulated vendor-neutral specifications for "Zero-Trust Container Orchestration Platform", "Encrypted-at-Rest Distributed Storage Service", and "Multi-Region High-Availability Database Engine".
- Applied the Standards Library: Recorded the on-premises SAN storage hardware as a technology to be phased out and adopted managed Kubernetes conforming to Cloud Native Computing Foundation (CNCF) conformance as the approved platform standard.
- Architected Multi-Region Cloud Deployment: Designed an active-active cloud topology across two domestic availability zones with an asynchronous disaster recovery replica in Europe, satisfying strict regulatory residency mandates.
- Formulated Candidate Work Packages: Generated core infrastructure components for Phase E: "Cloud Infrastructure Foundation & Landing Zone Setup", "Legacy Colocation Decommissioning & Data Migration", and "Zero-Trust Network Perimeter Modernization".
Inputs and Outputs of Phase D
| Key inputs | Outputs |
|---|---|
| Request for Architecture Work; Capability Assessment; Communications Plan | Refined and updated Phase A, B, and C deliverables where applicable |
| Approved Statement of Architecture Work; Architecture Principles (including technology principles, where they exist) | Draft Architecture Definition Document with Baseline and Target Technology Architecture descriptions and views |
| Architecture Vision; draft ADD and ARS from Phases B and C | Draft Architecture Requirements Specification, including gap analysis results, requirements output from Phases B and C, and updated technology requirements |
| Business, Data, and Application Architecture components of the Architecture Roadmap | Technology Architecture components of an Architecture Roadmap |
| Architecture Repository, including the Standards Library and technology reference models |
Common Exam Pitfalls
- Quoting only half the objective. Phase D delivers target business, data, and application building blocks through technology components and technology services.
- Using the old repository name only. The 10th Edition calls it the Standards Library.
- Committing to products too early. Phase D works mainly with architecture building blocks; candidate solution building blocks are identified and grouped in Phase E.
- Forgetting candidate roadmap components. Like B and C, Phase D identifies candidate roadmap components from technology gaps.
Which statement matches the first objective of Phase D: Technology Architecture?
In the TOGAF Standard, 10th Edition, what is the Architecture Repository component called that captures the standards new architectures must comply with?
How does the TOGAF glossary define a technology service?
Why is it valuable to define Architecture Building Blocks before selecting Solution Building Blocks in technology architecture work?