4.1 Information Systems Architectures Overview & Phase C Strategy

4.1 Information Systems Architectures Overview & Phase C Strategy

Key Takeaway: Phase C of the TOGAF Architecture Development Method (ADM) addresses Information Systems Architectures, combining Data Architecture and Application Architecture. TOGAF allows architects flexibility in choosing execution order—Data-first, Application-first, or Parallel—depending on business drivers, legacy constraints, and package implementation strategies.

Phase C of the TOGAF ADM focuses on developing the Information Systems Architectures for an enterprise architecture project. Positioned directly between Phase B (Business Architecture) and Phase D (Technology Architecture), Phase C defines how the enterprise's data assets and application software systems will be structured, managed, and integrated to realize the target business capability models, value streams, and business processes established in Phase B.

---

Why Phase C Combines Data and Application Architectures

In the TOGAF ADM, Information Systems Architectures encompasses two distinct but deeply interdependent architectural domains:

1. Data Architecture: Defines the structure of an enterprise's logical and physical data assets and data management resources. It describes how data is created, stored, transformed, moved, governed, and secured across the enterprise.
2. Application Architecture: Defines the blueprint for the individual application systems to be deployed, their interactions, interfaces, application services, and their relationships to core business processes.

TOGAF intentionally groups these two domains under Phase C as Information Systems Architectures because applications and data cannot be designed effectively in isolation. Applications are the transactional engines and functional containers that manipulate, process, and present data; conversely, data provides the operational context, persistent state, and strategic information value without which software applications are merely empty shells.

Combining Data and Application Architectures within Phase C enables architecture teams to maintain tight alignment between business software services and underlying enterprise data entities, preventing common anti-patterns such as defining software features without understanding master data ownership or designing data stores without identifying the applications responsible for their lifecycle.

---

Sequencing Strategies: Data-First vs. Application-First vs. Parallel Execution

Although Phase C is presented as a single phase in the ADM cycle, TOGAF explicitly recognizes that enterprise architecture projects vary significantly in their strategic priorities and technical contexts. Consequently, TOGAF offers complete flexibility regarding the execution order of Data Architecture and Application Architecture.

Architects can select from three primary sequencing approaches:

                          ┌───────────────────────────┐
                          │   Phase B Completed       │
                          │ Target Business Arch      │
                          └─────────────┬─────────────┘
                                        │
                         ┌──────────────┴──────────────┐
                         ▼                             ▼
              ┌─────────────────────┐       ┌─────────────────────┐
              │  Data Architecture  │       │    Application      │
              │       First         │       │ Architecture First  │
              └──────────┬──────────┘       └──────────┬──────────┘
                         │                             │
                         ▼                             ▼
              ┌─────────────────────┐       ┌─────────────────────┐
              │    Application      │       │  Data Architecture  │
              │ Architecture Second │       │       Second        │
              └──────────┬──────────┘       └──────────┬──────────┘
                         │                             │
                         └──────────────┬──────────────┘
                                        │
                                        ▼
                          ┌───────────────────────────┐
                          │    Phase C Consolidated   │
                          │     Interoperability      │
                          │      & Gap Analysis       │
                          └───────────────────────────┘

1. Data Architecture First (Data-Driven Strategy)

In a Data-first sequence, the architecture team models data entities, logical schemas, data governance frameworks, and data flows prior to defining software applications and service interfaces.

• Primary Rationale: Data outlives individual software applications. While commercial applications, frameworks, and custom software modules are frequently replaced or modernized every 5 to 10 years, core business data entities (such as Customer, Product, Account, and Order) persist throughout the lifespan of the enterprise.
• When to Choose Data-First:
  • Data-intensive enterprises, such as financial institutions, insurance carriers, or healthcare providers where regulatory compliance, risk reporting, and data governance take precedence.
  • Organizations undertaking Master Data Management (MDM), enterprise data warehousing, advanced analytics, or artificial intelligence (AI/ML) transformations.
  • Scenarios where data sovereignty, data security classification, and privacy regulations (such as GDPR or HIPAA) strictly govern system design.

2. Application Architecture First (Application-Driven Strategy)

In an Application-first sequence, the architecture team defines logical application components, application portfolios, process-to-application mappings, and integration interfaces before detailed data modeling occurs.

• Primary Rationale: Business functions and operational processes drive user software interactions. When an enterprise selects Commercial Off-The-Shelf (COTS) software solutions, Enterprise Resource Planning (ERP) packages, or Software-as-a-Service (SaaS) platforms (e.g., SAP, Salesforce, Workday), the application package arrives with pre-packaged data models and schemas that dictate data structures.
• When to Choose Application-First:
  • Package-driven enterprise transformations where COTS or SaaS software selection dictates underlying database structures.
  • Business process automation engagements where software user interfaces and rapid workflow deployment are the primary strategic drivers.
  • Environments undergoing legacy application replacement where existing database schemas are tightly coupled to vendor software binaries.

3. Parallel Execution (Iterative / Agile Strategy)

In a parallel sequence, dedicated sub-teams work concurrently on Data Architecture and Application Architecture, continuously exchanging architectural artifacts through iterative feedback loops.

• Primary Rationale: Accelerates architecture cycle time and ensures real-time alignment between application APIs and logical data schemas.
• When to Choose Parallel Execution:
  • Agile enterprise architecture teams operating within continuous delivery frameworks.
  • Complex digital transformations where cross-functional architecture teams collaborate to design cloud-native microservices and domain-driven design (DDD) bounded contexts.

Strategy Selection Criteria Matrix

---

Phase C Shared Inputs, Governance, and Deliverables

Core Inputs to Phase C

• Approved Architecture Vision (Phase A): Statement of Architecture Work, enterprise principles, and strategic business goals.
• Target Business Architecture (Phase B): Business capability maps, value streams, business organization structure, and baseline/target business processes.
• Architecture Repository Assets: Existing enterprise standards, reusable reference architectures (such as TOGAF Integrated Information Infrastructure Reference Model - III-RM), and industry data models (e.g., BIAN for banking, TM Forum for telecom).

Phase C Governance and Stakeholder Engagement

Phase C requires continuous governance to manage architectural trade-offs. Key stakeholders—including Chief Data Officers (CDOs), Chief Information Officers (CIOs), lead application architects, data privacy officers, and security engineers—must validate that proposed information systems satisfy both functional business capabilities and non-functional requirements (security, scalability, performance, and interoperability).

Consolidated Outputs and Deliverables

Upon completing Phase C, the architecture team produces:

1. Target Data Architecture: Conceptual/logical data models, data governance blueprints, data entity matrix, and data security controls.
2. Target Application Architecture: Application portfolio catalog, logical/physical component blueprints, interface catalog, and API architectures.
3. Consolidated Phase C Gap Analysis: Clear identification of gaps, redundancies, obsolete systems, and missing data attributes across both domains.
4. Candidate Architecture Roadmap Components: Discrete architectural work packages (e.g., "Implement Enterprise MDM Hub", "Decommission Legacy Mainframe Billing System") passed directly into Phase E (Opportunities & Solutions) for transition planning.