Deliverables

The curriculum covers what an architect should know. This covers what an architect actually hands over: 22 artifacts, each with a worked example, a note on when it is worth producing, who reads it, and the ways it usually goes wrong. Filter by the artifact's type, the kind of engagement that calls for it, the stack or industry it is drawn against, or the audience it is written for.

Identify the deliverable → 18 diagrams, shown one at a time with the answer withheld. Nothing to submit.

3 of 22 deliverables shown.

flowchart LR
  s1[("core_banking.accounts<br/><i>source</i>")]
  s2[("payments.transactions<br/><i>source</i>")]
  s3[("crm.customer<br/><i>source</i>")]

  j1{{"job: cdc_ingest<br/><i>hourly</i>"}}
  j2{{"job: conform_party<br/><i>daily 02:00</i>"}}
  j3{{"job: build_balances<br/><i>daily 03:15</i>"}}
  j4{{"job: reg_extract<br/><i>monthly</i>"}}

  r1[("raw.accounts")]
  r2[("raw.transactions")]
  c1[("clean.party")]
  c2[("clean.balance_daily")]
  o1[("report.capital_adequacy")]
  o2["Dashboard:<br/>Treasury Daily"]

  s1 --> j1 --> r1
  s2 --> j1 --> r2
  s3 --> j2
  r1 --> j2 --> c1
  r1 --> j3
  r2 --> j3 --> c2
  c1 --> j3
  c2 --> j4 --> o1
  c2 --> o2

Data View

Data Lineage Graph

Which dataset was derived from which, through what job — the artifact you produce when someone asks where a number came from.

Data Observability Run

erDiagram
  CUSTOMER ||--o{ ORDER : places
  CUSTOMER ||--o{ ADDRESS : has
  ORDER ||--|{ ORDER_LINE : contains
  ORDER }o--|| ADDRESS : "ships to"
  ORDER ||--o| PAYMENT : "settled by"
  PRODUCT ||--o{ ORDER_LINE : "appears in"
  PRODUCT }o--|| CATEGORY : "belongs to"

  CUSTOMER {
    uuid id PK
    string email UK
    string status
    timestamp created_at
  }
  ORDER {
    uuid id PK
    uuid customer_id FK
    uuid ship_to_id FK
    string status
    numeric total_minor
    string currency
  }
  ORDER_LINE {
    uuid id PK
    uuid order_id FK
    uuid product_id FK
    int quantity
    numeric unit_price_minor
  }
  PAYMENT {
    uuid id PK
    uuid order_id FK
    string provider_ref UK
    string state
  }

Data View

Entity Relationship Diagram

Entities, their attributes and the cardinality between them — where the notation on the end of each line is the actual content.

Relational Modelling Design

flowchart LR
  subgraph src["Sources"]
    direction TB
    oltp[("Operational DBs<br/><i>CDC</i>")]
    saas["SaaS APIs<br/><i>batch pull</i>"]
    events[["Event Stream<br/><i>Kafka</i>"]]
    files["Partner Files<br/><i>SFTP drop</i>"]
  end

  subgraph raw["Raw Zone"]
    direction TB
    r1[("append-only<br/>source schema<br/>no transforms")]
    r2["<i>guarantee:</i><br/>replayable history"]
  end

  subgraph clean["Cleansed Zone"]
    direction TB
    c1[("deduplicated<br/>typed, conformed<br/>quality-tested")]
    c2["<i>guarantee:</i><br/>schema + quality SLA"]
  end

  subgraph curated["Curated Zone"]
    direction TB
    g1[("business entities<br/>modelled, aggregated")]
    g2["<i>guarantee:</i><br/>agreed definitions"]
  end

  subgraph serve["Consumers"]
    direction TB
    bi["BI & Reporting"]
    ml["Feature Store<br/>& Model Training"]
    api["Data API<br/>& Reverse ETL"]
  end

  oltp --> raw
  saas --> raw
  events --> raw
  files --> raw
  raw --> clean
  clean --> curated
  curated --> serve
  clean -.->|"exploration only"| ml

Data View

Layered Data Platform Diagram

Sources landing into progressively refined zones, with the contract each zone offers written down rather than assumed.

Medallion Architecture Design