Study guide
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles
Key Takeaways Explain This Topic AI
Phase D Technology Architecture defines the infrastructure software, hardware platforms, communications networks, and multi-cloud landing zones required to support the deployment of application and data components (Phase C).
Technology principles—such as Technology Independence, Standards-Based Architecture, Interoperability, and Vendor Portability—govern procurement, platform engineering, and infrastructure modernization decisions.
Modern enterprise platform architectures span across public cloud, private cloud, hybrid, and edge topologies, requiring clear governance of responsibility boundaries across IaaS, PaaS, SaaS, and serverless execution models.
Cloud landing zones establish foundational architectural guardrails—encompassing identity federation, virtual network segmentation, encryption policies, and automated compliance policies—prior to workload migrations.
In the TOGAF Architecture Development Method (ADM), Phase D serves as the physical and virtual infrastructure foundation, translating logical application services and data persistence requirements into operational runtime environments.
Last updated: October 2026
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles
Phase D of the TOGAF Architecture Development Method (ADM) addresses Technology Architecture , the fourth and final core architecture domain in the Phase B-C-D sequence. While Phase B defines the business capabilities and value streams, and Phase C establishes the data entities and application services that automate those capabilities, Phase D defines the physical, virtual, and cloud infrastructure required to execute the application and data components. In contemporary enterprise IT, where infrastructure has evolved from static physical data centers to dynamic multi-cloud fabrics, containerized microservices, and serverless platforms, Phase D provides the architectural governance and engineering discipline necessary to build resilient, cost-effective, and secure digital foundations.
Objectives of Phase D Technology Architecture
The primary purpose of Phase D is to develop the Target Technology Architecture that enables the logical and physical application and data components defined in Phase C to operate effectively, while managing technical debt and infrastructure obsolescence. TOGAF states two objectives for Phase D: develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns; and identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures. In practice the work involves:
Develop the Target Technology Architecture : Define the technology building blocks (computing hardware, operating systems, virtualization platforms, container runtimes, network fabrics, storage arrays, cloud services, and physical facilities) required to support the target application and data portfolios.
Determine the Architecture Sequencing Approach : Decide whether to model the Baseline Technology Architecture first or formulate the Target Technology Architecture first, based on operational risks, technical debt, and business urgency.
Identify Candidate Architecture Roadmap Components : Analyze the delta between baseline infrastructure and target technology solutions to generate candidate work packages (e.g., cloud migrations, data center consolidations, network upgrades) for downstream synthesis in Phase E (Opportunities and Solutions).
Resolve Cross-Domain Impacts : Assess the technical, operational, and financial impacts of technology choices on Business Architecture (e.g., operational costs and business continuity) and Information Systems Architectures (e.g., application refactoring requirements and data replication latency).
Traceability: Supporting Business and Information Systems Architectures
A foundational tenet of enterprise architecture is vertical traceability . Technology Architecture cannot be designed in an operational silo; it exists exclusively to deliver the non-functional and operational requirements of upstream architecture domains.
Enterprise architects establish explicit traceability links across the ADM domains:
Business Architecture (Phase B) establishes business capabilities, critical operational periods, regulatory compliance mandates (such as GDPR, HIPAA, or PCI-DSS), and business continuity objectives (Maximum Tolerable Downtime).
Information Systems Architectures (Phase C) translate these business requirements into Application Building Blocks (e.g., Transaction Processing Engine, Customer Portal) and data components (e.g., Master Customer Record, Financial Transaction Ledger), specifying transactional throughput, data volume, and read/write access patterns.
Technology Architecture (Phase D) realizes these requirements by provisioning compute clusters with appropriate CPU/memory ratios, high-performance NVMe storage with synchronous replication, software-defined networks with micro-segmentation, and multi-region failover topologies.
When an infrastructure team procures specialized hardware or commits to a proprietary cloud vendor platform without demonstrating direct traceability to Phase B business capabilities or Phase C application requirements, they introduce architectural friction, unneeded capital expenditure, and operational risk.
Formulating Enterprise Technology Principles
Technology principles provide the enduring rules and architectural guardrails that govern the procurement, deployment, and lifecycle management of infrastructure technologies across the enterprise. Established during the Preliminary Phase and operationalized during Phase D, robust technology principles prevent reactive, ad-hoc technology adoption.
Core technology principles include:
Technology Independence : Software applications and data assets must be decoupled from specific hardware platforms, physical operating systems, and proprietary cloud vendor APIs. Wherever feasible, applications must target standard container runtimes (such as OCI-compliant containers) and open communication standards.
Standards-Based & Open Architecture : The enterprise prioritizes vendor-neutral, widely adopted industry standards (e.g., POSIX, TCP/IP, OpenID Connect, ANSI SQL, Kubernetes) over proprietary vendor extensions. This principle reduces supplier lock-in and facilitates interoperability across heterogeneous environments.
Interoperability Across Ecosystems : Technology components must exchange data and invoke platform services using open, well-documented protocols. Infrastructure platforms must not implement proprietary networking or storage protocols that prevent cross-platform integration.
Vendor Portability and Exit Strategies : Prior to adopting proprietary commercial cloud services or specialized hardware appliances, the enterprise must define an explicit exit strategy detailing the operational cost, time, and architectural refactoring required to migrate workloads to an alternative provider.
Security by Design and Zero Trust : Security controls must be embedded directly into the infrastructure fabric rather than treated as perimeter add-ons. Every technology component must enforce mutual authentication, least-privilege access, end-to-end encryption (in transit and at rest), and continuous security telemetry.
Modern Cloud Adoption Models & Shared Responsibility
Enterprise technology architects must evaluate cloud hosting models to balance operational control, agility, and financial expenditure. The cloud computing paradigm divides operational responsibilities between the cloud service provider (CSP) and the enterprise: Traditional On-Prem IaaS PaaS SaaS
- +---------------------+ +---------------------+ +---------------------+ +---------------------+
- | Applications (User) | | Applications (User) | | Applications (User) | | Applications (CSP) |
- | Data Assets (User) | | Data Assets (User) | | Data Assets (User) | | Data Assets (CSP) |
- | Runtimes (User) | | Runtimes (User) | | Runtimes (CSP) | | Runtimes (CSP) |
- | Middleware (User) | | Middleware (User) | | Middleware (CSP) | | Middleware (CSP) |
- | OS / Kernel (User) | | OS / Kernel (User) | | OS / Kernel (CSP) | | OS / Kernel (CSP) |
- | Hypervisor (User) | | Hypervisor (CSP) | | Hypervisor (CSP) | | Hypervisor (CSP) |
- | Servers/CPU (User) | | Servers/CPU (CSP) | | Servers/CPU (CSP) | | Servers/CPU (CSP) |
- | Storage Arrays(User)| | Storage Arrays(CSP) | | Storage Arrays(CSP) | | Storage Arrays(CSP) |
- | Physical Net (User) | | Physical Net (CSP) | | Physical Net (CSP) | | Physical Net (CSP) |
- +---------------------+ +---------------------+ +---------------------+ +---------------------+
- 1. Infrastructure-as-a-Service (IaaS)
The CSP provides virtualized compute instances, block storage, and software-defined networking. The enterprise retains full architectural control—and operational burden—for configuring the operating system, applying kernel security patches, managing runtime middleware, and configuring database clusters.
Best Suited For : Legacy application lift-and-shift migrations, bespoke operating system kernels, and applications with specialized network configurations.
2. Platform-as-a-Service (PaaS)
The CSP abstracts and manages the underlying hardware, hypervisors, operating systems, container orchestration engines, and database software. The enterprise focuses exclusively on deploying application code and managing data schemas.
Best Suited For : Rapid greenfield application development, cloud-native microservices, and managed relational databases where operational patching overhead must be minimized.
3. Software-as-a-Service (SaaS)
The vendor delivers a complete, turnkey application hosted on their cloud infrastructure. The enterprise manages only user access, role assignments, and client configuration data.
Best Suited For : Commodity enterprise capabilities (e.g., email, CRM, HRIS, enterprise collaboration) where custom development provides no competitive advantage.
4. Function-as-a-Service (FaaS) / Serverless
An event-driven execution model where the CSP executes code snippets in ephemeral containers in response to specific events (e.g., HTTP requests, queue messages). Billing is strictly consumption-based, scaling to zero when idle.
Best Suited For : Asynchronous event handling, real-time file processing, intermittent batch triggers, and webhooks.
Architectural Comparison Table: Cloud Hosting Models
Architectural Dimension Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS) Serverless / FaaS Software-as-a-Service (SaaS)
Enterprise Control Scope High (OS, network routing, storage tiers) Moderate (Application configurations, data models) Low (Application code and event triggers only) Minimal (User accounts, access policies, preferences)
Operational Maintenance High (OS patching, backup agents, clustering) Low (Automated backups, platform patching managed by CSP) Minimal (No server infrastructure to manage) None (Entirely managed by software vendor)
Elasticity & Scaling Coarse (Autoscaling VM instances; minutes) Fast (Horizontal container scaling; seconds) Instantaneous (Sub-second event-driven concurrency) Automated (Managed transparently by vendor)
Vendor Lock-in Risk Low (Standard VMs, generic Linux, portable images) Moderate to High (Proprietary CSP platform APIs) High (Proprietary event bindings and trigger formats) Severe (Proprietary data models and functional lock-in)
Billing Model Provisioned capacity (hourly/monthly VM allocations) Mixed (Base instance reservations + burst usage) Strict consumption (Execution duration and memory allocated) Per-user seat subscription or feature tier
Cloud Landing Zones: Architectural Guardrails
A frequent failure mode in enterprise cloud adoption is the uncontrolled, uncoordinated creation of cloud accounts by disparate development teams. Phase D establishes Cloud Landing Zones —a pre-configured, automated, and governed multi-account environment that serves as the baseline for all cloud workloads.
Key architectural pillars of an Enterprise Landing Zone include:
Multi-Account & Subscription Topology : Partitioning workloads across separate accounts based on security blast radius, regulatory classification, and environment lifecycle (e.g., Identity Account, Security/Audit Account, Shared Network Hub, Dev/Test Accounts, and Production Workload Accounts).
Centralized Network Hub-and-Spoke : Establishing a Transit Gateway or virtual network hub that consolidates outbound internet egress through next-generation firewalls, inspects cross-spoke traffic, and terminates dedicated private links (e.g., AWS DirectConnect, Azure ExpressRoute) back to on-premises data centers.
Federated Identity & Role-Based Access Control (RBAC) : Centralizing authentication against the enterprise identity provider (IdP) via SAML 2.0 or OpenID Connect, eliminating static API access keys and enforcing short-lived, role-assumed credentials.
Automated Policy Guardrails (Policy-as-Code) : Enforcing non-negotiable architectural constraints (e.g., prohibiting public IP addresses on database instances, mandating customer-managed KMS encryption on storage volumes, restricting resource deployment to authorized geographic regions).
Multi-Cloud and Edge Architecture Considerations
As organizations expand, enterprise architects must address multi-cloud strategies and edge computing topologies:
Multi-Cloud Strategies : While adopting multiple cloud providers mitigates vendor concentration risk and satisfies regulatory operational resilience mandates (e.g., DORA in the European Union), it introduces substantial cognitive overhead, fragmented observability, and expensive cross-cloud data egress fees. Practitioners recommend multi-cloud architectures primarily for specialized capabilities (e.g., AI/ML tooling on one cloud, legacy enterprise ERP on another) rather than distributing a single transactional application across multiple clouds.
Edge Computing Architectures : When business capabilities demand sub-millisecond response times, operate in bandwidth-constrained maritime/remote environments, or process high-throughput IoT sensor telemetry, processing data in centralized cloud data centers becomes technically unviable. Edge architecture places compute and storage nodes in close physical proximity to the data source (e.g., factory floors, retail stores, cell towers), running lightweight container runtimes that perform real-time inference and sync summarized records back to the core cloud repository.
Real-World Case Example: Global Telecommunications Cloud Transformation
TelcoUniversal , a tier-1 multinational telecommunications provider, operated five legacy data centers housing over 4,000 physical blade servers running on-premises billing, network telemetry, and customer provisioning systems. Facing $45 million in hardware lease renewals and recurring power outages, executive leadership mandated a rapid migration to the cloud.
During Phase D, the enterprise architecture team evaluated the portfolio against enterprise technology principles. Rather than allowing application teams to perform uncoordinated lift-and-shift migrations, the team:
Established an Enterprise Cloud Landing Zone featuring a centralized transit network hub, automated encryption enforcement, and IAM federation.
Formulated a Standards-Based Containerization Architecture (OCI containers orchestrated on managed Kubernetes) for core provisioning services, preventing proprietary cloud PaaS lock-in.
Designed an Edge Computing Architecture for network telemetry, placing lightweight edge processing clusters inside regional mobile switching centers to analyze 5G network traffic locally, filtering out 92% of raw telemetry before transmitting aggregated analytics to the central cloud data lake.
By executing this Phase D blueprint, TelcoUniversal retired three legacy data centers, reduced infrastructure operating costs by $18.2 million annually, and maintained the agility to migrate containerized workloads between cloud providers without refactoring application code.
Common Exam Traps & Practitioner Pitfalls
Jumping to Vendor Selection Before Defining Technology ABBs : Exam scenarios frequently present proposals where architects immediately select a specific cloud vendor product (e.g., AWS Aurora, Google Cloud Spanner) as the primary Phase D activity. TOGAF's approach is to first define vendor-neutral Technology Architecture Building Blocks (e.g., 'Distributed Relational Database Platform ABB') and non-functional specifications before selecting Solution Building Blocks (SBBs).
Confusing Cloud Adoption with Architectural Strategy : Cloud computing is an infrastructure delivery model, not a substitute for enterprise architecture. Migrating poorly architected, monolithic applications directly to cloud virtual machines (lift-and-shift) without addressing coupling, resilience, and operational governance often results in higher operational costs and worse reliability than on-premises hosting.
Neglecting the Shared Responsibility Model in Security Governance : Believing that moving workloads to public cloud PaaS or SaaS absolves the enterprise of security responsibilities is a dangerous misconception. The enterprise always retains ultimate accountability for data classification, identity access management, user permissions, and regulatory compliance.
Over-Architecting Multi-Cloud Workload Portability : Designing applications to dynamically fail over between AWS, Azure, and Google Cloud at runtime introduces extreme complexity and distributed database synchronization challenges. For the vast majority of enterprise use cases, workload portability at the container level (via standard Kubernetes and Helm charts) offers the optimal balance of agility and risk mitigation.