Section 1: Phase D Overview
Phase D — Technology Architecture — is the fourth architecture domain phase in the ADM cycle, following Phase C (Information Systems Architecture). Its purpose is to develop the Target Technology Architecture describing the hardware, software, and network infrastructure needed to realise the Business, Data, and Application architecture components identified in Phases B and C.
The ADM phase that develops the Technology Architecture enabling the Business, Data, and Application architectures to be realised. It maps technology components to application components, identifies technology standards, and produces the Technology Architecture document as the primary deliverable.
Key Inputs and Outputs
| Category | Item |
|---|---|
| Input | Architecture Vision; Business Architecture (Phase B); Data & Application Architectures (Phase C) |
| Input | Technology Reference Model (TRM); Standards Information Base; Architecture Repository |
| Output | Technology Architecture document (primary deliverable) |
| Output | Updated Architecture Definition Document; Gap Analysis (Technology) |
| Output | Updated Architecture Repository (Standards Information Base updated) |
Phase D comes after Phase C and before Phase E. Technology Architecture enables (realises) the Business, Data, and Application architectures — technology serves the upper layers, not the reverse. Part 1 tests this directionality frequently.
Section 2: Technology Architecture Artefacts
TOGAF's Architecture Content Framework defines three categories of artefact for Phase D: catalogs, matrices, and diagrams. Every artefact name in the table below is testable in Part 1.
| Artefact Type | Artefact Name | Purpose |
|---|---|---|
| Catalog | Technology Standards Catalog | Lists approved technology standards (mandatory, recommended, emerging) that all projects must reference |
| Catalog | Technology Portfolio Catalog | Inventory of all technology components in use, including version, lifecycle status, and owner |
| Matrix | Application/Technology Matrix | Maps each application component (from Phase C) to the technology components that host or support it |
| Diagram | Environments and Locations Diagram | Shows which technology services are deployed in which physical or virtual environments and locations |
| Diagram | Platform Decomposition Diagram | Decomposes the technology platform into constituent services and layers; reflects the TRM structure |
| Diagram | Processing Diagram | Illustrates how data and processes flow through the technology infrastructure at runtime |
| Diagram | Networked Computing/Hardware Diagram | Shows the physical and logical network topology, servers, and hardware infrastructure |
| Diagram | Communications Engineering Diagram | Details communication links, protocols, bandwidth, and network engineering specifications |
Part 1 may ask how many catalogs, matrices, or diagrams Phase D produces. The answer: 2 catalogs, 1 matrix, 5 diagrams. The Application/Technology Matrix is the only matrix in Phase D. Environments and Locations is a diagram, not a matrix — a frequent trap.
Section 3: Technology Reference Model (TRM)
The Technology Reference Model (TRM) is TOGAF's Foundation Architecture for the technology domain. It provides a taxonomy and graphical model of all generic services and building blocks required to provide a technology platform. The TRM has exactly two components:
- Technical Reference Model: A taxonomy of platform services — the vocabulary used to classify and describe technology components. It provides a comprehensive and vendor-neutral classification of services any technology platform should provide.
- Standards Information Base (SIB): A database of open industry standards that can be used to realise the services defined in the taxonomy. The SIB maps recognised standards to the service categories.
TRM Layered Platform Diagram
TRM Service Qualities
Six service qualities apply across all TRM platform services as non-functional requirements: Availability (accessible when required), Manageability (ease of monitoring and administration), Performance (response time, throughput, capacity), Reliability (consistent function without failure), Security (protection from unauthorised access or modification), and Scalability (ability to handle growth). Mnemonic: AMPS-RS.
Section 4: Platform Services in Technology Architecture
TOGAF's TRM defines nine categories of platform service. These represent the functional building blocks any enterprise technology platform must provide to support the application layer above it. All nine names are testable in Part 1.
Section 5: Cloud Technology Architecture
Cloud computing is integral to modern enterprise technology architectures. TOGAF positions cloud service models within the TRM platform service taxonomy. Understanding how IaaS, PaaS, and SaaS map to TOGAF concepts is expected in both Part 1 and Part 2.
| Cloud Model | TRM Layer Replaced | Enterprise Still Manages |
|---|---|---|
| IaaS — Infrastructure as a Service | Communications Infrastructure; physical hardware and virtualisation | OS, middleware, data, applications, identity |
| PaaS — Platform as a Service | OS Services, Middleware Services, Software Engineering Services | Applications, data, configuration, identity |
| SaaS — Software as a Service | Business Application components (entire application stack) | Data governance, access management, configuration only |
Hybrid Cloud in Enterprise Architecture
Most enterprises adopt a hybrid cloud model. In Phase D the architect must define the cloud deployment model per component, address data sovereignty and residency constraints, apply interoperability standards (containers, APIs), reference cloud provider patterns (Azure Landing Zone, AWS Well-Architected) as Architecture Building Blocks, and ensure the Technology Architecture upholds portability principles to avoid lock-in.
Part 2 scenarios often present a cloud migration situation. The correct TOGAF approach starts from business requirements (Phase A/B), defines application and data requirements (Phase C), then selects cloud services as technology components in Phase D. Cloud is a delivery mechanism, not an architecture driver. Never select an answer that starts with the cloud model and works backward to the business.
Section 6: Standards Information Base (SIB)
The Standards Information Base (SIB) is a component of the Architecture Repository that catalogs the technology standards applicable to the enterprise. It is the second component of the TRM and is used in Phase D to guide technology selection and ensure compliance across the enterprise portfolio.
Standard Classification
| Classification | Definition | Key Governance Point |
|---|---|---|
| Mandatory | All projects must adopt; no deviation without Architecture Board dispensation | Compliance checked in Phase G |
| Recommended | Projects should adopt; deviation with documented justification allowed | Reviewed in architecture reviews |
| Emerging | Under evaluation; experimental adoption permitted with Architecture Board awareness | May be promoted to Recommended |
| Retiring | Being phased out; existing projects may retain, new projects must not adopt | Migration plan and cutoff date required |
Industry Standards Bodies
| Body | Domain | Example Standards |
|---|---|---|
| ISO | Quality, security, process | ISO 27001 (info security), ISO 9001 (quality), ISO 20000 (IT service mgmt) |
| IEEE | Networking, computing | IEEE 802.11 (Wi-Fi), IEEE 802.3 (Ethernet), IEEE 1471 (architecture description) |
| W3C | Web, data interchange | HTML5, XML, SOAP, REST, WCAG (web accessibility) |
| IETF | Internet protocols | TCP/IP (RFC 791), HTTP (RFC 9110), TLS (RFC 8446), DNS (RFC 1034) |
Standard Lifecycle: Selection and Retirement
Standards pass through a defined lifecycle: Selection (evaluated against openness, maturity, adoption, and architecture principles) → Ratification (Architecture Board assigns Emerging / Recommended / Mandatory classification) → Review (periodic, typically annual, with possible promotion or demotion) → Retirement (a migration plan identifies dependent systems and sets a cutoff timeline).
Section 7: Gap Analysis for Phase D
Gap Analysis in Phase D compares the Baseline Technology Architecture (current technology inventory) against the Target Technology Architecture (desired future technology state). The output feeds into Phase E to identify the work packages required to close the gaps.
| Gap Category | Description | Action Required |
|---|---|---|
| Eliminate | Technology in baseline not required in the target — retired platforms, legacy systems, redundant components | Decommission; plan migration for all dependent applications |
| Create | Technology required in target that does not exist in baseline — new platforms, cloud services, integration layers | Procure, build, or subscribe; include in Phase E work packages |
| Modify | Technology that exists in both baseline and target but must change — version upgrades, configuration, licensing | Plan upgrade or migration within existing project streams |
| Retain | Technology that exists in baseline and is carried unchanged to the target | Document; validate ongoing standards compliance; no further action |
Technology Rationalization
Technology rationalization is a key Phase D gap analysis outcome. Common patterns: platform consolidation (one approved database standard across environments), middleware consolidation (reducing to an enterprise-approved integration set), OS standardisation (two or three approved server images), and standards compliance remediation (identifying components non-compliant with mandatory SIB standards and scheduling remediation in the Architecture Roadmap).
For Part 2 scenarios describing an organisation with many legacy platforms wishing to modernise: legacy components not needed in the target are Eliminate; net-new capabilities are Create; retained components needing upgrade are Modify; unchanged components are Retain. Gap Analysis outputs feed Phase E, never Phase F directly.
Revision Summary — Chapter 06
- Phase D develops the Target Technology Architecture that enables Business, Data, and Application architectures to be realised; primary outputs are the Technology Architecture document, updated Architecture Repository, and Gap Analysis (Technology).
- Phase D artefacts: 2 catalogs (Technology Standards, Technology Portfolio), 1 matrix (Application/Technology), and 5 diagrams (Environments & Locations, Platform Decomposition, Processing, Networked Computing/Hardware, Communications Engineering).
- The TOGAF TRM has exactly two components: the Technical Reference Model (a vendor-neutral taxonomy of platform services) and the Standards Information Base (SIB), which maps open standards to those services.
- Nine TRM platform service categories — Data Interchange, Data Management, Graphics & Imaging, Middleware, Network Services, Operating System, Software Engineering, Transaction Processing, User Interface — all nine are Part 1 testable.
- Six TRM service qualities apply across all platform services: Availability, Manageability, Performance, Reliability, Security, and Scalability.
- Cloud models map to the TRM: IaaS replaces Communications Infrastructure; PaaS replaces OS/Middleware/Software Engineering services; SaaS replaces Business Application components entirely.
- The SIB classifies standards as Mandatory, Recommended, Emerging, or Retiring. Only mandatory standards require a formal Architecture Board dispensation when a project needs to deviate.
- Phase D Gap Analysis uses four categories — Eliminate, Create, Modify, Retain — to identify technology rationalization opportunities; outputs feed directly into Phase E work package identification.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. Architecture Repository and Architecture Principles
B. Platform Decomposition Diagram and Technology Standards Catalog
C. Technical Reference Model (taxonomy of platform services) and Standards Information Base
D. Technology Portfolio Catalog and Application/Technology Matrix
Explanation: Option C is correct. The TOGAF TRM has exactly two components: (1) the Technical Reference Model, which provides a taxonomy of platform services, and (2) the Standards Information Base (SIB), which maps open industry standards to those services. Options A, B, and D describe other TOGAF artefacts and repository components, not the two parts of the TRM itself.
A. Platform Decomposition Matrix
B. Application/Technology Matrix
C. Technology Standards Matrix
D. Environments and Locations Matrix
Explanation: Option B is correct. The Application/Technology Matrix is the sole matrix artefact in Phase D — it maps application components from Phase C to the technology components that support them. Platform Decomposition (A) and Environments and Locations (D) are diagrams, not matrices. There is no Technology Standards Matrix; the Technology Standards Catalog is a catalog artefact.
A. IaaS — Infrastructure as a Service
B. SaaS — Software as a Service
C. PaaS — Platform as a Service
D. On-premises private cloud
Explanation: Option C is correct. When the provider manages hardware, OS, runtime, and middleware — and the enterprise manages only applications and data — this describes Platform as a Service (PaaS). In TOGAF terms, PaaS replaces the OS Services, Middleware Services, and Software Engineering Services layers of the TRM. IaaS (A) covers only physical hardware and virtualisation; the enterprise still manages the OS upward. SaaS (B) includes the application itself, managed entirely by the provider.
A. Eliminate — these components should be decommissioned with migration plans for dependent applications
B. Retain — legacy systems should be documented and kept unchanged in the target
C. Modify — the databases should be upgraded to newer versions of the same product
D. Create — replacement databases must be procured and built as new components
Explanation: Option A is correct. Components that exist in the Baseline Architecture but are not required in the Target Architecture are classified as Eliminate. The architect must then plan decommission and migration activities for those components and their dependent applications. "Retain" (B) applies to components carried over unchanged. "Modify" (C) applies to components that persist but must change. "Create" (D) applies to net-new components needed in the target that have no baseline equivalent.
A. Reject the request — only mandatory standards may be adopted by projects
B. Allow the project to adopt the emerging standard experimentally, with Architecture Board awareness and monitoring
C. Require a formal dispensation, as any deviation from the SIB is a governance breach requiring Architecture Board approval
D. Immediately promote the standard to Recommended status to formally authorise its adoption
Explanation: Option B is correct. An "Emerging" standard is one the enterprise is actively evaluating. Projects may adopt emerging standards experimentally, but the Architecture Board should be kept aware so the adoption informs the standard's future promotion or retirement decision. Option A is wrong — emerging standards are not prohibited. Option C confuses an emerging standard with deviation from a mandatory standard, which requires dispensation. Option D is wrong — promotion follows the formal SIB lifecycle review process, not individual project requests.