5.2 Phase C: Information Systems Architectures — Data & Application

5.2 Phase C: Information Systems Architectures — Data & Application

Phase C develops the Information Systems Architectures — the Data Architecture and the Application Architecture — that support the agreed Architecture Vision. The Foundation syllabus asks you to describe the objectives of Phase C for Data Architecture and Application Architecture, so learn both pairs.

---

Objectives of Phase C

Phase C as a whole aims to develop the Target Information Systems (Data and Application) Architecture, describing how the Information Systems Architecture will enable the Business Architecture and the Architecture Vision, and to identify candidate Architecture Roadmap components based on the gaps. The standard states separate objectives for each domain:

Both domains follow the common B/C/D step pattern: select reference models, viewpoints, and tools; develop baseline and target descriptions; perform gap analysis; define candidate roadmap components; resolve impacts across the Architecture Landscape; conduct formal stakeholder review; finalize; and create or update the Architecture Definition Document.

---

Why Data and Application Are Addressed Together in Phase C

A central feature of the TOGAF framework is grouping Data and Application architectures into a single phase rather than creating separate, isolated phases. This design reflects the inherent, symbiotic relationship between data and processing:

• Applications are Meaningless Without Data: An application exists to ingest, transform, calculate, display, and persist data. Without well-structured data entities, application functionality becomes brittle and inconsistent.
• Data is Inaccessible Without Applications: Enterprise data assets deliver no business value if locked away without application services, APIs, and interfaces that allow business actors and automated workflows to interact with them.

Sequencing Flexibility: Data-First vs. Application-First vs. Concurrent

The TOGAF Standard does not dictate a rigid order of execution within Phase C. Enterprise architects are empowered to choose the sequencing strategy best suited to their organizational drivers:

---

The Data Architecture Domain

Data Modeling Levels in Practice

Data modeling practice commonly distinguishes three kinds of data model. These are general data-modeling terms, not TOGAF's four architecture abstraction levels from Section 1.3:

• Conceptual Data Model: Represents high-level business concepts, information objects, and cardinal relationships in business language (originating in Phase B Information Mapping and formalized in Phase C).
• Logical Data Model: Fully normalized representation of data entities, attributes, primary/foreign keys, and data integrity rules, entirely independent of any specific database management system (DBMS) or storage technology.
• Physical Data Model: Details storage schemas, table partitioning, indexes, data types, and physical file allocations optimized for a specific database engine (e.g., Oracle, PostgreSQL, Cassandra). Note: Detailed physical modeling is typically executed by database engineering teams during implementation, governed by the architect's logical architecture.

Key Considerations for Data Architecture

The TOGAF approach to Data Architecture highlights three considerations:

• Data Management — understanding how data is created, stored, transported, and reported; defining which application components will serve as the system of record for each data entity; setting enterprise-wide standards that all application components (including packages) must follow; and planning data transformation, quality, and ownership.
• Data Migration — when an existing application is replaced, a significant amount of data must usually be migrated, so the architecture should identify data migration requirements and indicators of data quality.
• Data Governance — making sure the enterprise has the necessary dimensions in place to enable the transformation: the governance structure, the management system, and the people with the required skills and roles.

Data Stewardship and Security in Practice

Putting data governance into practice typically involves:

• Data Governance: The organizational policies, decision rights, and accountability frameworks governing data usage.
• Data Stewardship: Designated business and technical custodians responsible for enforcing data definitions, business rules, and quality standards.
• Data Security and Privacy: Classifying data based on sensitivity (Public, Internal, Confidential, Restricted), establishing encryption requirements (at rest and in transit), enforcing role-based access control (RBAC), and ensuring regulatory compliance with privacy frameworks.

---

The Application Architecture Domain

1. Application Portfolio Catalog

Before designing target systems, architects typically build an Application Portfolio Catalog — a TOGAF catalog artifact that inventories the applications in the enterprise. Architects then assess each application's business value and technical condition to decide whether it should be retained, enhanced, replaced, or retired. (Rationalization models from outside TOGAF, such as Gartner's Tolerate–Invest–Migrate–Eliminate categories, can be used for this assessment but are not part of the TOGAF Standard.)

2. Logical vs. Physical Application Components

A fundamental distinction in the TOGAF Enterprise Metamodel is the difference between Logical and Physical Application Components:

3. Application Services and Integration Architecture

Applications interact through defined contracts. Phase C models Application Services—the externally visible operations an application exposes to its consumers. Architects define integration patterns:

• API-Led Connectivity: Organizing interfaces into System APIs (accessing underlying databases), Process APIs (orchestrating business logic), and Experience APIs (delivering tailored data to web/mobile clients).
• Event-Driven Architecture (EDA): Decoupling systems using message brokers (e.g., Kafka, RabbitMQ) for asynchronous pub/sub event distribution.
• Integration Platforms: Modernizing from heavy on-premises Enterprise Service Buses (ESBs) to lightweight integration platform-as-a-service (iPaaS) and microservice service meshes.

4. Application/Data Matrix (CRUD View)

A useful Phase C artifact is the Application/Data Matrix, often annotated as a CRUD view. It cross-references application components against data entities, indicating which application may Create, Read, Update, and Delete each data entity:

The CRUD matrix is indispensable for identifying architectural violations: if two separate applications claim "Create" authority over the same data entity, the architect has uncovered a data divergence risk that must be resolved through Master Data Management.

---

Realistic Enterprise Scenario: Aegis Financial

Aegis Financial, a major retail banking and wealth management institution, operated on a 30-year-old COBOL mainframe core banking system. The bank suffered from severe pain points: customer address updates in the mobile app took 48 hours to reflect in the mortgage servicing system, opening a new investment account required customer service reps to copy-paste data across five disconnected terminals, and real-time fraud detection was impossible because batch files were processed only at midnight.

During Phase C, the enterprise architecture team achieved the following:

1. Data Architecture Modernization: Defined an enterprise Logical Data Model establishing "Customer Master Entity" and "Deposit Account Entity" as canonical schemas. Formulated data governance rules designating a new Master Data Management (MDM) platform as the single authoritative source of customer identity.
2. Application Architecture Rationalization: Cataloged 140 legacy banking applications in the Application Portfolio Catalog and marked 45 redundant applications for retirement. Defined modular Logical Application Components: "Digital Identity Service", "Core Ledger Engine", and "Real-Time Event Fraud Detector".
3. CRUD Matrix Reconciliation: Discovered that six separate legacy applications were independently updating customer contact records. The target CRUD matrix concentrated update authority exclusively within the Customer Onboarding & Profile Service.
4. Gap Analysis Deliverables: Produced candidate work packages for Phase E: "Enterprise Customer MDM Deployment", "Core Banking Mainframe API-Decoupling Layer", and "Kafka Event Streaming Integration Backbone".

---

Inputs and Outputs of Phase C

---

Common Exam Pitfalls

• Believing TOGAF mandates "data before applications." Phase C can develop Data and Application Architecture in either order.
• Forgetting that each domain has its own objectives. Both develop a target architecture that enables the Business Architecture and Architecture Vision, and both identify candidate roadmap components from gaps.
• Confusing logical and physical application components. Logical components are implementation-independent; physical components are specific implementations.
• Treating Phase C as database administration. Phase C addresses the enterprise's data and application structures, not detailed physical tuning.