6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First

6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First

Phase C of the TOGAF Architecture Development Method (ADM) addresses Information Systems Architectures, encompassing two distinct yet deeply complementary disciplines: Data Architecture and Application Architecture. While Data Architecture governs the structure, governance, and dissemination of an enterprise's logical and physical information assets, Application Architecture defines the structural blueprint of software applications required to process that data and automate business capabilities. In modern digital enterprises, where technical debt and software sprawl frequently hinder strategic agility, Phase C Application Architecture provides the analytical rigor required to design stable, interoperable, and business-aligned application ecosystems.

---

Objectives of Phase C Application Architecture

The primary objective of Phase C Application Architecture is to develop the Target Application Architecture for the enterprise and determine whether to model the Baseline Application Architecture first or leap directly to the target vision. TOGAF states two objectives for the application part of Phase C: develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns; and identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures. In practice the work involves:

1. Define the Target Application Architecture: Structure the logical Application Building Blocks (ABBs), application services, and software interactions needed to automate and deliver the business capabilities documented in Phase B.
2. Establish System Boundaries and Responsibilities: Clarify which applications own specific business functions and master data sets, eliminating ambiguous operational responsibilities and duplicated software features.
3. Identify Candidate Architecture Roadmap Components: Formulate concrete, capability-based work packages and transition requirements based on the gap analysis between baseline and target application states for downstream refinement in Phase E (Opportunities and Solutions).
4. Ensure Interoperability and Loose Coupling: Design standard integration interfaces, API contracts, and communication protocols that decouple application components, allowing individual systems to evolve independently without cascading outages.

---

Application Architecture vs. Software Engineering and Design

A perennial point of confusion for emerging architects—and a favorite subject for OGEA-103 exam traps—is the clear distinction between Enterprise Application Architecture and Software Engineering / Software Design.

Enterprise Application Architecture operates at the portfolio and system boundary level. It treats individual software systems as modular building blocks within a broader organizational ecosystem. It asks: What business capability does this application automate? What data entities does it read, create, or update? Which upstream systems invoke its services, and over what standard integration contracts?

In contrast, Software Engineering and Software Design operate inside the system boundary. Software design governs low-level implementation details, such as object-oriented class inheritance hierarchies, design patterns (e.g., Factory, Singleton, Observer), algorithmic complexity, memory management, unit test frameworks, and physical database schemas.

Enterprise architects must resist the temptation to micromanage internal software design. Dictating whether an engineering team uses a specific programming language library or internal class structure violates separation of concerns and creates bureaucratic friction without delivering enterprise value.

---

Inputs and Outputs of Phase C Application Architecture

Phase C does not occur in a vacuum; it relies on strategic artifacts authored in earlier ADM phases and produces foundational models that drive Technology Architecture (Phase D) and Migration Planning (Phases E and F).

Critical Inputs

• Request for Architecture Work & Architecture Vision (Phase A): Establishes business goals, executive constraints, strategic drivers, and authorized scope boundaries.
• Statement of Architecture Work (Phase A): Defines the contractual schedule, deliverables, and resource commitments governing the architectural engagement.
• Business Architecture Deliverables (Phase B): The essential foundation. Specifically, the Business Capability Map, Value Streams, Business Function Catalog, and Organization Map. Application architectures cannot be constructed without knowing what business capabilities they must automate.
• Data Architecture Models (Phase C): Conceptual and Logical Data Models, Data Entity/Business Function Matrices, and Data Dissemination Diagrams developed concurrently or iteratively with Application Architecture.
• Architecture Principles: Enterprise-wide rules established in the Preliminary Phase, including principles regarding application independence, open standards, and security compliance.

Key Outputs

