In the TOGAF Architecture Development Method (ADM), Phase D: Technology Architecture is often the most tangible for IT professionals. While Phases B and C define what the business does and how data flows, Phase D defines the hardware, software, and network infrastructure required to support those capabilities.
Phase D ensures that the logical application and data architectures (from Phase C) have a robust, secure, and scalable physical foundation. This guide zooms in exclusively on the three primary deliverables of Phase D, providing detailed breakdowns, templates, and practical examples using our continuing case study of GlobalFin Corp.
Architecture Definition Document (Technology)
Architecture Requirements Specification (Technology)
Architecture Roadmap (Technology)
The Technology Architecture Definition Document (ADD-Tech) provides a comprehensive view of the baseline (current state) and target (future state) technology environments. It bridges the gap between logical application components and physical infrastructure.
Baseline Technology Architecture: Current servers, networks, storage, and middleware.
Target Technology Architecture: Future infrastructure design, including cloud services, hybrid models, and new hardware.
Gap Analysis: Specific differences between baseline and target.
Technology Standards: Approved technologies, protocols, and platforms.
Compute: 50 Physical Servers in On-Premise Data Center (San Francisco). Aging hardware (5+ years old).
Network: Traditional VLAN-based segmentation. Single firewall perimeter.
Storage: SAN (Storage Area Network) with limited scalability.
Middleware: Legacy IBM WebSphere Application Server.
Pain Points: High maintenance costs, slow provisioning (weeks for new servers), single point of failure risks.
Compute: Hybrid Cloud Model.
AWS EC2: For customer-facing microservices (auto-scaling groups).
Azure Virtual Machines: For internal HR and Finance systems (due to existing Microsoft licensing).
Network: Software-Defined Networking (SDN). Direct Connect links to AWS and Azure. Zero Trust security model implementation.
Storage: AWS S3 for unstructured data; Azure Blob Storage for backups.
Middleware: Container orchestration via Kubernetes (EKS on AWS, AKS on Azure).
Benefits: Elastic scalability, reduced CAPEX, improved disaster recovery (multi-region).
| Component | Baseline | Target | Gap Action Required |
|---|---|---|---|
| Server Provisioning | Manual, 2-4 weeks | Automated via Terraform, <1 hour | Implement Infrastructure as Code (IaC) tools |
| Security Model | Perimeter-based Firewall | Zero Trust / Identity-Centric | Deploy Identity Provider (Okta) and Service Mesh |
| Monitoring | Siloed tools (Nagios, Splunk) | Unified Observability (Datadog) | Migrate logs and metrics to centralized platform |
Container Runtime: Docker Enterprise Edition.
Orchestration: Kubernetes v1.28+.
CI/CD Pipeline: Jenkins integrated with AWS CodePipeline.
Database Engine: PostgreSQL 15 for relational; MongoDB 6 for document store.
This document translates business and information system requirements into specific technical constraints and quality attributes. It ensures the technology stack can meet performance, security, and compliance needs.
Functional Requirements: Specific technical capabilities needed.
Non-Functional Requirements (NFRs): Performance, reliability, security, scalability.
Compliance Requirements: Regulatory and legal constraints.
Constraints: Budgetary, legacy integration, or vendor-specific limitations.
API Gateway: Must support REST and GraphQL endpoints with rate limiting and throttling capabilities.
Service Discovery: Automatic registration and discovery of microservices within the Kubernetes cluster.
Secrets Management: Centralized management of API keys, database passwords, and certificates using HashiCorp Vault.
| Category | Requirement | Metric/Threshold |
|---|---|---|
| Performance | API Response Time | < 200ms for 95% of requests under peak load |
| Availability | Uptime SLA | 99.99% for customer-facing services |
| Scalability | Auto-Scaling | Handle 10x traffic spike during holiday season without manual intervention |
| Recoverability | RTO/RPO | Recovery Time Objective < 1 hour; Recovery Point Objective < 5 minutes |
| Security | Encryption | AES-256 for data at rest; TLS 1.3 for data in transit |
PCI-DSS: All systems handling credit card data must be isolated in a dedicated VPC with strict access controls.
GDPR: Data residency requirements mandate that EU customer data remains within Frankfurt (AWS eu-central-1) region.
SOX: Audit logs for all administrative access to production infrastructure must be retained for 7 years.
Budget: Total annual cloud spend must not exceed $1.2M for the first year.
Legacy Integration: Must maintain connectivity to the mainframe via IBM MQ for the next 12 months during migration.
Vendor Lock-in: Avoid proprietary AWS-only services where open-source alternatives exist (e.g., use Kafka instead of Kinesis if possible).
The Technology Architecture Roadmap outlines the sequence of projects and initiatives required to transition from the baseline to the target technology architecture. It aligns technical milestones with business value delivery.
Transition Architectures: Intermediate states that provide incremental value.
Project Portfolio: List of infrastructure projects.
Timeline: Phased approach with dependencies.
Resource Allocation: Skills and budget required per phase.
Objective: Establish secure cloud landing zone.
Key Activities:
Set up AWS Organization and Azure Subscription structure.
Implement Identity Provider (Okta) integration.
Deploy Network Firewall and WAF (Web Application Firewall).
Establish CI/CD pipeline skeleton.
Deliverable: Secure "Landing Zone" ready for application deployment.
Business Value: Enhanced security posture; compliance readiness.
Objective: Migrate non-critical applications to validate patterns.
Key Activities:
Containerize the "Customer Profile" service.
Deploy to AWS EKS.
Implement centralized logging (Datadog).
Decommission 10 physical servers.
Deliverable: First live microservice in production cloud environment.
Business Value: Proof of concept; team skill development; initial cost savings.
Objective: Migrate core banking engines.
Key Activities:
Refactor "Loan Processing" engine for cloud-native deployment.
Implement database replication from on-premise Oracle to AWS RDS PostgreSQL.
Set up multi-region disaster recovery.
Decommission remaining 40 physical servers.
Deliverable: Core banking functions running on hybrid cloud.
Business Value: Significant scalability improvement; reduced operational risk.
Objective: Leverage cloud-native features.
Key Activities:
Implement serverless functions for event-driven processes.
Use AI/ML services for fraud detection.
Optimize cloud costs using reserved instances and spot instances.
Deliverable: Fully optimized cloud-native platform.
Business Value: Competitive advantage through innovation; lowest total cost of ownership.
gantt
title GlobalFin Tech Architecture Roadmap
dateFormat YYYY-MM-DD
section Phase 1: Foundation
Cloud Landing Zone :active, p1, 2024-01-01, 90d
Security Setup :p1, 2024-01-15, 75d
section Phase 2: Pilot Migration
Containerize Profile Svc :crit, p2, 2024-04-01, 60d
Deploy to EKS :p2, 2024-05-01, 30d
section Phase 3: Core Migration
Refactor Loan Engine :crit, p3, 2024-07-01, 120d
DB Migration :p3, 2024-08-01, 90d
section Phase 4: Optimization
Serverless Implementation :p4, 2025-01-01, 90d
Cost Optimization :p4, 2025-02-01, 60d
Input from Phase C: The Application Architecture defines the number of microservices, which dictates the Kubernetes cluster size in Phase D.
Input from Phase B: Business continuity requirements (e.g., "24/7 global access") drive the multi-region setup in Phase D.
Output to Phase E: The Technology Roadmap informs the Implementation Plan by identifying infrastructure prerequisites for each application project.
Avoid Over-Engineering: Do not design for Google-scale if you are a mid-sized bank. Right-size your infrastructure.
Automate Everything: Use Infrastructure as Code (Terraform, Ansible) to ensure the Target Architecture is reproducible and version-controlled.
Security Left: Integrate security requirements (DevSecOps) into the Technology Architecture from day one, not as an afterthought.
Vendor Neutrality: Where possible, choose open standards to avoid lock-in, unless there is a compelling business reason.
Continuous Validation: Regularly update the Architecture Definition Document as cloud services evolve rapidly.
Phase D is where the rubber meets the road. A well-crafted Technology Architecture Definition Document provides clarity on the physical landscape. A rigorous Requirements Specification ensures the infrastructure meets business needs for performance and security. And a realistic Roadmap ensures a smooth, low-risk transition.
For GlobalFin Corp, these deliverables transformed a vague desire to "go cloud" into a concrete, actionable plan that reduced risk, controlled costs, and enabled rapid innovation. By mastering these three deliverables, architects can ensure their technology foundations are not just stable, but strategic assets.
