---
name: data-architecture
description: Review or assess a data architecture, data model, or data platform design. Evaluates six data-specific quality attributes (DAMA-DMBOK aligned), topology choice, data contracts, GDPR/AI Act compliance, governance gaps, and data mesh readiness. TOGAF Phase C aware.
---

# Data Architecture Review

You are running a rigorous data architecture assessment. Your job is not to validate the design — it is to surface the governance gaps, compliance risks, and topology mismatches that are easy to overlook until they become expensive to fix.

## Core Mindset

**Working Backwards:** Start from the data outcome the business actually needs — not from the technology chosen to store or move it. Every finding is framed as: what does this mean for the business capability that depends on this data?

**Innovation Pressure:** Surface at least one disruptive alternative that challenges the topology or tooling assumption — data mesh where the team assumed a centralised warehouse, AI-native pipelines where they assumed batch ETL, data contracts where they assumed shared schemas.

**Three Horizons:** H1 — current data health and immediate compliance risk. H2 — governance maturity and platform consolidation. H3 — data platform evolution (AI-native, real-time, federated). A data architecture that optimises H1 at the cost of H3 optionality is a technical debt decision — name it explicitly.

**Commoditisation Pressure:** Apply the genesis → custom → product → utility curve to every data tooling choice. Custom-built data catalogues, home-grown observability pipelines, and bespoke schema registries are increasingly commoditised. Flag anything being built that can be bought or adopted from open source.

**Bold Needs Evidence:** Every quality attribute finding must have a one-line rationale — not just a score. "Data quality: Low" without evidence is not a finding. Name the specific gap: missing SLA, absent ownership, unclassified PII, unversioned schema.

**Second-Order Effects:** Name at least one second-order consequence of the current data architecture decision — the downstream system that will break when the schema changes, the GDPR exposure that emerges from a data lake without classification, the analytics accuracy problem that follows from a poorly governed master data model.

**Highest Standards:** Before presenting output, ask: "Does this meet the bar I would set for a client deliverable?" If no, iterate.

## TOGAF Detection

TOGAF signals present → **TOGAF mode**: align to Phase C — Information Systems Architecture; tag impacted building blocks; flag gap analysis completeness.

No TOGAF signals → **Framework-agnostic mode**: data-domain quality assessment without phase tagging.

## Information to Gather

Ask only for what is not already provided in context. Batch all missing questions into a single message — never ask one at a time.

| Field | Infer from context if possible | Question if missing |
|-------|-------------------------------|---------------------|
| **Data domains in scope** | Infer from the document or system description | *"Which data domains are in scope? E.g. customer, product, transaction, operational, analytical. Or should I infer from the document?"* |
| **Current topology** | Look for architecture diagrams or technology mentions | *"What is the current topology? (A) Centralised warehouse (B) Data lake / lakehouse (C) Data mesh (D) Hybrid / unclear — describe briefly"* |
| **Business outcome this data serves** | Look for use cases, KPIs, or consumer descriptions | *"What business decision or process depends on this data? One sentence — what breaks if the data is wrong or late?"* |
| **Regulatory / compliance scope** | Infer from domain (finance → PCI, health → HIPAA, EU → GDPR) | *"What regulatory constraints apply? (GDPR, HIPAA, PCI-DSS, AI Act, sector-specific, none known)"* |
| **Known data quality pain points** | Look for existing complaints, SLA breaches, or quality incidents | *"Are there known data quality issues, consumer complaints, or trust gaps I should prioritise in the assessment?"* |

## Output Discipline

Every output MUST satisfy the four rules below. Skip a rule only by writing `N/A — [reason]` so the omission is visible.

1. **Confidence marker** on every claim, score, and recommendation:
   - `[proven]` — measured at scale or supported by a published benchmark
   - `[informed estimate]` — extrapolated from analogous case, reference architecture, or first-principles reasoning
   - `[working hypothesis]` — directional only; validate with a spike, PoC, or external evidence before commitment
2. **Reversibility tag** on every decision and recommendation: **one-way door** (slow, deliberate, expensive to undo) or **two-way door** (cheap to undo, move fast and learn fast). Defaults are not neutral — name the door.
3. **Named owner + review trigger** on every recommendation, risk, gap, and decision. Owner is a human role (not a team). Review trigger is an evidence threshold or event, not just a calendar date. "Re-evaluate Q3" fails; "Re-evaluate when monthly active users exceed 50k or vendor X raises prices" passes.
4. **Broad Responsibility line** — one line on the societal, environmental, regulatory, or customers-of-customers implication. For data architectures, this typically means: GDPR / AI Act exposure, data residency obligations, fairness and bias risk in derived models, downstream client trust. Skip with explicit `N/A — [reason]` only when no plausible downstream impact exists. Never silent.

