4.3 Phase C Application Architecture: Logical Components, Services & Interfaces

4.3 Phase C Application Architecture: Logical Components, Services & Interfaces

Key Takeaway: Phase C Application Architecture defines the software application portfolio, application services, and interface structures required to support target business functions. A core TOGAF distinction separates vendor-neutral Logical Application Components from concrete Physical Application Components, guided by rationalization frameworks like the TIME model.

Application Architecture is the second major domain of Phase C in the TOGAF ADM. While Data Architecture defines the information assets of the enterprise, Application Architecture specifies the software application blueprint—defining the applications required to process data, deliver business capabilities, and expose functional services to internal users and external partners.

---

Logical vs. Physical Application Components

A central concept in TOGAF Application Architecture is the explicit distinction between Logical Application Components (LAC) and Physical Application Components (PAC). This decoupling ensures that the architecture team can analyze required software capabilities without becoming prematurely locked into specific vendor products or custom technology frameworks.

┌────────────────────────────────────────────────────────────────────────┐
│ LOGICAL APPLICATION COMPONENT (LAC)                                    │
│ - Vendor-neutral encapsulation of software capabilities                │
│ - Defines WHAT functional capabilities the application must perform     │
│ - Example: "Customer Relationship Management (CRM) Component"          │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Realized by
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ PHYSICAL APPLICATION COMPONENT (PAC)                                   │
│ - Concrete software product, COTS package, SaaS app, or custom code     │
│ - Defines HOW the capability is deployed using specific technology     │
│ - Example: "Salesforce Enterprise Edition v2024.2 (SaaS)"              │
└────────────────────────────────────────────────────────────────────────┘

Logical Application Component (LAC)

A Logical Application Component represents an abstract, vendor-neutral grouping of software capabilities that perform specific business tasks. It is defined entirely by its functional responsibilities and interfaces, independent of software vendor, programming language, hosting platform, or deployment architecture.

Examples of LACs:

• Claims Processing Component
• Enterprise Service Bus (ESB) Integration Component
• General Ledger Accounting Component
• User Identity & Access Management Component

Physical Application Component (PAC)

A Physical Application Component is a specific, tangible software application product, custom software build, commercial COTS package, or cloud SaaS solution that implements one or more Logical Application Components.

Examples of PACs:

• Salesforce Sales Cloud v2024 (SaaS)
• Custom Java/Spring Boot Microservice container (v3.2.1)
• SAP S/4HANA Finance Module (On-Premises)
• Okta Workforce Identity Cloud

Architectural Comparison: LAC vs. PAC

---

Application Portfolio Categorization & The TIME Framework

Enterprise application portfolios frequently suffer from application sprawl, functional duplication, and technical debt accumulated over decades. During Phase C, application architects analyze baseline applications and apply structured portfolio rationalization.

TOGAF recommends utilizing frameworks such as the TIME Model (Tolerate, Invest, Migrate, Eliminate) to categorize physical applications:

                  High │ ┌───────────────────────┬───────────────────────┐
                       │ │       TOLERATE        │        INVEST         │
                       │ │ High Business Value,  │ High Business Value,  │
                       │ │ Low Technical Quality │ High Technical Quality│
     BUSINESS VALUE    │ ├───────────────────────┼───────────────────────┤
                       │ │       ELIMINATE       │        MIGRATE        │
                       │ │ Low Business Value,   │ Low Business Value,   │
                       │ │ Low Technical Quality │ High Technical Quality│
                   Low │ └───────────────────────┴───────────────────────┘
                       └─────────────────────────────────────────────────
                         Low                 High
                               TECHNICAL QUALITY

1. Tolerate

• Characteristics: Applications providing high, critical business value but built on aging, obsolete technical architectures.
• Strategy: Retain the application without major investments; maintain minimal operational support while planning long-term replacement.

2. Invest

• Characteristics: Modern, high-performing applications that deliver strong business value and align with technology standards.
• Strategy: Prioritize strategic funding, expand feature sets, and integrate with cloud ecosystem services.

3. Migrate / Re-architect

• Characteristics: Applications representing high technical quality or modern infrastructure, but misaligned with core business processes or poorly adopted.
• Strategy: Re-architect, consolidate, or migrate software modules to better support strategic business capabilities.

4. Eliminate

• Characteristics: Redundant, outdated applications providing low business value and incurring high operational maintenance costs.
• Strategy: Decommission, archive underlying data, and retire the application package during Phase E.

---

Application Services, APIs, and Interface Architecture

Modern Application Architecture relies heavily on service orientation and microservice paradigms. Applications interact by exposing Application Services accessible through standardized interfaces.

Key interface architecture principles include:

• Loose Coupling: Applications interact via standardized contracts (e.g., RESTful APIs, OpenAPI specifications, gRPC contracts) rather than shared database tables or tightly bound remote procedure calls.
• Encapsulation: Internal application logic, object models, and database schemas remain hidden behind interface boundaries.
• Event-Driven Integration: Leveraging message brokers (e.g., Apache Kafka, RabbitMQ) for asynchronous pub/sub messaging, enabling resilient, decoupled system interactions.

---

Core Application Architecture Artifacts

TOGAF Phase C requires architects to produce standardized artifacts documenting the application landscape:

1. Application Portfolio Catalog

A comprehensive inventory of all software applications operating across the enterprise. Attributes include application name, owner, business capability supported, technology stack, lifecycle status (Active, Deprecated, Target), hosting model (On-Premises, IaaS, PaaS, SaaS), and annual licensing cost.

2. Application / Function Matrix

Maps physical or logical application components against business functions defined in Phase B. This matrix identifies:

• Functional Gaps: Business functions with no supporting application capability.
• Application Redundancy: Multiple applications supporting the exact same business function across different divisions.

3. Application Communication Diagram

Visually models inter-application connectivity, illustrating data flows, communication protocols (HTTPS, SFTP, AMQP), integration middleware, and security boundaries.

4. Interface Catalog

A detailed specification register cataloging all application interfaces. Details include Interface ID, Provider Application, Consumer Application, Communication Protocol, Data Schema/Payload format, Execution Frequency (Real-Time Synchronous vs. Asynchronous Batch), and Authentication Standard (OAuth2, mTLS).

---

Conducting Application Architecture Gap Analysis

To complete Phase C Application Architecture, architects execute a Gap Analysis comparing the Baseline Application Portfolio against the Target Application Portfolio.

Architects create an Application Gap Matrix to document:

• Retired Applications: Applications slated for elimination under the TIME framework.
• New Applications: Required software components (COTS packages, custom microservices, SaaS modules) to fulfill new business capabilities.
• Modified Applications: Existing applications requiring API additions, major refactoring, or cloud migration.

The resulting gaps form key inputs to the Phase C Architecture Requirements Specification and generate candidate work packages for Phase E.