Study guide
6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration
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.2 Application Portfolio Rationalization, Component Modeling, and Application Integration
Key Takeaways Explain This Topic AI
Application Portfolio Rationalization (APR) optimizes the enterprise software footprint by categorizing applications across Business Value and Technical Fitness using the Gartner TIME framework (Tolerate, Invest, Migrate, Eliminate).
The TOGAF Content Framework distinguishes Architecture Building Blocks (ABBs), which capture logical application functionality, and Solution Building Blocks (SBBs), which represent physical vendor software or custom codebases.
Modern application architectural styles—Monolithic, Modular, Microservices, and Event-Driven—present critical engineering trade-offs regarding component coupling, operational overhead, transactional consistency, and deployment velocity.
Robust application integration relies on well-defined system boundaries and standard communication patterns (APIs, asynchronous message brokers, event streams, and mediation gateways), mitigating the failure modes of point-to-point spaghetti architectures.
Decommissioning applications in the Eliminate quadrant is an essential architectural responsibility that curtails technical debt, closes cybersecurity vulnerabilities, and recovers licensing capital for strategic innovation.
Last updated: October 2026
6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration
Enterprises operating across multiple business cycles inevitably accumulate severe application bloat. Mergers and acquisitions, departmental shadow IT, decentralized software procurement, and changing vendor relationships result in sprawling portfolios where multiple applications perform identical business functions. In many large enterprises, most of the IT operating budget goes to running, patching, and maintaining existing applications, leaving relatively little for strategic change. Phase C Application Architecture provides two indispensable practices to reverse this decay: Application Portfolio Rationalization (APR) and Logical Component Modeling .
The Imperative for Application Portfolio Rationalization (APR)
Application Portfolio Rationalization is the systematic, evidence-based evaluation of an enterprise's software assets to determine which applications should be retained, modernized, replaced, or decommissioned. The strategic objectives of APR include:
Reducing Run-the-Business (RTB) Operating Expense : Eliminating redundant software licenses, hosting infrastructure, support contracts, and specialized maintenance staffing.
Mitigating Operational & Cybersecurity Vulnerability : Retiring obsolete, unpatched systems running on unsupported operating systems or runtimes.
Increasing Agility : Reducing the complexity of the integration mesh, enabling faster delivery cycles and simplified regression testing.
Enabling Data Coherence : Eliminating contradictory customer and financial data silos scattered across redundant systems.
The TIME Framework: Analytical Foundations
A widely used portfolio rationalization model, which is not part of TOGAF itself, is the Gartner TIME Framework . TOGAF's own Phase E guidance uses a simpler classification of current systems: Mainstream (part of the future information system), Contain (expected to be replaced or modified within the planning horizon), and Replace (to be replaced within the planning horizon). The TIME framework evaluates every application in the enterprise portfolio along two fundamental axes:
Business Value / Strategic Fit (Y-Axis) : Measures how effectively the application supports current and future business capabilities, drives revenue, satisfies customer expectations, and complies with industry regulations.
Technical Fitness / Architecture Quality (X-Axis) : Measures the application's underlying code quality, architectural modularity, maintainability, vendor support status, cybersecurity resilience, scalability, and integration openness. High ^
- | MIGRATE INVEST
- | High Business Value High Business Value
- | Low Technical Fitness High Technical Fitness
- | (Refactor / Replatform) (Enhance / Scale)
- Business|
- Value |---------------------------------------------------
- | ELIMINATE TOLERATE
- | Low Business Value Low Business Value
- | Low Technical Fitness High Technical Fitness
- | (Decommission / Archive) (Maintain As-Is / Contain)
- Low +--------------------------------------------------->
- Low Technical Fitness High
- Deep-Dive into the Four TIME Quadrants
Each quadrant of the TIME matrix dictates a distinct architectural roadmap strategy:
1. Tolerate (Low Business Value, High Technical Fitness)
Applications in the Tolerate quadrant are technically sound, stable, and incur low operational defect rates, but provide minimal strategic differentiation or business impact. Examples include internal expense reporting tools or utility calculators.
Architectural Action : Maintain As-Is . Do not allocate discretionary capital or architectural effort toward enhancing these systems. Keep them running in a steady state, perform mandatory security patching, and avoid investing in custom feature development.
2. Invest (High Business Value, High Technical Fitness)
Invest applications represent the crown jewels of the enterprise. They automate critical, highly differentiating business capabilities while running on modern, resilient, maintainable architectures (e.g., a proprietary algorithmic trading engine or an advanced omnichannel e-commerce platform).
Architectural Action : Expand and Optimize . Direct strategic capital toward these systems. Automate deployment pipelines, expand API capabilities, introduce AI/ML optimizations, and scale capacity to maximize competitive advantage.
3. Migrate (High Business Value, Low Technical Fitness)
Migrate applications are mission-critical workhorses that generate substantial revenue or support vital operational workflows, but are hobbled by severe technical debt. They may run on obsolete mainframes, unsupported operating systems, or brittle monolithic architectures with exorbitant maintenance overhead.
Architectural Action : Modernize, Refactor, or Replace . These systems represent catastrophic operational risks. Architects must formulate modernization roadmaps using patterns such as re-hosting (lift-and-shift), re-platforming, refactoring to microservices, or wholesale replacement with modern Commercial Off-the-Shelf (COTS) or Software-as-a-Service (SaaS) platforms.
4. Eliminate (Low Business Value, Low Technical Fitness)
Eliminate applications fail on both counts: they provide negligible business value while consuming disproportionate operational support, generating severe cybersecurity vulnerabilities, and incurring recurring software licensing fees. They frequently represent legacy systems that were bypassed by newer SaaS tools but never formally decommissioned.
Architectural Action : Decommission and Retire . Define a decommissioning work package in Phase E. Extract and archive historical data to satisfy compliance mandates, migrate any remaining active users to standard enterprise platforms, terminate vendor maintenance contracts, and safely shut down servers.
Component Modeling: Architecture Building Blocks (ABBs) vs. Solution Building Blocks (SBBs)
A foundational idea in the TOGAF Content Framework is the separation between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) .
Architecture Building Blocks (ABBs) in Phase C
In Phase C, application architects model Application Building Blocks (ABBs) . An ABB is a logical, vendor-neutral definition of an application capability. It defines what the system must do, its functional boundaries, the application services it provides, its non-functional requirements (SLAs, throughput, availability), and the standard interface contracts it exposes to the enterprise.
Examples of ABBs : "Customer Relationship Management ABB", "Enterprise Billing & Invoicing ABB", "Identity and Access Management ABB", "Inventory Allocation ABB".
Solution Building Blocks (SBBs) in Phase E & Implementation
Solution Building Blocks (SBBs) represent the physical, tangible realization of ABBs. They are specific commercial software packages, SaaS products, open-source libraries, or bespoke custom software codebases deployed to production.
Examples of SBBs : "Salesforce Service Cloud", "Stripe Invoicing API", "Okta Identity Engine", "Custom Java Spring Boot Microservice v4.2".
Why This Distinction Is Paramount
Prematurely selecting SBBs during Phase C is one of the most destructive architectural anti-patterns. When an enterprise architect specifies "Salesforce" or "SAP" during Phase C without first defining the logical ABBs and interface requirements, the enterprise binds its architecture to the vendor's proprietary data models and commercial limitations. Defining ABBs first ensures that when the enterprise evaluates vendor solutions in Phase E, it does so against an objective, business-aligned functional specification.
Modern Application Architecture Styles & Trade-Off Analysis
Enterprise architects must evaluate various architectural styles when constructing the Target Application Architecture. No single style is universally superior; each embodies distinct architectural trade-offs: Monolithic Modular Monolith Microservices Event-Driven (EDA)
- +---------------+ +---------------------+ +---+ +---+ +---+ +-------+ +-------+
- | UI, Business | | Bounded Modules | |Svc| |Svc| |Svc| |Pub Svc| |Pub Svc|
- | Logic & Data | --> | in Single Runtime | --> +---+ +---+ +---+ --> +-------+ +-------+
- | Single Binary | | Shared/Isolated DB | | | | \ /
- +---------------+ +---------------------+ v v v [ Event Broker ]
- | Relational DB | | Relational DB | [Polyglot Databases] / \
- +---------------+ +---------------------+ (Distributed Comms) +-------+ +-------+
- |Sub Svc| |Sub Svc|
- +-------+ +-------+
- 1. Monolithic Architecture
A single, unified software binary where the user interface, business logic, and data access layers are packaged and executed together against a single centralized database.
Strengths : Simple early development, straightforward end-to-end debugging, simple transactional consistency (ACID).
Weaknesses : High coupling; scaling requires replicating the entire application; deployment bottlenecks where a bug in one component crashes the entire system.
2. Modular Monolith
A structured architectural evolution of the monolith. Code is strictly partitioned into domain-aligned modules with private data schemas and explicit public interfaces, but compiled and deployed as a single runtime process.
Strengths : High domain cohesion without the extreme operational overhead and network latency of distributed microservices.
Weaknesses : Still shares a single deployment pipeline; requires rigorous engineering governance to prevent developers from bypassing module boundaries.
3. Microservices Architecture
A distributed collection of fine-grained, independently deployable services organized around Domain-Driven Design (DDD) bounded contexts. Each microservice encapsulates its own data store (polyglot persistence) and communicates via lightweight network protocols (HTTP/REST, gRPC).
Strengths : Independent scalability, continuous deployment velocity, organizational alignment with autonomous product teams.
Weaknesses : High operational complexity (requires container orchestration, distributed tracing, service meshes), eventual data consistency challenges, distributed transaction failures.
4. Event-Driven Architecture (EDA)
An asynchronous architectural paradigm where decoupled software services communicate by emitting and reacting to domain events via centralized message brokers or event streaming platforms (e.g., Apache Kafka, RabbitMQ).
Strengths : Exceptional horizontal scalability, extreme loose coupling (producers have zero knowledge of consumers), high fault isolation.
Weaknesses : Asynchronous debugging complexity, eventual consistency lag, complex schema evolution governance.
Architectural Comparison Table: Monolith to Event-Driven
- Architectural Attribute Monolithic Modular Monolith Microservices Event-Driven Architecture
- Coupling Degree Extremely High Moderate (Internal Loose) Low (Distributed) Extremely Low (Temporal & Spatial)
Scalability Model Vertical (Scale-Up) Vertical / Coarse Scale-Out Fine-Grained Horizontal Extreme Asynchronous Scale-Out
- Data Consistency Immediate (ACID) Immediate (ACID) Eventual (Sagas) Eventual (Event Sourcing / CQRS)
- Operational Overhead Very Low Low Very High (K8s, Mesh) High (Event Broker Infrastructure)
Failure Blast Radius Entire Application Entire Runtime Single Isolated Service Single Consumer / Isolated Queue
- Deployment Velocity Slow, Batch Cycles Moderate Cycles Rapid, Continuous Continuous, Independent
- Application Integration Patterns and System Boundaries
An application architecture is only as resilient as its integration boundaries. Uncontrolled point-to-point integration creates the infamous "spaghetti architecture" (N(N - 1) / 2 connections), where altering a single system triggers unpredicted ripple effects across the entire enterprise.
Modern integration architectures enforce four primary integration patterns:
API Gateway & Service Proxy : Establishes a unified, secure entry point for external consumers. Enforces centralized authentication (OAuth2 / OIDC), rate limiting, request validation, and protocol translation, shielding internal systems.
Enterprise Service Bus (ESB) / Integration Broker : Provides reliable message routing, protocol transformation, and canonical data model mapping. Ideal for bridging legacy systems with modern platforms, though architects must avoid embedding heavy business logic into the bus.
Asynchronous Messaging & Queues : Employs point-to-point message queues (e.g., AMQP, SQS) for guaranteed, load-leveled task processing where consumers process work at their own pace.
Event Streaming Platforms : Utilizes distributed commit logs (e.g., Apache Kafka) to broadcast continuous streams of immutable business state changes across the enterprise.
Real-World Case Example: Rationalizing an Insurer's Claims Ecosystem
Pinnacle Assurance , a national property and casualty insurer, grew through twelve regional acquisitions over fifteen years. An architecture audit revealed that Pinnacle was operating seven separate claims processing applications , each licensed from different vendors, running on different database engines, and maintained by separate vendor contracts totaling $18.5 million annually.
The enterprise architect launched an Application Portfolio Rationalization initiative using the TIME framework:
Claims System A : Handled 60% of national claims, ran on modern Linux cloud infrastructure, and scored high on technical fitness and business value ( Invest ).
Claims Systems B and C : Mission-critical for high-value commercial accounts, but ran on unsupported 1990s client-server architectures with soaring failure rates ( Migrate ).
Claims System D : A simple, stable utility system for employee internal travel claims ( Tolerate ).
Claims Systems E, F, and G : Handled fewer than 5% of claims, were redundant with System A, and suffered high defect rates ( Eliminate ).
By executing this rationalization roadmap, Pinnacle decommissioned Systems E, F, and G within nine months, migrated Systems B and C into modern microservices wrapping System A, and recovered $9.2 million in recurring annual software licensing costs.
Common Exam Traps & Practitioner Pitfalls
Specifying Vendor Products (SBBs) in Phase C : Part 2 scenario questions frequently offer distracters that recommend selecting specific commercial software (e.g., Salesforce, SAP S/4HANA) as the primary Phase C deliverable. The correct architectural answer focuses on defining vendor-neutral Application Building Blocks (ABBs) and interface requirements.
Dogmatic Microservices Bias : Assuming that microservices are the optimal architecture for all applications is a serious anti-pattern. Scenarios with small development teams, simple transactional domains, or strict low-latency requirements often achieve superior outcomes with Modular Monoliths.
Overlooking the "Eliminate" Quadrant : Failing to actively decommission redundant software in the Eliminate quadrant allows technical debt and vulnerability footprints to compound endlessly.