← Dashboard
T8Scenario-HeavyHigh Frequency

Phase C: Information Systems Architecture

TOGAF Phase C — The Open Group↗
Official TOGAF 10 Phase C chapter
Information Systems Architecture Techniques↗
Data and Application architecture techniques
OGEA-101 Exam Syllabus↗
Phase C scope for Foundation exam
Phase C
Second BDAT phase
Data + App
Two domains in one phase
2 Gap Analyses
One per domain
No Tech Yet
Technology comes in Phase D
💡 The Big Idea

Phase C: Information Systems Architecture covers TWO domains — Data Architecture and Application Architecture — in a single phase. Both are technology-agnostic: no database products, no tech stacks yet. Phase C defines WHAT data exists and WHAT applications handle it; Phase D defines HOW technology enables them.

Phase C develops the Information Systems Architecture — covering both the data landscape and the application landscape. It follows Phase B (Business Architecture) and precedes Phase D (Technology Architecture).

  • ▸🗄️ Develops Data Architecture (Baseline + Target): entities, relationships, data flows, ownership
  • ▸📱 Develops Application Architecture (Baseline + Target): application portfolio, functions, interactions
  • ▸🔍 Performs TWO Gap Analyses: one for Data, one for Application
  • ▸📄 Adds TWO sections to the Architecture Definition Document (Data + Application)
  • ▸🔗 Both architectures are technology-agnostic — no database products or tech stacks yet
  • ▸🔁 Data and Application Architecture can be done sequentially or in parallel
  • ▸📌 Business Architecture (Phase B) must be complete before Phase C begins

Toggle between the two Phase C domains to explore key questions, work products, CDIPD examples, and exam traps:

Phase C · Data Architecture

Defines WHAT data exists, its structure, ownership, and flows across the enterprise.

Key Questions Answered
  • ▸What data entities does the business need?
  • ▸How is data structured and related?
  • ▸Where does data originate and how does it flow?
  • ▸Who owns which data? Who can access it?
  • ▸How is data quality, security, and lifecycle managed?
Work Products
  • ▸Data Entity / Data Component Catalogue
  • ▸Data Dictionary (definitions + owners)
  • ▸Data Lifecycle catalogue
CDIPD Examples
DWMS
Student entity (ID, name, programme, year), Leave entity (applicant, type, dates, status, approver), Grade entity (student, course, marks, grade, verified_by)
PayFlask
Transaction entity (ID, amount, payer, gateway, status, timestamp), AuditLog entity (transaction_id, event_type, actor, timestamp)
VSSC Search
Document entity (doc_id, title, category, classification_level, vector_embedding), SearchQuery entity (query_text, user_id, results_count, latency_ms)
🔍 Gap Analysis Example

DWMS Data Gap: Baseline had no audit log entity → Target requires AuditLog entity with full event trail. Gap type: NEW — must be designed and built.

⚡ Exam Trap — Data Architecture defines the DATA MODEL — entities, relationships, ownership, and flows. It does NOT specify which database product to use (that is Technology Architecture). "PostgreSQL" = Technology; "Student entity with FK to Course" = Data Architecture.
Attribute🗄️ Data Architecture📱 Application Architecture
AnswersWhat DATA does the business need?What APPLICATIONS support the business?
FocusEntities, relationships, data flowsApplication functions, interactions, portfolio
Technology?No — no database products yetNo — no tech stack yet (that's Phase D)
Gap AnalysisData Gap AnalysisApplication Gap Analysis
CDIPD exampleStudent entity, Grade entity, AuditLog entityDWMS Workflow Engine, PayFlask Orchestrator
SequenceCan precede or run parallel to AppCan follow or run parallel to Data
🔑 The Phase C Rule

Phase C produces TWO Gap Analyses (Data + Application) and adds TWO sections to the Architecture Definition Document. Neither Data nor Application Architecture specifies which technology product to use — that is Phase D. Phase C defines WHAT; Phase D defines HOW (technically).

A common mistake is including technology choices in Phase C. TOGAF is explicit: Phase C defines WHAT data exists and WHAT applications handle it — not HOW they are technically implemented. That comes in Phase D.

  • ▸📊 "Student data entity with attributes: ID, name, programme, year" → Data Architecture ✅
  • ▸❌ "Student data stored in PostgreSQL 16 on AWS RDS" → Technology Architecture (Phase D)
  • ▸📱 "A notification service that sends email and SMS alerts" → Application Architecture ✅
  • ▸❌ "Spring Boot 3.x microservice deployed on Docker" → Technology Architecture (Phase D)
  • ▸🔑 Logical, vendor-neutral = ABB. Physical / supplier-specific = SBB. SBBs are formally defined in Phase E
  • ▸⚠️ Exam trap: "PostgreSQL" in Phase C = wrong; "relational data store" = correct

The ADD is built progressively across Phases B, C, D. After Phase C, the ADD contains three sections:

  • ▸✅ Section 1: Business Architecture (completed in Phase B)
  • ▸✅ Section 2: Data Architecture (completed in Phase C)
  • ▸✅ Section 3: Application Architecture (completed in Phase C)
  • ▸⏳ Section 4: Technology Architecture (to be completed in Phase D)
  • ▸📌 The ADD is still a draft after Phase D — it is finalized in Phase F
  • ▸⚠️ Exam trap: the ADD is still a draft after Phase C and D — it is finalized in Phase F

Phase C is the second architecture development phase. Its position between Business (B) and Technology (D) reflects the logical dependency chain:

Sequence:B→D→A→T"Big Dogs Always Triumph"
← T7T9 →