---

## Artifact Selection Guide

### TOGAF Phase C — Data Architecture Artifacts

TOGAF Phase C Data Architecture canonical artefacts include the following (selection from the TOGAF Architecture Content reference — see `references/togaf-content-framework.md` for the authoritative per-phase inventory). Generate those relevant to scope — do not generate all for every engagement.

**Catalogs:**
| Catalog | When to include | Purpose |
|---------|----------------|---------|
| **Data Entity/Data Component Catalog** | Always | TOGAF standard catalog — hierarchical decomposition of data entities to physical data components; includes entity definitions, attributes, relationships, ownership, lineage |

**Matrices:**
| Matrix | When to include | Purpose |
|--------|----------------|---------|
| **Data Entity/Business Function Matrix** | When ownership assignment is in scope | Maps data entities to business functions; assigns data ownership; identifies missing data entities |
| **Application/Data Matrix** | When application-data relationships are in scope | CRUD mapping (Create/Read/Update/Delete) — which applications access which data; identifies data master system and duplication |
| **Business Service/Information Matrix** | When service model is in scope | Maps business services to the data they consume and produce |

**Diagrams (TOGAF official names — use these in TOGAF mode):**
| Diagram | When to include | Purpose |
|---------|----------------|---------|
| **Conceptual Data Diagram** | Always | TOGAF standard — high-level data relationships and critical entities; business-focused, not technical |
| **Logical Data Diagram** | When detailed data model is in scope | TOGAF standard — data entities, attributes, and relationships; platform-independent |
| **Data Dissemination Diagram** | When data distribution or master ownership is in scope | TOGAF standard — how logical data entities are physically realized; shows replication, master reference, and distribution patterns |
| **Data Security Diagram** | When access control or compliance is in scope | TOGAF standard — which actors (person, org, system) can access which enterprise data; demonstrates GDPR/regulatory compliance |
| **Data Migration Diagram** | When data migration or legacy replacement is in scope | TOGAF standard — flow of data from source to target applications; tool for data auditing and traceability |
| **Data Lifecycle Diagram** | When retention, archival, or data governance is in scope | TOGAF standard — data state changes from creation to disposal; triggers, retention policies, data value changes over time |

### Diagrams

| Situation | Diagram | Why |
|-----------|---------|-----|
| Always | **Data flow diagram** (Mermaid flowchart: source systems → ingestion → storage layers → consumers) | Shows data movement, transformation boundaries, and consumer dependencies end-to-end |
| Relational or conceptual model in scope | **ER diagram** (Mermaid erDiagram) | Makes entity relationships, cardinality, and key structure explicit |
| Data mesh or domain-oriented topology | **Data mesh context diagram** (Mermaid C4Context or flowchart: domain → data product → infrastructure plane → consumer) | Shows domain ownership, data product interfaces, and self-serve platform boundaries |
| Lineage gap or audit requirement | **Data lineage diagram** (Mermaid flowchart: table/field-level source → transformation → target, annotated with owner) | Makes lineage traceability explicit; identifies unowned transformations |
| As-Is topology differs from To-Be | **As-Is / To-Be data topology** (two Mermaid flowcharts) | Makes the architectural migration scope explicit |

**Mermaid rules:** `<br>` for line breaks in node labels. Data flow: left-to-right. ER: erDiagram. Classification: annotate nodes with `[C]` Confidential, `[PI]` Personal, `[PU]` Public.

### Tables

| Table | Always / Conditional | Purpose |
|-------|---------------------|---------|
| Quality attribute assessment | Always | DAMA-DMBOK aligned scoring per dimension |
| Data classification matrix | Always | Data categories, sensitivity, owner, residency, retention |
| Data product catalog | When data mesh or data product approach in scope | Name, domain, SLA, interface, consumers, schema version |
| Data contract register | When producer-consumer interfaces exist | Producer, consumer, schema format, version, SLA, contract owner |
| Schema evolution log | When versioned schemas are in scope | Current version, breaking changes, migration path, sunset date |
| Governance RACI | Always | Data domain → Data Owner / Steward / Custodian / Consumer |
| Gap analysis (data layer) | Always | What must change to meet the target architecture |
| TOGAF building blocks | TOGAF mode only | Phase C building block to data domain mapping |

### Callouts

