TOGAF Phase C: Information Systems Architecture: Application and Data in Sparx EA

TOGAF Phase C answers a deceptively simple question: what systems do we need, and what data do they handle? It is deliberately split into two sub-phases, Application Architecture and Data Architecture, and the discipline of keeping them separate is what makes the output usable downstream.

For an architect, Phase C is where the target state becomes concrete: which applications and which data the business needs. The article covers how to structure the package tree, model the application architecture on the ArchiMate application layer, build the data architecture, and run the gap analyses that drive application portfolio management and rationalization decisions. Today the architect builds these models by hand and collects portfolio details from many owners. The AI-augmented way is to decide the structure, the dispositions and the data ownership, let AI build the models, and connect the systems that already hold portfolio facts. The skill is stating the scope and the boundaries clearly and checking that what AI builds keeps application and data concerns separate.

Phase C structure: two sub-phases

Many practitioners blur the boundary and produce a combined "application and data" model that satisfies neither sub-phase. Keep them separate in your Sparx EA package structure:

Phase C: Information Systems Architecture
├── C1: Application Architecture
│   ├── Baseline Application Architecture
│   ├── Target Application Architecture
│   └── Application Gap Analysis
└── C2: Data Architecture
    ├── Logical Data Model
    ├── Canonical Data Model
    ├── Data Lineage Diagrams
    └── Data Gap Analysis

The separation matters because the two sub-phases have different stakeholders (application owners versus data owners), different approval timelines, and different downstream consumers. Application architecture decisions feed Phase D (technology); data architecture decisions feed integration design and analytics.

Application architecture in Sparx EA

Application portfolio. Model the complete application estate using ArchiMate Application Component elements, each connected by Realization relationships to the Phase B capabilities it supports. Portfolio facts such as business owner, lifecycle status, annual cost, vendor and contract expiry are held by your project and portfolio, service management, risk and compliance, and financial management systems. Rather than recording them as static values in the repository, the AI-augmented way is to connect those systems to the model. The architecture model stitches the data together and shows how it relates to capabilities and applications, so portfolio managers get an application inventory that is always current without spreadsheet maintenance. The same data can feed a Power BI report (see reporting and Power BI).

Application interaction diagrams. For each significant integration point, create an ArchiMate application-collaboration diagram showing which components exchange data, through which interfaces (Application Interface elements), and the direction and frequency of exchange. Do not model every API. Model the architecturally significant interactions: those that cross organizational boundaries, carry critical data, or represent technical risk.

Integration architecture. For complex integration estates, create a dedicated integration view. Model the integration platform (ESB, API gateway, event bus) as an Application Component with Realization relationships to the integration services it provides, and show each application's connectivity to that layer using Association relationships.

Data architecture in Sparx EA

Logical data model. The logical data model captures the key business entities and their relationships, independent of physical implementation. Use a UML Class diagram with entity stereotypes, or ArchiMate Data Object elements for a higher-level view. Link key entities to the business capabilities and application components that create, read, update, or delete them.

To build a CRUD matrix, use the Relationship Matrix with Data Objects on one axis and Application Components on the other, and mark the cells with create, read, update or delete. This matrix is the foundation of the data architecture and the primary tool for spotting data-ownership ambiguity, a common data architecture problem.

Canonical data model. The canonical model is a vendor-neutral reference for the key business entities used in integration. Model it as a separate package from the logical data model. Each canonical entity is the "master" definition that integration mappings reference: when an application exposes or consumes data via an API, it maps to and from the canonical entity, not directly to another application's proprietary schema.

Data lineage diagrams. Lineage shows how data flows through the estate, from source through transformations to consumption. Use ArchiMate data-flow views or UML sequence diagrams, and tag each flow:

• data_classification: Public / Internal / Confidential / Restricted
• data_quality_score: if a data quality assessment has been run
• lineage_verified: whether the lineage has been validated with the application owner

Documented lineage is what makes downstream analytics trustworthy: when a Power BI report knows the lineage of the data it shows, quality issues can be traced to source rather than blamed on the report.

The application gap analysis, step by step

The gap analysis compares the baseline application architecture to the target and produces a disposition decision for each application. Run it as a repeatable sequence in the model rather than a one-off workshop.

With this output in place, the rationalization conversation changes from "we have too many CRMs" (opinion) to "three of our five CRM instances serve capabilities that consolidate in the target architecture; two have contracts that expire inside the planning window; the combined annual cost is in the dashboard" (model-derived fact).

The data gap analysis

The data gap analysis identifies four kinds of gap. Model each one as a Gap element linked to the affected data entity and the capability or application that requires it, then tag it with type and priority:

• Missing data entities: capabilities in the target architecture with no identified data source.
• Data quality gaps: entities that exist but lack the quality the target use cases demand.
• Data ownership gaps: entities with no authoritative source (master-data-management failures).
• Integration gaps: data that needs to flow between applications where no integration exists.

The data gap analysis feeds the integration architecture design here in Phase C and the platform-selection decisions in Phase D.

Frequently asked questions

What this means for the architect

The structured model you produce in Phase C is what makes analytics and AI answers worth trusting. Which tools help depends on the job: AI tools for Sparx EA compares the options for building and querying the model, and AI-Augmented Architecture shows how the work changes across modeling, analysis, governance, and engagement. The architect's part is the structure, the dispositions and the data ownership decisions.