Phase D: Technology Architecture

Define the logical and physical technology components that realize the Business, Data, and Application Architectures.

About this phase

Phase D develops the Technology Architecture: the logical software and hardware capabilities and technology standards required to support the deployment of the business, data, and application services. It covers platforms, infrastructure, middleware, networks, communications, processing, and related standards.

The Technology Architecture grounds the earlier domains in deployable technology. It defines Technology Services and the technology building blocks (platform services, infrastructure components) that will host and connect the application components defined in Phase C.

Phase D follows the same nine-step pattern as Phases B and C. Its outputs complete the draft Architecture Definition Document across all four domains, ready for Phase E to shape into a delivery roadmap.

Objectives

Develop the Target Technology Architecture that enables the Architecture Vision, the target business, data, and application building blocks to be delivered through technology components and technology services, while addressing the Statement of Architecture Work and stakeholder concerns.
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures.

Steps in this phase

0/9 · 0%

1.Select reference models, viewpoints, and toolsChoose technology reference models (e.g., the TRM), viewpoints (e.g., environments and locations, platform decomposition, network), and modeling tools.
2.Develop the Baseline Technology Architecture descriptionDescribe the existing technology landscape — platforms, hosting, networks, standards — to the extent needed for gap analysis.
3.Develop the Target Technology Architecture descriptionDefine target technology services, platforms, environments, and standards that will host the target applications and data.
4.Perform gap analysisIdentify gaps between the Baseline and Target Technology Architectures.
5.Define candidate roadmap componentsDerive candidate technology work items (platform builds, migrations, decommissioning) as input to Phases E and F.
6.Resolve impacts across the Architecture LandscapeAssess implications for and from other architectures — e.g., shared platforms and enterprise standards.
7.Conduct formal stakeholder reviewVerify the Technology Architecture addresses stakeholder concerns and the Statement of Architecture Work.
8.Finalize the Technology ArchitectureSelect standards for each building block, fully document components and interfaces, and cross-check against requirements.
9.Create/update the Architecture Definition DocumentDocument the Technology Architecture (baseline, target, gaps, views), completing the four-domain draft of the Architecture Definition Document.

Key inputs

Request for Architecture Work and Statement of Architecture Work
Architecture Vision and Capability Assessment
Technology principles (if existing)
Organizational Model for Enterprise Architecture and Tailored Architecture Framework
Architecture Repository — reusable building blocks, reference models (e.g., TRM), organization-specific standards
Draft Architecture Definition Document, including Business, Data, and Application Architectures
Draft Architecture Requirements Specification, including gap analysis results from Phases B and C
Business, Data, and Application Architecture components of an Architecture Roadmap

Key outputs

Refined and updated Architecture Vision phase deliverables where applicable
Draft Architecture Definition Document containing Baseline and Target Technology Architecture (v1.0)
Draft Architecture Requirements Specification, including gap analysis results and requirements for the Technology Architecture
Technology Architecture components of an Architecture Roadmap

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

PFrom Preliminary Phase

AFrom Phase A: Architecture Vision

BFrom Phase B: Business Architecture

CFrom Phase C: Information Systems Architectures

RMFrom ADM Architecture Requirements Management

Prepared for this phase

example inputDeliverablefrom PreliminaryThe document from the sponsoring organization that triggers an ADM cycle — the key handoff from the Preliminary Phase into Phase A.

Request for Architecture Work

Sponsoring organization: Meridian Retail Group — Office of the COO Date: 2 April 2026 Reference: RAW-2026-001 Addressed to: Architecture Board (submitted via the Lead Architect)

Organization sponsors

Chief Operating Officer (business sponsor); Chief Information Officer (executive sponsor for architecture).

Mission statement

Deliver the "One Meridian" unified customer experience: any customer, recognized in any channel, served from a single view of orders, inventory, and preferences.

Business goals and changes

Increase repeat-purchase rate from 31% to 40% within 24 months
Enable buy-online-pickup-in-store (BOPIS) in all 240 stores
Consolidate 4 customer databases into a governed single customer view
Reduce integration spend by 20%

Strategic plans

Responds to the One Meridian strategy (FY26–FY28) and Board Directive 26-04. Goals map to drivers DRV-01 to DRV-04 in the Driver/Goal/Objective catalog.

Time limits

Architecture definition (Target Architecture and roadmap) approved before the 1 Nov 2026 peak trading freeze
First Transition Architecture in production before the FY27 peak freeze

Changes in the business environment

Competitors now offer click-and-collect as standard; digital revenue at 26% and rising; POS v9 reaches end of life in 2027.

Organizational constraints

Peak trading freeze: no production change 1 Nov – 15 Jan
Franchise stores operate their own POS until contract renewal (FY27)

Financial constraints

Indicative program envelope of $18M over 2 years, subject to Investment Committee approval per tranche.

External and business constraints

GDPR and PCI-DSS compliance mandatory
3PL logistics contract fixes EDI message formats until 2027

Current business system description

Channel-based operating model: Digital Commerce, Store Operations, and Customer Care each run their own customer processes and service standards.

Current systems description

4 customer databases, 3 order management systems, in-store POS (v9, EOL 2027), monolithic e-commerce platform, nightly-batch warehouse integration.

Developing organization and resources available

Meridian EA team (Lead Architect plus 4 domain architects), working under the Tailored Architecture Framework v1.0 and Architecture Principles v1.0. Business subject-matter experts released for up to 2 days per week during Phases B–D.

Success criteria

An approved Target Architecture and Implementation and Migration Plan for the One Meridian program, with the first Transition Architecture delivered before the FY27 peak trading freeze.