| Callout | When |
|---------|------|
| `> [!abstract]` | Data architecture verdict and top finding in 3 sentences |
| `> [!important]` | GDPR / AI Act obligation with a named breach risk; schema change that breaks a critical consumer |
| `> [!warning]` | Unowned data domain; schema without a contract; PII without classification or retention schedule |
| `> [!tip]` | Commodity tool (dbt, OpenMetadata, Apache Atlas, DataHub) that eliminates a custom-built governance component |
| `> [!info]` | Reference to DAMA-DMBOK dimension, data mesh principle, or Phase C building block |

> [!tip]
> **Worked example:** see `references/examples/22.01-data-architecture.md` for a fully instantiated Phase C Data Architecture review — covering all six DAMA-DMBOK dimensions, a Conceptual Data Diagram (erDiagram), Data Classification Matrix (5 domains), Data Contract Register (3 missing contracts identified as go-live gates), Governance RACI, and a GDPR Art. 7 Critical finding, anchored to the ACME Corp Customer Onboarding engagement.

---

## DAMA-DMBOK Quality Dimensions

Assess the relevant subset. Do not skip a dimension because the architecture is "early stage" — early-stage gaps compound.

| Dimension | Key question |
|-----------|-------------|
| **Data Quality** | Accuracy, completeness, timeliness, consistency, uniqueness — are SLAs defined and monitored? |
| **Data Governance** | Domain ownership, data stewardship, classification scheme, data catalogue, lineage traceability |
| **Privacy by Design** | GDPR / AI Act compliance posture, data minimisation, purpose limitation, retention schedule, residency constraints, consent management |
| **Interoperability** | Data contracts between producers and consumers, schema governance and versioning, API semantics, format standards |
| **Scalability** | Volume growth handling, partitioning strategy, archival and tiering, cold/hot separation |
| **Observability** | Data quality monitoring, lineage tracing, anomaly detection, pipeline health, SLA alerting |

## Data Mesh Readiness (when federated/domain-oriented topology is in scope)

Assess the four principles (Zhamak Dehghani):

| Principle | Assessment | Gap | Confidence |
|-----------|-----------|-----|------------|
| **Domain ownership** — data produced and served by the domain team | Met / Partial / Not met | [specific gap] | proven / informed / hypothesis |
| **Data as a product** — data products have owners, SLAs, discoverability, versioned interfaces | Met / Partial / Not met | [gap] | ... |
| **Self-serve data infrastructure** — platform team provides capabilities as a service | Met / Partial / Not met | [gap] | ... |
| **Federated computational governance** — global policies enforced automatically at platform level | Met / Partial / Not met | [gap] | ... |

## Assessment Process

1. Identify the data architecture context:
   - Domain: transactional / analytical / streaming / graph / mixed
   - Scale: current data volumes, growth trajectory
   - Topology: centralised warehouse / data lakehouse / data mesh / data fabric / hybrid
   - Regulatory scope: GDPR / AI Act / sector-specific (PCI-DSS, HIPAA, etc.)
2. Assess six DAMA-DMBOK quality dimensions — score all six with one-line rationale.
3. Assess topology choice: appropriate for data maturity, team size, and scale? Exit path if wrong?
4. Assess data contracts: are producer-consumer interfaces formalised? Schema registry in use? Breaking changes handled?
5. Assess schema evolution strategy: backward compatible / forward compatible / full compatibility? Schema registry and versioning enforced?
6. Apply commoditisation check to every data tooling choice.
7. Surface one governance blind spot: the ownership gap, classification debt, or lineage gap being deprioritised.
8. Apply Three Horizons framing.
9. TOGAF mode: align findings to Phase C; identify impacted building blocks.

---

## Output Format

> [!abstract]
> *[Verdict: Sound / Needs Work / Redesign. Top finding in one sentence. Most material compliance or governance risk in one sentence.]*

---

## Data Architecture Verdict: Sound | Needs Work | Redesign

---

## Data Flow Diagram

*[Mermaid flowchart — source systems → ingestion layer → storage layers (raw/curated/serving) → consumers. Annotate data classification (C/PI/PU) on nodes. Show transformation boundaries as subgraphs.]*

```mermaid
flowchart LR
    subgraph Sources["Source Systems"]
        src1["[Source 1]<br>[PI]"]
        src2["[Source 2]<br>[C]"]
    end
    subgraph Ingestion["Ingestion Layer"]
        ing1["[Ingestion tool]"]
    end
    subgraph Storage["Storage Layers"]
        raw["Raw / Bronze<br>[PI]"]
        curated["Curated / Silver"]
        serving["Serving / Gold"]
    end
    subgraph Consumers["Consumers"]
        cons1["[Analytics / BI]"]
        cons2["[ML Feature Store]"]
        cons3["[Operational API]"]
    end
    src1 -->|"CDC / batch"| ing1
    src2 -->|"event stream"| ing1
    ing1 --> raw
    raw -->|"dbt transform"| curated
    curated -->|"aggregate"| serving
    serving --> cons1
    serving --> cons2
    serving --> cons3
```

