5.1 Phase D: Technology Architecture, Platform Services & Infrastructure

5.1 Phase D: Technology Architecture, Platform Services & Infrastructure

In the TOGAF Architecture Development Method (ADM), Phase D: Technology Architecture represents the domain where abstract application capabilities and enterprise data assets are grounded into concrete software infrastructure, compute platforms, physical networks, and cloud deployment environments. While Phase B defines what business functions are executed and Phase C defines what data and applications process those functions, Phase D establishes the fundamental technological underpinning required to run those applications securely, reliably, and at scale.

---

Primary Objectives of Phase D

The primary goals of ADM Phase D are:

1. Develop the Target Technology Architecture that enables the logical Application and Data Architecture components defined in Phase C and aligns with the strategic vision of Phase A.
2. Identify Candidate Architecture Roadmap Components based upon gaps identified between the Baseline and Target Technology Architectures.
3. Define Technology Standards and Guidelines to govern the procurement, operation, and lifecycle management of hardware, platforms, runtime engines, and networking infrastructure.
4. Structure Infrastructure Deployment Models across on-premises data centers, public cloud providers (IaaS/PaaS/SaaS), edge environments, and hybrid cloud architectures.

---

ADM Execution Steps in Phase D

Executing Phase D involves a structured 9-step progression aligned with the universal ADM domain pattern:

1. Select Reference Models, Viewpoints, and Tools: Choose appropriate technology reference models (such as the TOGAF Technical Reference Model), infrastructure modeling notations (e.g., ArchiMate Technology Layer), and automated deployment modeling tools.
2. Develop Baseline Technology Architecture Description: Document existing server assets, platform services, network topologies, storage systems, and vendor software licenses currently active across the enterprise.
3. Develop Target Technology Architecture Description: Design the future-state technology portfolio, incorporating modern container platforms, cloud-native services, serverless execution environments, and zero-trust network boundaries.
4. Perform Gap Analysis: Compare Baseline vs. Target Technology Architectures to identify missing technology capabilities, hardware end-of-life risks, unsupported operating systems, and platform integration gaps.
5. Define Candidate Roadmap Components: Group technology gap resolutions into potential technology migration work packages.
6. Resolve Impacts Across the Architecture Landscape: Determine whether new technology components (e.g., introducing a global Kubernetes cluster or service mesh) require updates to security baselines, operations, or application software architectures.
7. Conduct Formal Stakeholder Review: Review proposed technology standards and deployment topologies with infrastructure engineers, security officers, and cloud operations teams.
8. Finalize the Technology Architecture: Secure sign-off from the Architecture Review Board (ARB) and publish the Technology Architecture deliverables.
9. Create Architecture Definition Document: Package the Technology Architecture models, catalogs, matrices, and diagrams into the master ADD.

---

Logical vs. Physical Technology Components

A critical concept in TOGAF Technology Architecture is the clear conceptual boundary between Logical Technology Components (LTC) and Physical Technology Components (PTC).

Logical Technology Components (LTC)

An LTC is an abstract, vendor-neutral classification of a software or hardware platform capability. It specifies what function the technology performs without naming specific commercial software products or vendors.

• Examples: Enterprise Relational Database Management System (RDBMS), API Gateway, Distributed Message Broker, Container Orchestration Platform, Storage Area Network (SAN).

Physical Technology Components (PTC)

A PTC is the concrete, real-world realization of a logical technology component. It specifies vendor names, software release versions, commercial product titles, hardware models, or specific cloud instances.

• Examples: PostgreSQL 15.2 running on AWS RDS Multi-AZ, Kong Enterprise API Gateway v3.4, Apache Kafka 3.5 deployed on EC2, Red Hat OpenShift v4.12, Dell PowerScale F600 All-Flash Array.

Maintaining this distinction enables enterprise architects to build flexible Target Architectures that survive individual product deprecations or vendor acquisition cycles.

---

The TOGAF Technical Reference Model (TRM)

To ensure consistency across enterprise deployments, TOGAF Phase D utilizes the Technical Reference Model (TRM)—a foundational architectural taxonomy that categorizes platform services into logical layers.

+-------------------------------------------------------------------------+
|                         APPLICATION SOFTWARE                            |
+-------------------------------------------------------------------------+
|                   Application Platform Interface (API)                  |
+-------------------------------------------------------------------------+
|                          APPLICATION PLATFORM                           |
|  - Software Engineering Services      - Security Services               |
|  - Data Management Services           - System & Network Management     |
|  - Operating System Services          - User Interface Services         |
|  - Communication Infrastructure Svc   - Transaction Processing Services |
+-------------------------------------------------------------------------+
|                Communications Infrastructure Interface (CII)             |
+-------------------------------------------------------------------------+
|                      COMMUNICATIONS INFRASTRUCTURE                      |
|  - Network Hardware / Cabling        - Routers, Switches & Firewalls    |
|  - Transmission Media & Protocols    - Cloud VPC Networking & SD-WAN   |
+-------------------------------------------------------------------------+

The TRM establishes a universal vocabulary for infrastructure architects, categorizing services into three main structural zones:

1. Application Software: Business-specific applications and enterprise applications (e.g., ERP, CRM, custom microservices).
2. Application Platform: The rich set of infrastructure and middleware services made accessible to applications via standardized APIs (e.g., OS runtimes, database services, authentication tokens, directory services).
3. Communications Infrastructure: The physical and software-defined network conduits that interconnect systems across local networks, wide area networks, and multi-cloud backbones.

---

Core Phase D Deliverables and Artifacts

Phase D produces specific catalogs, matrices, and diagrams designed to govern technology implementation:

• Technology Standards Catalog: The authoritative enterprise registry detailing approved hardware models, operating systems, database engines, language runtimes, and open-source libraries. It defines product lifecycles (e.g., Approved, Emerging, Retiring, Prohibited) to prevent unmanaged technical debt.
• Technology Portfolio Catalog: A complete operational inventory of all physical hardware, cloud instances, network appliances, and software platform licenses currently deployed across data centers and cloud regions.
• Application / Technology Matrix: A cross-domain matrix mapping application components (from Phase C) to the logical and physical technology platforms on which they are hosted. This matrix reveals platform dependencies, single points of failure, and opportunities for host consolidation.
• Environments and Locations Diagram: A physical architecture diagram detailing where systems are hosted across data center facilities, cloud availability zones, edge compute nodes, and operational field offices. It illustrates development, staging, production, and disaster recovery (DR) environments.