7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models

7.3 Technology Architecture Gap Analysis, Technical Reference Model (TRM), and Non-Functional Requirements

Designing a robust Technology Architecture requires rigorous analytical methods to ensure that infrastructure platforms satisfy operational demands without introducing excessive cost or complexity. Phase D brings together three practices to achieve this balance: selecting and tailoring reference models, systematically modeling Non-Functional Requirements (NFRs), and performing a formal Technology Gap Analysis. These techniques bridge the gap between abstract architectural visions and tangible, deployable infrastructure roadmaps.

---

Phase D Steps and Artifacts

Phase D follows the same nine-step pattern as Phases B and C: select reference models, viewpoints, and tools; develop the baseline description; develop the target description; perform gap analysis; define candidate roadmap components; resolve impacts across the Architecture Landscape; conduct a formal stakeholder review; finalize the Technology Architecture; and create or update the Architecture Definition Document.

TOGAF's Phase D artifacts include the Technology Standards catalog, Technology Portfolio catalog, Application/Technology matrix, Environments and Locations diagram, Platform Decomposition diagram, Processing diagram, Networked Computing/Hardware diagram, and Network and Communications diagram.

Reference Models and the Historical TRM

Step 1 of Phase D selects reference models. For many years the best-known was the TOGAF Technical Reference Model (TRM), a Foundation Architecture taxonomy of platform services. The TRM separates Application Software (business and infrastructure applications) from the Application Platform of services through the Application Platform Interface, with the Communications Infrastructure reached through the Communications Infrastructure Interface.

In the TOGAF Standard, 10th Edition, the TRM and the Integrated Information Infrastructure Reference Model (III-RM) are historical Series Guides in the TOGAF Library, not Fundamental Content. Their ideas still appear. TOGAF's Transition Architecture State Evolution Table, for example, can list services from a defined taxonomy "(e.g., the TOGAF TRM)". Treat any reference model, historical or current, as something to tailor to the enterprise, not to copy as a mandatory architecture. Industry reference models, such as those for banking or telecommunications, are held in the Reference Library of the Architecture Repository.

Capturing and Modeling Non-Functional Requirements (NFRs)

While functional requirements define what a system must do (e.g., 'process a credit card payment'), Non-Functional Requirements (NFRs)—also termed Quality Attributes or Architectural Characteristics—define how well the system must perform its functions. In Phase D, NFRs are the primary drivers of technology sizing, redundancy design, and platform topology.

A core practitioner failure is expressing NFRs in vague, subjective language (e.g., 'the system must be fast, scalable, and secure'). Good practice, consistent with TOGAF's SMART guidance for objectives, calls for NFRs that are quantifiable, measurable, and testable.

The Non-Functional Requirement Taxonomy

1. Availability & Uptime: The percentage of time a service is operational and accessible.
   • Metrics: Uptime percentage (e.g., 99.9% ['three nines' = 8.76 hours downtime/year] vs. 99.999% ['five nines' = 5.26 minutes downtime/year]).
   • Architectural Realization: Eliminating single points of failure (SPOFs), deploying active-active compute nodes across multiple availability zones, implementing automated health checks and failover load balancers.
2. Performance & Latency: The responsiveness of the platform under specified workloads.
   • Metrics: P95 and P99 latency percentiles (e.g., '99% of API requests must complete in under 150 milliseconds at 10,000 requests per second').
   • Architectural Realization: Edge caching via Content Delivery Networks (CDNs), distributed in-memory data grids (Redis), asynchronous event processing, and database read-replicas.
3. Scalability & Elasticity: The capacity of the platform to handle increasing transaction volumes.
   • Metrics: Peak concurrent users, transactions per second (TPS), data ingestion gigabytes per hour.
   • Architectural Realization: Horizontal pod autoscaling, stateless application tiers, dynamic cloud compute scaling groups, and partitioned database sharding.
4. Disaster Recovery (DR): The ability of the infrastructure to restore operational capability following a catastrophic regional outage.
   • Recovery Point Objective (RPO): The maximum acceptable age of data that can be lost when a disaster occurs (e.g., RPO = 0 means zero data loss, requiring synchronous replication).
   • Recovery Time Objective (RTO): The maximum acceptable duration of time required to restore service following an outage (e.g., RTO = 15 minutes).
   • Architectural Realization: Multi-region active-active clusters, asynchronous cross-region database replication, automated DNS failover (e.g., Route53 / Cloudflare), and automated Infrastructure as Code recovery pipelines.
5. Security & Data Sovereignty: Compliance with regulatory data locality and isolation mandates.
   • Metrics: Encryption standards (AES-256, TLS 1.3), data residency constraints (e.g., financial data must reside within national borders).
   • Architectural Realization: Dedicated hardware security modules (HSMs), region-locked cloud storage buckets, zero-trust network microsegmentation.

---

Architectural Trade-Off Analysis in Phase D

Architectural design is fundamentally an exercise in trade-off analysis. Conflicting NFRs cannot all be maximized simultaneously. Enterprise architects utilize structured trade-off matrices to evaluate competing platform designs:

• Availability vs. Financial Cost: Achieving 99.999% availability requires multi-region active-active infrastructure, duplicate database clusters, cross-region leased lines, and continuous synthetic testing, exponentially increasing infrastructure costs compared to an active-passive setup with 99.9% availability.
• Data Consistency vs. Latency (The CAP Theorem): In distributed data persistence, synchronous replication across geographic regions guarantees zero data loss (RPO = 0) and strong consistency, but adds substantial network round-trip latency to every transactional write. Asynchronous replication delivers sub-millisecond write latency, but introduces a risk of data loss during catastrophic regional failovers.
• Vendor Portability vs. Cloud-Native Velocity: Restricting infrastructure strictly to generic containers and standard VMs ensures portability, but prevents developers from leveraging specialized, managed cloud services that could accelerate time-to-market.