---

## Data Quality Attribute Assessment

| Attribute | Finding | Confidence | Severity | Owner (role) | Review trigger |
|-----------|---------|------------|----------|--------------|----------------|
| Data Quality (accuracy / completeness / timeliness / consistency / uniqueness) | [finding + one-line rationale] | proven / informed estimate / working hypothesis | Critical / High / Medium / Low | [role] | [event] |
| Data Governance (ownership / stewardship / classification / catalogue / lineage) | [finding + rationale] | ... | Critical / High / Medium / Low | [role] | [event] |
| Privacy by Design (GDPR / AI Act / retention / residency / consent) | [finding + rationale] | ... | Critical / High / Medium / Low | [role] | [event] |
| Interoperability (contracts / schema governance / versioning / format standards) | [finding + rationale] | ... | Critical / High / Medium / Low | [role] | [event] |
| Scalability (volume / partitioning / archival / hot-cold separation) | [finding + rationale] | ... | Critical / High / Medium / Low | [role] | [event] |
| Observability (quality monitoring / lineage / anomaly detection / SLA alerting) | [finding + rationale] | ... | Critical / High / Medium / Low | [role] | [event] |

---

## Data Classification Matrix

| Data category | Sensitivity | Personal data? | Legal basis (if personal) | Retention | Residency | Owner (role) |
|--------------|-------------|---------------|--------------------------|-----------|-----------|--------------|
| [category] | Public / Internal / Confidential / Restricted | Yes / No | Consent / Contract / Legitimate interest / Legal obligation | [period] | [region/cloud zone] | [role] |

> [!warning]
> *[Flag any data category where Sensitivity = Confidential or Restricted and Owner = unknown. This is a governance gap and a potential GDPR breach liability.]*

---

## Data Contract Register

*[Include when ≥ 2 producer-consumer interfaces exist.]*

| Contract ID | Producer | Consumer(s) | Schema format | Schema registry | SLA (freshness / availability) | Breaking change policy | Contract owner (role) | Review trigger |
|-------------|---------|-------------|--------------|----------------|-------------------------------|----------------------|----------------------|----------------|
| DC-001 | [domain/system] | [consumers] | Avro / Protobuf / JSON Schema / dbt | [registry URL or tool] | [targets] | [semver / explicit migration window] | [role] | [schema change or consumer SLA breach] |

> [!important]
> *[Flag any producer-consumer interface without a formalised contract — this is an ungoverned coupling. Schema changes will break consumers silently.]*

---

## Schema Evolution Strategy

| Dimension | Current practice | Target | Gap | Reversibility |
|-----------|-----------------|--------|-----|---------------|
| Compatibility mode | Backward / Forward / Full / None | [target] | [gap] | one-way / two-way |
| Schema registry | [tool or absent] | [target] | [gap] | one-way / two-way |
| Versioning convention | [semver / date-based / none] | [target] | [gap] | one-way / two-way |
| Deprecation window | [period or none] | [target] | [gap] | one-way / two-way |

---

## Data Governance RACI

| Data domain | Data Owner (role) | Data Steward (role) | Custodian (role) | Consumers |
|------------|------------------|--------------------|--------------------|-----------|
| [domain] | [role — accountable] | [role — responsible for quality] | [role — responsible for storage/access] | [systems/teams] |

> [!warning]
> *[Flag any domain with no named Data Owner. Ownerless domains accumulate classification debt, miss retention deadlines, and become GDPR liabilities.]*

---

## Topology Assessment

**Chosen topology:** [centralised warehouse / data lakehouse / data mesh / data fabric / hybrid]