• Baseline Application Architecture Description (if deemed necessary by the scoping strategy).
• Target Application Architecture Description, detailing logical Application Building Blocks (ABBs), application services, and external interfaces.
• Application Architecture Views, addressing specific stakeholder concerns through Catalogs (e.g., Application Portfolio Catalog), Matrices (e.g., Application/Organization Matrix, Application/Function Matrix), and Diagrams (e.g., Application Communication Diagram).
• Application Gap Analysis Matrix, highlighting retained, modified, retired, and newly required systems.
• Candidate Architecture Roadmap Components, documenting technical debt remediation, replacement projects, and integration initiatives to feed Phase E.

---

The Phase C Nine-Step ADM Progression

The TOGAF Standard outlines a structured nine-step method for executing Phase C Application Architecture:

1. Select Reference Models, Viewpoints, and Tools: Identify suitable industry reference models (e.g., BIAN in banking, eTOM in telecom), architectural viewpoints aligned to stakeholder concerns, and modeling tools.
2. Develop Baseline Application Architecture Description: Document the existing application landscape to the level of detail necessary to support the target state decisions and gap analysis.
3. Develop Target Application Architecture Description: Model the future state logical applications, boundaries, and interactions required to support target business capabilities.
4. Perform Gap Analysis: Cross-examine baseline and target architectures to identify missing capabilities, retired systems, and necessary enhancements.
5. Define Candidate Roadmap Components: Translate identified gaps into prioritized architectural work packages.
6. Resolve Impacts Across the Architecture Landscape: Evaluate how the target application model impacts other architecture domains (e.g., infrastructure demands for Phase D, organizational retraining for Phase B).
7. Conduct Formal Stakeholder Review: Present application models and trade-off analyses to business and technical stakeholders to secure buy-in.
8. Finalize the Application Architecture: Incorporate stakeholder feedback, ensure traceability to business requirements, and validate alignment with architecture principles.
9. Create the Architecture Definition Document: Package the application models, gap analysis, and candidate roadmap components into the formal deliverable.

---

The Architectural Dilemma: Baseline-First vs. Target-First

A critical decision facing the practitioner in Step 1 is determining the sequencing of baseline and target modeling. The TOGAF Standard does not mandate an immutable sequence; architects may document the baseline first, design the target first, or adopt an iterative hybrid approach.

                                [ Architectural Context ]
                                           |
               +---------------------------+---------------------------+
               |                                                       |
      [ Complex Legacy ]                                      [ Greenfield / Pivot ]
      [ Severe Compliance Risk ]                              [ Disruptive Urgency ]
               |                                                       |
               v                                                       v
     Baseline-First Strategy                                 Target-First Strategy
  (Map dependencies & liabilities)                        (Design target capabilities)
               |                                                       |
               v                                                       v
    Target Architecture Design                              Baseline Gap Verification
               |                                                       |
               +---------------------------> + <-----------------------+
                                           |
                                           v
                                [ Application Gap Analysis ]

The Baseline-First Approach

In a Baseline-First approach, the architecture team undertakes a rigorous discovery and documentation of existing software assets before attempting to formulate the future state. This involves cataloging all installed software, mapping runtime interfaces, analyzing batch data feeds, and reviewing software license agreements.

When to Use Baseline-First:

• Heavy Legacy Technical Debt: The enterprise relies on decades-old monolithic systems with undocumented point-to-point batch interfaces and "tribal knowledge" dependencies.
• High Operational and Safety Risk: Disruption of existing services carries catastrophic consequences (e.g., core payment clearings in banking, avionics telemetry, patient telemetry in acute healthcare).
• Strict Regulatory Compliance: Auditing mandates require verifiable accounting of data lineage, software licenses, and security vulnerability profiles.
• Mergers and Acquisitions (M&A): Two distinct application portfolios must be rationalized and consolidated, requiring full visibility into overlapping baseline assets.

The Target-First Approach

In a Target-First approach, the architecture team begins by designing the ideal future-state application architecture based directly on the business capabilities and value streams established in Phase B, without being constrained by existing systems. Only after the target architecture is envisioned does the team assess the baseline to identify what can be salvaged, refactored, or discarded.

When to Use Target-First:

