Study guide
6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
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
6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
Key Takeaways Explain This Topic AI
The Application/Organization Matrix cross-references application systems against business units, departments, and user roles, revealing system ownership, stakeholder dependencies, and shadow IT redundancy.
The Application/Function Matrix maps applications to business functions and capabilities, providing immediate visibility into functional gaps (unsupported processes) and duplication (redundant systems executing identical capabilities).
Application Gap Analysis systematically compares baseline and target application building blocks using a structured matrix to categorize components as Retained, Retired/Eliminated, New, or Modified.
The Application Communication Diagram models runtime interactions, message exchange patterns, integration protocols, and trust boundaries between application components.
Defining precise Application System Boundaries using Domain-Driven Design bounded contexts ensures single data mastership, high cohesion, loose coupling, and operational release autonomy across systems.
Last updated: October 2026
6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
The TOGAF Architecture Content Framework categorizes architectural work products into three core types: Catalogs (inventories of building blocks), Matrices (tabular cross-mappings depicting relationships between entities), and Diagrams (visual views representing architectural structures from stakeholder viewpoints). In Phase C Application Architecture, matrices and diagrams are the primary instruments used to analyze relationships across business units, functional capabilities, and technical systems. Without these artifacts, enterprise architects cannot identify redundancies, enforce clear system boundaries, or conduct an auditable gap analysis.
The Role of Structured Artifacts in Phase C
While the Application Portfolio Catalog maintains the master list of all software assets, it provides only a flat, one-dimensional inventory. True architectural insight emerges when application entities are cross-referenced against entities from other architectural domains. Specifically, Phase C relies heavily on two critical matrices:
Application / Organization Matrix : Maps application systems to the business units, divisions, external partners, or user roles that consume or own them.
Application / Function Matrix : Maps application systems to the business functions and business capabilities (established in Phase B) that they automate.
The Application/Organization Matrix: Stakeholder Alignment & Redundancy Discovery
The Application/Organization Matrix provides a structured view of organizational software consumption. By listing business units along one axis and applications along the other, architects can immediately identify:
Software Redundancy & Proliferation : Multiple business units procuring separate, uncoordinated software tools to perform identical tasks (e.g., three divisions running separate CRM instances).
Shadow IT Deployment : Unapproved SaaS systems adopted by rogue business units without architecture review or security compliance sign-off.
Orphaned Applications : Legacy software systems that have no designated business unit owner or executive sponsor, yet continue to consume data center power and licensing capital.
Stakeholder Impact Scope : Exactly which business units and executive stakeholders will be disrupted during a planned system migration or retirement.
Representative Application/Organization Matrix
Application System (ABB / SBB) Retail Banking Commercial Lending Wealth Management Customer Care Operations Risk & Compliance
- Core Banking Ledger (Legacy Mainframe) Primary User Primary User Secondary User Read-Only Secondary User
- Salesforce CRM (Enterprise SaaS) Primary User None None Primary User None
- HubSpot CRM (Divisional Shadow IT) None Primary User None None None
- Microsoft Dynamics CRM (Divisional) None None Primary User None None
- Actimize Anti-Money Laundering ABB None None None None Primary User
- Zendesk Contact Center Platform Secondary User None None Primary User None
Architectural Interpretation : The matrix instantly exposes severe software redundancy. The enterprise is paying for three separate CRM platforms across Retail Banking, Commercial Lending, and Wealth Management. This discovery triggers an immediate Application Portfolio Rationalization initiative to consolidate onto a single enterprise CRM building block, eliminating duplicated licensing and unifying customer profiles.
The Application/Function Matrix: Exposing Capability Gaps & Duplication
The Application/Function Matrix maps applications against business functions and capabilities defined in Phase B. This matrix is the primary tool used to evaluate functional coverage across the enterprise. When analyzing intersections in this matrix, architects apply three standard diagnostic rules:
Zero Applications Mapped to a Function (0:1) : Represents an Architectural Capability Gap . The business requires this capability, but no automated software exists to support it, forcing staff to rely on error-prone manual spreadsheets or paper workflows. A new Application Building Block (ABB) must be planned in the target architecture.
Exactly One Application Mapped to a Function (1:1) : Represents Optimal Architectural Alignment . The business function is cleanly automated by a single authoritative application system.
Multiple Applications Mapped to a Function (N:1) : Represents Functional Duplication and Redundancy . Two or more distinct software systems are executing the same business logic, leading to data inconsistencies, conflicting calculations, and wasteful maintenance expenditure.
Representative Application/Function Matrix
Business Function / Capability (Phase B) Legacy Loan Engine NextGen Lending Platform Credit Bureau Gateway Wealth Advisory Portal Core GL Ledger
- Customer Credit Scoring Redundant Primary Primary None None
- Loan Origination & Underwriting Redundant Primary None None None
- Automated Collateral Valuation [ GAP ] [ GAP ] None None None
- Portfolio Advisory Modeling None None None Primary None
- General Ledger Reconciliation None None None None Primary
Architectural Interpretation : Notice that "Automated Collateral Valuation" has zero mapped systems, uncovering a critical capability gap that must be addressed in the Target Application Architecture. Meanwhile, both the "Legacy Loan Engine" and "NextGen Lending Platform" automate loan underwriting, confirming ongoing functional redundancy that must be resolved by retiring the legacy engine.
Application Communication Diagrams & Interface Modeling
The Application Communication Diagram visualizes the dynamic runtime interactions between application systems. It depicts how applications cooperate to execute business processes, including communication protocols, data payload formats, interface directions, and security trust boundaries.
Architects must capture several key interface attributes on communication diagrams:
Integration Style & Protocol : Synchronous (HTTP/REST, gRPC), Asynchronous (AMQP, Kafka, MQTT), or Batch (SFTP, database staging tables).
Synchronization Mechanics : Request-response vs. fire-and-forget event publication.
Network and Trust Boundaries : DMZ perimeters, internal VPCs, third-party partner connections, and zero-trust authentication checkpoints.
Interface Directionality : Unidirectional data feeds vs. bidirectional interactive exchanges.
Applying the TOGAF Gap Analysis Matrix to Applications
Step 4 of Phase C requires performing a formal Gap Analysis . The TOGAF Gap Analysis Matrix is a structured 2D table that systematically compares Baseline Application Building Blocks (listed along the vertical rows) against Target Application Building Blocks (listed along the horizontal columns).
The matrix features two specialized outer boundaries:
An additional Right-Hand Column titled "Eliminated / Retired" , capturing baseline applications that have no corresponding target equivalent and must be decommissioned.
An additional Bottom Row titled "New Target Building Blocks" , capturing target applications that have no baseline predecessor and must be built or procured.
Representative Application Gap Analysis Matrix
Baseline Applications \ Target Applications Core Banking ABB Enterprise CRM ABB Fraud Detection ABB NextGen Lending ABB Eliminated / Retired Baseline
- Mainframe Core Ledger Modified (Encapsulated) None None None None
- Siebel CRM v7.5 None Replaced None None RETIRED (Decommission)
- HubSpot Commercial CRM None Replaced None None RETIRED (Terminate SaaS)
- Legacy Regional Loan Engine None None None Replaced RETIRED (Decommission)
- New Target Building Blocks None NEW (Procure SaaS) NEW (AI Engine) NEW (Custom Cloud) Gaps Identified
- Interpreting the Gap Classifications
Retained : The baseline application persists into the target architecture unchanged.
Modified / Enhanced : The baseline application is carried forward but requires architectural modification (e.g., encapsulating a mainframe ledger with modern REST APIs).
Retired / Eliminated : The baseline application is rendered obsolete and must be decommissioned, generating retirement work packages for Phase E.
New : A net-new building block required to satisfy a business capability gap, generating procurement (COTS/SaaS) or development work packages.
Establishing Rigorous Application System Boundaries
A primary duty of the enterprise application architect is defining and governing system boundaries . When system boundaries are ill-defined, applications suffer from "scope creep," where developers add unrelated features to an existing system simply because it is convenient. Over time, this erodes architectural modularity and creates monolithic entanglements.
To establish clean system boundaries, architects apply principles from Domain-Driven Design (DDD) :
Bounded Contexts : Each Application Building Block must operate within an explicit bounded context that encapsulates a specific domain model and ubiquitous business vocabulary. A "Customer" entity in a Sales context (leads, opportunities, contracts) must not be conflated with a "Customer" entity in a Billing context (tax IDs, payment methods, credit balances).
High Cohesion : All functions and data within a boundary must support a single, tightly unified business capability.
Single Mastership (System of Record) : Exactly one application system must be designated as the authoritative System of Record (SoR) for each core data entity. If the ERP owns the master general ledger, no CRM system may write ledger entries directly without going through the ERP's governed interface.
Operational & Release Autonomy : A system within its boundary must be capable of being patched, updated, and deployed independently without forcing simultaneous deployments of upstream or downstream applications.
Real-World Case Example: Omnichannel Banking Modernization
Apex Global Bank undertook a Phase C transformation to replace its branch-only retail banking model with a modern omnichannel banking experience. During baseline discovery, the enterprise architecture team authored an Application/Organization Matrix and an Application/Function Matrix. The matrices revealed that:
Retail branches used a 1980s green-screen terminal system called BranchFlow .
The call center used a custom Windows client called PhoneAssist .
Mobile banking used a hastily built third-party white-label app with direct read-access to the core database.
Because all three systems maintained separate customer profile tables, a customer updating their home address on the mobile app would find their bank statements still mailed to their old address, triggering hundreds of regulatory audit complaints.
The enterprise architect constructed an Application Gap Analysis Matrix and defined strict system boundaries:
A new, vendor-neutral Customer Profile & Preferences ABB was designated as the sole System of Record for all customer demographic data.
BranchFlow , PhoneAssist , and the white-label mobile app were classified as Eliminated / Retired .
A unified Omnichannel Engagement ABB was designed to provide standardized API access across web, mobile, and branch terminals.
By establishing clear boundaries and retiring redundant client systems, Apex Bank reduced customer profile update errors by 99.4% and accelerated mobile feature releases from nine-month waterfall cycles to bi-weekly deployments.
Common Exam Traps & Practitioner Pitfalls
Confusing Application/Function with Application/Organization Matrices : Exam questions frequently test whether candidates know which matrix exposes shadow IT (Application/Organization) versus which exposes functional capability gaps (Application/Function). Mapping to organizational departments evaluates software governance and ownership; mapping to business functions evaluates capability coverage.
Treating Gap Analysis as a Casual Diff : TOGAF Gap Analysis requires a structured matrix cross-referencing baseline rows against target columns, specifically accounting for retired systems and net-new additions. Informal bulleted lists fail to meet standard TOGAF rigor.
Ignoring Network and Trust Boundaries in Communication Diagrams : Drawing application interface lines without indicating communication protocols, encryption standards, or DMZ firewalls produces incomplete diagrams that fail security governance reviews.