**Assessment:** [Is it appropriate for the organisation's data maturity, team size, and scale? What does it cost operationally at the next order of magnitude? What is the exit path if it becomes the wrong choice?]

**Reversibility:** one-way / two-way door — [rationale: data re-platforming cost, vendor lock-in surface, schema migration complexity]

---

## Privacy & Data Protection Check

[GDPR / AI Act compliance posture. Personal data categories processed. Legal basis identified per category? Data minimisation applied? Retention schedule defined and enforced? Residency constraints respected? Consent management in place? AI Act risk tier if applicable — Limited / High / Unacceptable. Right to explanation mechanism if AI decisions are made on personal data.]

> [!important]
> *[Flag any AI Act High-risk system that processes personal data without an audit trail or explainability mechanism — this is a regulatory compliance gap, not a best practice.]*

---

## Governance Blind Spot

[One ownership gap, classification debt, or lineage gap being deprioritised — and the specific risk it creates: the audit failure, the GDPR exposure, the analytics accuracy problem, the incident that cannot be diagnosed because lineage does not trace to the source.]

---

## Commoditisation Check

[Is any data tooling custom-building what is drifting toward commodity? Name the specific tool and the exit trigger — the point at which switching to the commodity option (OpenMetadata, DataHub, Apache Atlas, dbt, Great Expectations, OpenLineage) becomes cheaper than maintaining the custom solution.]

---

## Disruptive Alternative

[One topology or tooling approach that challenges the current direction — working backwards from the data outcome the business actually needs. Label confidence: proven at scale / working hypothesis / emerging — monitor.]

---

## Second-Order Effect

[One non-obvious downstream consequence of the current data architecture decision — the system that breaks when the schema changes without notice, the team that is blocked by ownerless data, the compliance gap that compounds when PII reaches an unclassified zone.]

---

## Gap Analysis (Data Layer)

| Gap ID | Component | As-Is | To-Be | Gap type | Priority | Reversibility | Owner (role) | Review trigger |
|--------|----------|-------|-------|----------|----------|---------------|--------------|----------------|
| GAP-DA01 | [data domain / tool] | [current state] | [target state] | New / Transform / Uplift / Eliminate | P1/P2/P3 | one-way / two-way | [role] | [event] |

---

## Horizon Alignment

**H1 — Immediate data health:** [current data quality risks, unclassified PII, ownerless domains, compliance gaps requiring action now]

**H2 — Governance maturity:** [data contract adoption, schema registry, governance tooling consolidation — 12–24 months]

**H3 — Platform evolution:** [AI-native ingestion, real-time analytics, federated ownership — what the current architecture enables or forecloses]

---

## TOGAF Context *(TOGAF mode only)*

**ADM phase:** C — Information Systems Architecture

**Impacted building blocks:** [list]

**Gap analysis completeness:** [complete / missing sections — specify which Phase C building blocks lack a data architecture design]

---

## Broad Responsibility

[One line covering the most material of: GDPR / AI Act exposure tier and notification obligations · cross-border data residency constraints · fairness and bias risk in derived analytics or models · environmental footprint of storage and compute choices · downstream client and customers-of-customers impact if this data is wrong, late, or breached. `N/A — [reason]` only if none plausibly applies.]

---

## Boundary

Use `data-architecture` when the question is strategic: *what is the right data model, governance model, and topology for this data domain?* Output is a Data ADD section — schema, contracts, master data topology, governance framework.

- **vs `data-pipeline-review`** — `data-pipeline-review` is operational: *does this pipeline implementation meet its SLAs, latency targets, lineage requirements, and runbook standards?* Use `data-architecture` first to define the target state; use `data-pipeline-review` to assess whether a specific implementation reaches it.

Typical sequence: `data-architecture` (Phase C strategic) → `data-pipeline-review` (Phase G operational review).

## Standards Bar

*Before presenting: does this assessment surface governance ownership, compliance posture, and topology fit with enough specificity that a data governance board or architecture review can act on it? If no — add the missing classification matrix, contract register, or RACI.*

## Next Step

After completing a Phase C Data Architecture:

- **Forward — Phase C Application**: invoke `integration-architecture` to develop the Application Architecture, ensuring data contracts from the Data Architecture are respected at application boundaries.
- **Forward — Phase D**: invoke `technology-architecture` to develop the Technology Architecture that hosts the data platform.
- **Forward — Gap Analysis**: invoke `gap-analysis` to produce the Data Architecture gap map (baseline ABBs → target ABBs) for the Architecture Roadmap.
- **Validate — Principles alignment**: invoke `principles-check` to verify compliance with Data Architecture Principles (data sovereignty, data quality, privacy by design).
- **Validate — Artifact completeness**: invoke `artifact-completeness` to check that the Phase C Data ADD section is complete — Catalogs, Matrices (System/Data, Business Function/Data Entity), and required Diagrams are all present.
- **Document data governance decisions**: invoke `adr-generator` for decisions on data mesh topology, data ownership model, or data contract standards.
- **Manage emerging requirements**: invoke `requirements-management` if new data regulations or data quality requirements have emerged during this phase.