Submitted by: COO, 2 April 2026 · Accepted for Phase A: Architecture Board, 9 April 2026

Example outputs

example outputDeliverableTarget platform services, environments and locations, and the technology gap summary.

Architecture Definition Document — Technology Architecture (draft v0.4, excerpt)

Section: 8 (Technology Architecture) · Author: A. Duarte · Status: Approved by the Architecture Board, 27 Aug 2026 · Completes: four-domain draft of the ADD

1. Approach and viewpoints

The taxonomy of technology services follows the TOGAF Technical Reference Model (TRM), with Meridian-specific additions for store edge computing. Views produced in this phase: Environments and Locations, Platform Decomposition, Application/Technology matrix, and the Technology Standards catalog. Each addresses concerns recorded in the Stakeholder Map (SM-2026-001).

Stakeholder	Concern	View
CIO	Platform consolidation, DC exit	Platform Decomposition diagram
CISO / DPO	PCI scope, data residency	Environments and Locations diagram
Store Ops leadership	Trading during WAN outages	Environments and Locations diagram
Delivery teams	Which standards to build to	Technology Standards catalog

2. Baseline (summary)

Single data center (2 halls) with an aging hypervisor cluster; per-store POS servers reaching end of life in 2027; flat store networks on MPLS; batch file integration; no customer identity platform; fragmented monitoring. Detail in the baseline technology inventory (BT-01..BT-10).

3. Target platform services (extract)

Technology service (ABB)	Description	Consumed by
Container Platform Service	Managed Kubernetes for custom services	Customer Profile Svc, Inventory Svc, Commerce Front End
API Gateway Service	External/internal API mediation, throttling, authN	All channel apps, SaaS integrations
Event Streaming Service	Durable pub/sub for order & inventory events	Order Hub, Inventory Svc, WMS, LoyaltyOne adapter
Customer Identity Service (CIAM)	Customer authentication, consent-aware sessions	Commerce Front End, Next-gen POS
Managed Relational Database Service	Transactional stores	Customer Profile Svc, Order Hub
Observability Service	Unified logs, metrics, traces, alerting	All target components
Store Edge Service	Minimal in-store compute for offline-tolerant POS	Next-gen POS

These are Architecture Building Blocks. They state required capability and service levels, not products. Product selection (SBBs) happens in Phase E under the Buy Before Build principle.

4. Environments and locations (summary)

Cloud (primary region + DR region): all shared services and channel back ends; production, staging, and performance environments
Stores (240): thin Store Edge node per store; POS operates in degraded-offline mode on WAN loss (sync on restore)
Data center: shrinks to legacy WMS host until FY29 lease end

Both cloud regions are inside the EU to meet the Data Governance Council's residency policy for customer data.

5. Technology standards (new entries for the Standards catalog)

Standard	Status
Container runtime & orchestration standard	Adopted
Event schema standard (CloudEvents-based)	Adopted
Store network segmentation standard (POS VLAN, PCI zone)	Adopted
TLS 1.3 minimum for all new services	Adopted

6. How the target meets key requirements

Requirement	Design response
REQ-T-01 99.95% checkout	Multi-zone deployment in primary region; active-standby DR region
REQ-T-03 POS offline ≥ 8h	Store Edge holds local catalog, prices and a transaction queue
REQ-T-05 PCI scope	Payment traffic only in the segmented PCI zone; tokenization at the terminal
REQ-T-06 Peak 5x	Container autoscaling on the checkout path; no manual resizing

7. Technology gap summary → roadmap candidates

Gap	Roadmap candidate
No container/API/event platform	WP-08: Landing zone + integration platform build
Store connectivity & segmentation	WP-09: Store network upgrade (240 sites)
No CIAM	WP-10: Customer identity platform
Observability fragmented	WP-11: Unified observability rollout

8. Architecture decisions recorded

TD-01: Public cloud as primary hosting; no new workloads in the data center.
TD-02: FY27 hardware refresh limited to the WMS footprint.
TD-03: Store Edge is a thin node, not a full store server, so it stays within field-force capacity of 40 refits a month.

Study notes

Produced in: Step 1: Select reference models, viewpoints, and tools · Step 3: Develop the Target Technology Architecture description · Step 8: Finalize the Technology Architecture · Step 9: Create/update the Architecture Definition Document

With this section, the draft Architecture Definition Document covers all four domains (Business, Data, Application, Technology). Phase E works from this four-domain draft.
The target services are ABBs described by capability and service level. Naming products here would anticipate Phase E, where SBBs are selected. This distinction appears often in exam questions.
Section 1 maps stakeholders to views. It applies the viewpoint selection from step 1 and continues the concern-to-view chain started in the Phase A Stakeholder Map.
Section 6 is the cross-check from step 8: each key requirement in the Architecture Requirements Specification has a design response that a Phase G compliance review can test.

Study tips & key concepts

Phase D completes the four architecture domains (BDAT: Business, Data, Application, Technology) — after Phase D, the draft Architecture Definition Document covers all four.
Technology Architecture defines technology services and components as building blocks — Architecture Building Blocks (ABBs) here; specific products (Solution Building Blocks, SBBs) are typically identified from Phase E onward.
Recognize typical Phase D artifacts: Technology Standards catalog, Technology Portfolio catalog, Application/Technology matrix, Environments and Locations diagram, Platform Decomposition diagram, Network Computing/Hardware diagram.
Emerging technologies and non-functional requirements (capacity, availability, security, latency) are major drivers in this phase.
The same nine-step pattern as B and C applies — if you know it for one domain phase, you know it for all three.