---

Mapping Business NFRs to Technology Architecture Solutions

---

Performing Technology Architecture Gap Analysis

In Step 4 of Phase D, enterprise architects conduct a formal Technology Gap Analysis using the TOGAF Gap Analysis Matrix. This matrix cross-references baseline technology components (rows) against target technology components (columns) to systematically identify infrastructure shortfalls, end-of-life systems, and net-new capabilities.

The Gap Analysis Matrix includes two critical boundary vectors:

• 'Eliminated / Retired' Column: Identifies existing baseline hardware, operating systems, or hosting contracts that have no place in the target architecture and must be safely decommissioned.
• 'New Target Building Blocks' Row: Identifies net-new infrastructure platforms, cloud landing zones, or network backbones required in the target state that do not exist in the baseline.

Representative Technology Gap Analysis Matrix

Key Gap Findings in Phase D

• Hardware Refresh & End-of-Life (EOL): Identification of physical servers, storage arrays, or network switches that have reached end-of-support, creating unmitigated operational and security risks.
• Operating System & Runtime Obsolescence: Legacy OS versions (e.g., Windows Server 2012, CentOS 7, Solaris 10) requiring forced migration to modern enterprise Linux or containerized execution environments.
• Capacity & Bandwidth Bottlenecks: Baseline network bandwidth or database IOPS that cannot support projected Phase C transaction volumes, requiring optical network upgrades or cloud transit gateways.
• Data Center Footprint Consolidation: Identifying redundant co-location facilities that can be decommissioned as workloads migrate to cloud landing zones.

---

Phase D Deliverables and Candidate Roadmap Components

Phase D culminates in the production and update of formal TOGAF architectural deliverables:

1. Architecture Definition Document (ADD) Updates:
   • Baseline Technology Architecture: Complete documentation of existing infrastructure, data center facilities, hardware inventories, operating systems, and network topologies.
   • Target Technology Architecture: Formal specifications of target technology building blocks, cloud landing zones, platform services, and capacity planning projections.
   • Technology Views: Specific viewpoints addressing stakeholder concerns, such as the Environments and Locations diagram (where technology is hosted), the Processing diagram (deployable units and how they are deployed onto technology), and the Networked Computing/Hardware diagram (network topology and hardware).
2. Technology Architecture Gap Analysis Matrix: Documenting the retained, modified, retired, and net-new infrastructure components.
3. Candidate Architecture Roadmap Components: Discrete, capability-aligned work packages formulated to resolve the identified technology gaps. These candidate components are fed directly into Phase E (Opportunities and Solutions), where they are consolidated with Business and Application work packages to create the integrated implementation roadmap.
   • Examples of Phase D Candidate Roadmap Components: 'Project Alpha: Legacy Data Center Decommissioning and Co-location Lease Exit', 'Project Beta: Enterprise Kubernetes Container Platform Rollout', 'Project Gamma: Global SD-WAN Zero-Trust Network Deployment'.

---

Real-World Case Example: Global Retail Payment Gateway Zero-Downtime Modernization

OmniPay Global, an international payment gateway processing $80 billion annually, operated a baseline technology estate consisting of two co-located data centers running on-premises Oracle database clusters on legacy Unix servers. During peak holiday shopping events, processing volume reached 18,000 transactions per second (TPS). In November 2024, a fiber cut combined with an unhandled database failover triggered an 82-minute global outage, costing $14 million in lost transaction fees and regulatory penalties.

During Phase D of their modernization ADM cycle:

1. Reference model taxonomy: The architects used a platform-services taxonomy, derived from the historical TOGAF TRM, to separate the transaction application software from the underlying data management and network communications platforms via standardized interfaces.
2. NFR Modeling: The team established rigorous, quantifiable NFRs: Availability of 99.999% ('five nines'), P99 transaction authorization latency under 80 milliseconds, RPO = 0 (zero lost transactions), and RTO < 60 seconds.
3. Gap Analysis: The Gap Analysis Matrix identified the legacy Unix servers and synchronous SAN replication as the primary bottleneck causing database lock-ups during network partitions.
4. Target Technology Architecture: The team designed a multi-region cloud deployment utilizing a distributed SQL database engine deployed across three geographic regions with quorum-based Raft consensus. An in-memory distributed cache handled tokenized card validation, while an intelligent Anycast DNS network routed transactions to the nearest healthy cloud edge node.

When tested under simulated regional network severed fiber scenarios during holiday load testing, the new Phase D platform processed 32,000 TPS with a P99 latency of 42ms and zero dropped transactions, validating the target architecture against all defined NFRs.

---

Common Exam Traps & Practitioner Pitfalls

• Treating a Reference Model as Mandatory: Reference models, including the historical TOGAF TRM, are generic starting points to be tailored to the enterprise's business and industry context, not prescriptive architectures.
• Specifying Subjective, Unmeasurable NFRs: Formulating NFRs as 'the platform should be highly available and responsive' is an architectural anti-pattern. Exam scenarios reward candidates who identify measurable metrics: 99.99% uptime, P99 latency < 200ms, RPO = 0, RTO < 15 minutes.
• Overlooking Infrastructure Retirement in Gap Analysis: Focusing exclusively on exciting new target technologies (e.g., Kubernetes, cloud AI platforms) while failing to account for the decommissioning, data erasure, and lease terminations of baseline hardware creates hidden technical debt and inaccurate migration budgets in Phase E.
• Ignoring Communications Infrastructure Latency in Multi-Region Architectures: Assuming that cloud resources in different geographic regions communicate instantaneously is a severe trap. High-volume synchronous database replication between geographically distant regions introduces physical speed-of-light network latency that can severely degrade application transaction throughput.