• Greenfield Ventures & Startups: Brand-new business units, subsidiaries, or digital-native enterprises where no legacy systems exist.
• Disruptive Business Model Pivots: The business is abandoning an obsolete operating model to enter a completely different market (e.g., a traditional print publisher pivoting to on-demand digital streaming).
• High Business Urgency & Speed-to-Market: Fast-moving competitive disruption requires rapid prototyping of new capabilities where spending months documenting doomed legacy systems represents a wasteful sunk cost.
• Total Replacement Strategy: Executive leadership has already decided to retire the legacy core entirely in favor of modern cloud SaaS or COTS platforms.

---

Decision Matrix: Baseline-First vs. Target-First

To balance risk, velocity, and architectural rigor, practitioners evaluate the operating environment across six fundamental dimensions:

---

Core Application Architecture Principles

To govern application modeling and prevent subjective technical debates, enterprise architects leverage foundational application principles established in the Preliminary Phase:

1. Technology Independence (one of TOGAF's example principles): Applications should be decoupled from the underlying platform and infrastructure technologies. Business logic must not be tightly coupled to a specific hardware operating system or proprietary cloud provider API.
2. Loose Coupling & High Cohesion: Application Building Blocks must have tightly focused, single-purpose business responsibilities (high cohesion) while exposing standard, stable interface contracts that minimize dependencies on external systems (loose coupling).
3. Common Use & Reusability: If an application function is required by multiple business units (e.g., customer identity verification, payment settlement), it must be developed as a shared enterprise service rather than duplicated across divisional silos.
4. Data Mastership & Single Point of Authority: Each core data entity (e.g., Customer, Account, Product) must have a designated application of record that owns transactional creation, updates, and integrity validation.

---

Real-World Case Example: Global Logistics Modernization

Consider TransGlobal Freight, a worldwide shipping conglomerate operating across 40 countries. Over thirty years, TransGlobal accumulated 28 distinct regional dispatch systems, dozens of custom EDI translation scripts, and three separate core tracking mainframes. Executive leadership launched an enterprise transformation to deploy an integrated, real-time tracking platform.

The lead enterprise architect initially faced strong pressure from business leaders to execute a Target-First strategy, designing a modern event-driven microservices architecture immediately. However, an architectural risk assessment revealed that TransGlobal's global customs clearance operations relied on undocumented COBOL batch jobs executed every midnight across the legacy mainframes. Disrupting these jobs would cause container ships to be impounded at international ports, incurring millions of dollars in regulatory fines.

The architect executed a pragmatic, hybrid strategy. First, the team executed a timeboxed Baseline-First discovery strictly focused on the core mainframe interfaces and customs data flows. Once these critical operational boundaries and data dependencies were cataloged, the team switched to a Target-First approach to design the future-state event-driven tracking services. By using the baseline catalog to establish encapsulation wrappers (the Strangler Fig pattern), TransGlobal modernized its dispatch architecture without a single day of port clearance downtime.

---

Common Exam Traps & Practitioner Pitfalls

• Conflating Application Architecture with Software Design: Exam scenarios frequently present proposals detailing database column indexing, microservice thread pools, or programming language class hierarchies as Phase C deliverables. These are distracters; Phase C produces logical Application Building Blocks (ABBs), system boundaries, and service interfaces.
• The "Boiling the Ocean" Baseline Trap: Documenting 100% of every internal script, table, and batch routine in an enterprise before starting target architecture work is an anti-pattern. Baseline modeling should proceed only to the depth necessary to evaluate gaps and manage migration risks.
• Ignoring Data Architecture Synchronization: Developing an Application Architecture without continuous cross-checks against Data Architecture produces systems that cannot effectively store, query, or secure enterprise information entities.
• Bypassing Architecture Principles: Selecting commercial software packages solely because of aggressive vendor sales pitches, without verifying conformance to enterprise application principles (such as loose coupling and open APIs), leads to severe vendor lock-in.