Section 1: Phase C Overview
Phase C — Information Systems Architecture — is the third architectural domain phase of the ADM, following Phase B (Business Architecture) and preceding Phase D (Technology Architecture). It is unique in that it contains two sub-phases: Data Architecture (Phase C-Data) and Application Architecture (Phase C-Application). Either sub-phase may be addressed first, but TOGAF recommends Data before Application.
Develops the Baseline and Target architecture for the Information Systems domains — Data and Application — that support the business capabilities defined in Phase B. Produces artifacts that describe what data exists, how it is structured and governed, which applications exist, and how those applications interact with each other and with business processes.
| Attribute | Detail |
|---|---|
| Purpose | Define Baseline and Target Data and Application architectures that enable the business capabilities identified in Phase B |
| Key Inputs | Architecture Vision, Statement of Architecture Work, Business Architecture (Phase B outputs), Architecture Principles, existing data and application inventories |
| Key Outputs | Baseline & Target Data Architecture; Baseline & Target Application Architecture; Gap Analysis (Data); Gap Analysis (Application); updated Architecture Definition Document; updated Architecture Requirements Specification |
| Sub-Phase Order | Data Architecture first (recommended), then Application Architecture — order may be reversed where justified |
Section 2: Data Architecture (Phase C-Data)
Describes the structure of an organisation's logical and physical data assets and data management resources. It defines how data is collected, stored, arranged, integrated, and put to use within the enterprise, ensuring that data is treated as a strategic enterprise asset.
Data Architecture Key Artifacts
| Artifact Type | Artifact Name | Description |
|---|---|---|
| Catalogs | Data Entity / Data Component Catalog | Inventory of all data entities and the components that realise them |
| Data Dictionary | Definitions, data types, ownership, and quality rules for each data element | |
| Matrices | Data Entity / Business Function Matrix | Maps which data entities are created, read, updated, or deleted (CRUD) by which business functions |
| Application / Data Matrix | Maps which applications create or consume which data entities | |
| Diagrams | Conceptual Data Diagram | High-level view of key data entities and relationships (no implementation detail) |
| Logical Data Diagram | Entity-relationship model showing attributes, keys, and associations — independent of technology | |
| Data Dissemination Diagram | Shows how data entities flow between logical application components | |
| Data Security Diagram | Maps data entities to security policies, classifications, and access controls | |
| Data Migration Diagram | Illustrates how data moves from source systems to target systems during migration | |
| Data Lifecycle Diagram | Describes how data entities are created, maintained, archived, and retired |
Five Core Data Principles
- Data is an Asset: Data has real value; it must be managed with the same discipline as financial or physical assets. Data owners are accountable for quality and access.
- Data is Shared: Data is a shared enterprise resource, not owned by individual applications or departments. Systems must share data rather than duplicate it.
- Data is Accessible: Data is available to authorised users and applications at the right time and in the right format to support business decisions.
- Data Trustee: Each data element has a named trustee (data steward) responsible for its accuracy, completeness, and timeliness.
- Common Vocabulary and Data Definitions: Data definitions are consistent and understood enterprise-wide; a common glossary prevents semantic ambiguity across business units.
Master Data Management (MDM) in Enterprise Context
Master Data Management ensures that an enterprise's most critical shared data — customers, products, suppliers, employees — has a single authoritative source (the "golden record"). MDM programmes are directly enabled by the Data Architecture and are a key deliverable of Phase C-Data in large enterprises. Key MDM concerns include: identifying master data domains, selecting a consolidation style (registry, consolidation, coexistence, or centralised), and establishing data governance policies that span business units.
TOGAF recommends completing Data Architecture before Application Architecture in Phase C. The rationale: applications exist to create, read, update, and delete data; therefore, understanding the data model first ensures that application decisions are driven by data requirements, not the reverse. This sequence is a direct Part 1 recall question.
Section 3: Application Architecture (Phase C-Application)
Describes the individual application systems deployed, their interactions and relationships to each other, and their relationships to core business processes. It provides a blueprint for the application layer that supports the business and consumes or produces data assets defined in the Data Architecture.
Application Architecture Key Artifacts
| Artifact Type | Artifact Name | Description |
|---|---|---|
| Catalogs | Application Portfolio Catalog | Complete inventory of all application systems in the enterprise — baseline and target |
| Interface Catalog | Inventory of all interfaces between application components, including protocols and data exchanged | |
| Matrices | Application / Organisation Matrix | Maps applications to the organisational units that own or use them |
| Application Interaction Matrix | Tabular view of which applications interact with which other applications | |
| Application / Function Matrix | Maps business functions to the applications that support them | |
| Application / User Location Matrix | Maps applications to the geographic or organisational locations where they are used | |
| Diagrams | Application Communication Diagram | Shows information flows and communication paths between application components |
| Application and User Location Diagram | Depicts where applications are deployed relative to user and data locations | |
| Application Use-Case Diagram | Shows actors (users/systems) and the use cases they interact with | |
| Enterprise Manageability Diagram | Illustrates how applications are monitored, managed, and supported | |
| Process / Application Realisation Diagram | Maps business processes to the application components that realise them | |
| Software Engineering Diagram | Shows internal structure of application components (layers, modules, packages) | |
| Application Migration Diagram | Maps source applications to target applications during transition | |
| Software Distribution Diagram | Shows how software is distributed across the physical technology environment |
Application Integration Patterns
TOGAF Phase C-Application must address how applications communicate. Common integration patterns that appear in enterprise architecture practice and Part 2 scenarios include:
- Point-to-Point: Direct connections between systems; simple but creates tight coupling and an unmanageable "spaghetti" topology at scale.
- Hub-and-Spoke (ESB): A central Enterprise Service Bus mediates all integration; reduces coupling but creates a single point of failure risk.
- Publish-Subscribe (Event-Driven): Applications publish events to a broker; consumers subscribe to events they need. Decouples producers and consumers; suits real-time and asynchronous flows.
- API Gateway: A managed facade exposing standardised REST or GraphQL APIs; enables controlled access to application capabilities for internal and external consumers.
SOA and Microservices in TOGAF Context
Service-Oriented Architecture (SOA) is explicitly referenced in the TOGAF Standard as a valid Application Architecture style. SOA organises application capabilities as reusable, loosely coupled services with defined contracts. Microservices — a more granular evolution of SOA — are treated in TOGAF as an architectural pattern that can be recommended within Phase C when the Target Architecture calls for high scalability and independent deployability. Both patterns must be documented in Application Communication Diagrams and Interface Catalogs.
Application–Data Relationship Diagram
Section 4: Gap Analysis for Phase C
Gap Analysis in Phase C compares the Baseline Architecture (current state) to the Target Architecture (desired future state) for both the Data and Application sub-phases. The output feeds directly into Phase E (Opportunities & Solutions) where work packages are defined to close the gaps.
Application Rationalization
A key activity within the Application gap analysis is application rationalization — evaluating the current application portfolio and deciding the disposition of each application:
| Disposition | Meaning | When to Apply |
|---|---|---|
| Retire | Decommission the application; capabilities no longer needed or superseded | Duplicate applications, end-of-life systems, capabilities absorbed by another app |
| Retain | Keep the application as-is in the target state | Application meets needs, low risk, replacement cost not justified |
| Replace | Swap the application for a different system that better meets requirements | Capability gaps, vendor end-of-support, technology obsolescence |
| Re-platform | Move the application to a new platform (e.g., cloud) without major functional change | Infrastructure modernisation, cost reduction, scalability requirements |
Data Consolidation Gaps
Data gap analysis typically identifies: data entities present in baseline that are not needed in target (to be deprecated); entities required in target but not yet captured (to be created); duplicate data stores that must be consolidated into a single authoritative source; and data quality issues that must be remediated before migration. Each gap becomes a candidate work package in Phase E.
The four dispositions (Retire, Retain, Replace, Re-platform) are Part 1 recall items. In Part 2 scenarios, you may be asked to recommend a disposition for a given application. Match the scenario signals: "end of vendor support" = Replace; "moving to cloud" = Re-platform; "functionality absorbed by new system" = Retire; "strategic system meeting all requirements" = Retain.
Section 5: Industry Examples
Banking: Core Banking Application Architecture
A retail bank's Application Architecture typically centres on a core banking system (e.g., Temenos, Finacle, FIS) as the system of record for accounts, transactions, and products. Surrounding applications — digital banking channels, payment gateways, CRM, risk management, and regulatory reporting — integrate via an API gateway or ESB. Phase C would document the Application Portfolio Catalog covering all these systems, Application Interaction Diagrams showing integration flows, and the Application/Data Matrix linking transaction and customer master data to each system.
Healthcare: EHR Data Architecture and HL7 FHIR
In healthcare, the Data Architecture revolves around the Electronic Health Record (EHR) as the master data store for patient information. Data Architecture artifacts define patient, encounter, observation, and medication as canonical data entities. The HL7 FHIR (Fast Healthcare Interoperability Resources) standard defines how these entities are structured and exchanged between clinical applications (EHR, laboratory, pharmacy, imaging). Phase C-Data would produce a Conceptual Data Diagram showing FHIR resource relationships, a Data Security Diagram mapping patient data to HIPAA classifications, and a Data Dissemination Diagram showing how patient records flow across care settings.
Cloud: Cloud-Native Application Architecture Patterns
Cloud-native target architectures in Phase C typically adopt microservices (each service owns its data store), containerisation (Docker/Kubernetes), and event-driven integration (Kafka, Azure Service Bus). Phase C-Application documents the transition from a monolithic baseline application to a target microservices Application Architecture using Application Migration Diagrams, Software Engineering Diagrams (showing service decomposition), and Application Communication Diagrams (showing event flows). Application rationalization decisions include re-platforming existing apps to containers and replacing tightly coupled modules with cloud-native services.
Section 6: Exam Tips for Phase C
- Tip 1 — Order: Data Architecture comes before Application Architecture in the recommended TOGAF sequence.
- Tip 2 — Both are Phase C: Data AND Application are both developed in Phase C; Technology is Phase D. Never put Application Architecture in Phase D.
- Tip 3 — Artifacts by type: Know the difference between Catalogs (inventories), Matrices (cross-mapping tables), and Diagrams (visual representations). Part 1 tests this classification.
- Tip 4 — Application/Data Matrix: This is the key artifact linking Phase C-Data to Phase C-Application. It shows the CRUD relationship between apps and data entities.
- Tip 5 — Gap = Work Package: Every gap identified in Phase C feeds into Phase E work packages. The gap analysis is not just a comparison — it drives the Roadmap.
- Tip 6 — Flexibility is explicit: TOGAF states the order of Data and Application sub-phases may be reversed. Part 2 scenarios may test whether you recognise this flexibility.
Revision Summary — Chapter 05
- Phase C covers Information Systems Architecture, comprising two sub-phases: Data Architecture and Application Architecture (Data recommended first).
- Data Architecture describes the structure of logical and physical data assets; key artifacts include the Data Dictionary, Conceptual/Logical Data Diagrams, and Data Entity/Business Function Matrix.
- The Application/Data Matrix is the critical cross-cutting artifact that links both sub-phases, showing which applications create or consume which data entities.
- Application Architecture describes deployed application systems, their interactions, and relationships to business processes; key artifacts include the Application Portfolio Catalog and Application Communication Diagram.
- Five core data principles — Data is an Asset, Shared, Accessible; Data Trustee; Common Vocabulary — must be defined and enforced across Phase C deliverables.
- Application rationalization categorises each application into one of four dispositions: Retire, Retain, Replace, or Re-platform.
- Phase C Gap Analysis for both data and applications feeds directly into Phase E work packages, which are sequenced and prioritised in Phase F.
- SOA and microservices are valid Application Architecture styles in TOGAF; integration patterns (point-to-point, ESB, event-driven, API gateway) must be documented in Interface Catalogs and Communication Diagrams.
Practice Questions
Five exam-style questions covering Phase C. Click a question to reveal the answer and explanation.
A. Phase C contains Application Architecture only; Data Architecture is developed in Phase D
B. Phase C contains both Data Architecture and Application Architecture, with Data recommended first
C. Phase C contains Technology Architecture and Application Architecture
D. Phase C contains Business Architecture and Data Architecture, always performed in that fixed order
Explanation: Option B is correct. Phase C — Information Systems Architecture — contains two sub-phases: Data Architecture (Phase C-Data) and Application Architecture (Phase C-Application). TOGAF recommends performing Data Architecture before Application Architecture because applications exist to process data, so the data model should drive application design. However, the order may be reversed if the organisation's circumstances justify it. Options A and C are wrong because Technology Architecture belongs to Phase D. Option D is wrong because Business Architecture is Phase B.
A. Conceptual Data Diagram
B. Data Dictionary
C. Data Entity / Business Function Matrix
D. Data Dissemination Diagram
Explanation: Option C is correct. The Data Entity / Business Function Matrix is the artifact that cross-references data entities against business functions, typically using CRUD notation (Create, Read, Update, Delete). This is a matrix artifact, distinguishing it from diagrams (A, D) and catalogs (B). The Conceptual Data Diagram shows entity relationships at a high level; the Data Dictionary defines data element attributes; the Data Dissemination Diagram shows data flows between application components.
A. Retire — the system is no longer needed
B. Replace — the system will be replaced by a different system
C. Retain — the system continues in the target state
D. Re-platform — the system is moved to a new technology platform
Explanation: Option B is correct. "Replace" means the existing application is swapped for a different system that better meets requirements. In this scenario, the legacy lab system is being replaced by a new cloud-based lab platform — it is a different application, not simply moved to a new infrastructure. Re-platform (D) would apply if the same application were migrated to a cloud runtime without functional change. Retire (A) applies when the capability is no longer needed. Retain (C) means no change in the target state.
A. Data Dissemination Diagram
B. Application Communication Diagram
C. Logical Data Diagram
D. Software Distribution Diagram
Explanation: Option A is correct. The Data Dissemination Diagram shows how data entities flow between logical application components — it is the data-centric view of inter-application flows and belongs to Phase C-Data. The Application Communication Diagram (B) shows information flows and communication paths between applications from an application-centric perspective. The Logical Data Diagram (C) shows entity-relationship structure, not flows. The Software Distribution Diagram (D) shows how software is distributed across the physical infrastructure.
A. A database technology product used to store and retrieve master records
B. A Phase D activity that provisions master data across the technology infrastructure
C. A governance framework for managing architecture principles in the Preliminary Phase
D. A discipline that ensures critical shared data has a single authoritative source (golden record), enabled by the Data Architecture defined in Phase C
Explanation: Option D is correct. MDM is a discipline — not a specific technology product (A) — that ensures the enterprise's most critical shared data (customers, products, employees) has one authoritative source. In TOGAF, MDM is enabled by the Data Architecture developed in Phase C: the architect identifies master data domains, establishes data ownership, and designs the authoritative source as part of the target Data Architecture. MDM is not a Phase D activity (B) and is not related to architecture principles (C).