TOGAF Phase C: Application Architecture Design and Integration

Once the Business Architecture is established in Phase B, the question becomes: which software systems do we need to support those business capabilities and services? That is exactly what Phase C answers.

Phase C covers Information Systems Architecture, which TOGAF divides into two sub-phases: Application Architecture and Data Architecture. This post focuses on Application Architecture — defining the portfolio of applications that the enterprise needs, how those applications interact, and how they need to change to support the target business model.

Application Architecture is often where enterprise architects face the most resistance. Every existing system has owners, users, and embedded workflows. Changing the application landscape means disrupting real people and real processes. Phase C gives you the structured approach to navigate this with confidence.

---

What Is Application Architecture in TOGAF?

Application Architecture provides a blueprint for the individual application systems and their interactions. It describes:

• What applications exist or need to exist
• What each application does and which business services it supports
• How applications share data and trigger each other
• Which applications are candidates for replacement, consolidation, or enhancement
• The target application landscape the organization is working toward

Application Architecture does not define the internal design of any individual application. That is software design work, done by development teams. Phase C defines the application landscape at a higher level of abstraction: what is in the portfolio, what each system is responsible for, and how the portfolio as a whole serves the business.

---

The Objectives of Phase C Application Architecture

1. Develop a Baseline Application Architecture describing the current application landscape
2. Develop a Target Application Architecture aligned to the business capabilities defined in Phase B
3. Perform a Gap Analysis between the two states
4. Identify candidate roadmap components to bridge the gaps
5. Resolve impacts across the architecture landscape and update the Architecture Roadmap

---

Starting Point: Business Services as Application Requirements

The key input to Phase C Application Architecture is the set of business services defined in Phase B. Each business service represents a defined unit of business functionality that must be delivered. The Application Architecture must answer: which application, or combination of applications, will deliver each service?

This approach ensures that application decisions trace directly to business needs rather than to technical preferences or legacy assumptions.

For each business service, Phase C asks:

• Is an existing application already supporting this service? If so, adequately?
• Does an existing application support it partially, requiring enhancement?
• Is no application currently supporting this service, indicating a gap?
• Are multiple applications supporting the same service redundantly, indicating a consolidation opportunity?

---

Building the Application Portfolio Catalog

The Application Portfolio Catalog is the foundational Phase C deliverable. It lists every application in the organization's current landscape with key attributes for each:

• Application name and description: What the system is and what it does
• Business services supported: Which Phase B services this application enables
• Business capabilities supported: Which capabilities from the capability map it contributes to
• Organizational owner: Which business unit owns and is accountable for this application
• Technology stack: The platform, language, and hosting environment
• Integration interfaces: How this application connects to others
• Strategic disposition: Is this application to be retained, enhanced, replaced, or retired?
• Risk and age: Is this a legacy system carrying technical debt?

---

Application Integration Patterns

Modern enterprises run dozens or hundreds of applications, and the way those applications interact is as important as the applications themselves. Phase C documents the integration patterns that connect the application landscape.

Common application integration patterns in enterprise architecture include:

• Point-to-point integration: Applications connect directly to each other via custom interfaces. Simple for small numbers of applications, but creates a complex web as the portfolio grows
• Hub-and-spoke (ESB): A central integration platform (Enterprise Service Bus) mediates all communication between applications. Reduces point-to-point complexity but introduces a central dependency
• API-led integration: Applications expose standardized APIs and consume each other's APIs. Highly flexible and supports digital ecosystem development
• Event-driven integration: Applications publish events and subscribe to events from other applications via a message broker. Decouples producers and consumers, enabling high scalability
• Batch integration: Data is transferred between applications in bulk at scheduled intervals. Common in financial services and legacy environments

The Target Application Architecture defines which integration patterns will be adopted as the enterprise standard, and how the current landscape will migrate toward those patterns.

---

The Application Interaction Matrix

A key Phase C matrix is the Application Interaction Matrix, which maps every significant data flow or functional dependency between applications.

For each pair of applications that interact, the matrix documents:

• The direction of the interaction (which application is the producer and which is the consumer)
• The nature of the data or trigger being exchanged
• The integration pattern used (API call, database read, file transfer, event)
• The frequency and latency characteristics
• Whether the interface is in the baseline, target, or both

This matrix becomes essential in Phase E (Opportunities and Solutions) when planning the sequence of changes to the application landscape.

---

Common Application Architecture Patterns

Phase C uses established application architecture patterns to guide the Target Architecture design. Understanding these patterns is important for both the exam and real-world practice.

Monolithic Architecture

A single, self-contained application that handles all business functions internally. Simple to deploy but difficult to scale and change independently.

Layered Architecture

Applications are structured into horizontal layers (presentation, business logic, data access), each with a defined responsibility. Common in traditional enterprise applications.

Microservices Architecture

The application is decomposed into small, independently deployable services, each responsible for a single business capability. Highly scalable and supports rapid change but requires strong integration and DevOps maturity.

Service-Oriented Architecture (SOA)

Applications expose and consume services via a centralized registry. Closer to TOGAF's concept of business services, making it a natural fit for TOGAF-aligned enterprises.

---

Gap Analysis in Phase C

The Gap Analysis compares the Baseline Application Architecture against the Target to identify:

• Missing applications: Business services the target requires that no current application supports
• Applications to retire: Applications that will no longer be needed in the target state
• Applications to consolidate: Multiple applications doing the same thing that should be replaced by a single, unified system
• Applications to enhance: Applications that will remain but need new capabilities
• Integration gaps: New connections needed or existing connections that must change

Each gap identified feeds into the Architecture Roadmap and influences the migration planning in Phase F.

---

Phase C Application Architecture Deliverables

The formal outputs of Phase C Application Architecture include:

Catalogs

• Application Portfolio Catalog
• Interface Catalog (all integration interfaces between applications)

Matrices

• Application/Organization Matrix: Which business units use which applications
• Application/Function Matrix: Which functions each application supports
• Application Interaction Matrix: How applications communicate with each other

Diagrams

• Application Communication Diagram: Visual map of application interactions
• Application and User Location Diagram: Where applications are hosted and where users access them from
• Software Engineering Diagram: High-level software structure of key applications

---

Real-World Example: E-Commerce Retailer

A national e-commerce retailer's Phase C Application Architecture work reveals:

• Baseline: Three separate systems handle customer orders: a legacy e-commerce platform, a manual phone order system, and a wholesale portal, none of which share inventory data in real time
• Target: A single Order Management System feeds all channels (web, phone, wholesale) and communicates in real time with a unified inventory platform via event-driven integration
• Gaps: No unified Order Management System exists. The inventory platform holds data in a format incompatible with modern APIs. The phone order system needs to be retired or integrated
• Architecture decisions: Procure an off-the-shelf OMS, expose inventory via REST APIs, implement an event broker to coordinate real-time stock updates across channels, retire the phone-order legacy system within 18 months

---

Summary

Phase C Application Architecture defines the blueprint for the software landscape that enables the business. Its core activities are:

• Building the Application Portfolio Catalog from the current state
• Designing the Target Application Architecture driven by Phase B's business services
• Selecting appropriate integration patterns
• Performing a structured Gap Analysis to identify what must change

In the next post, we cover the second sub-phase of Phase C: Data Architecture — defining the logical and physical data models, data governance, and information flows that underpin the application landscape.

For context on how applications connect to business needs, review Phase B Business Architecture which defines the business services that Phase C must support.