Deliverables

The curriculum covers what an architect should know. This covers what an architect actually hands over: 55 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 → 42 diagrams, shown one at a time with the answer withheld. Nothing to submit.

6 of 55 deliverables shown.

flowchart LR
  party["Party"]
  cust["Customer"]
  supp["Supplier"]
  prod["Product"]
  order["Order"]
  ship["Shipment"]
  inv["Invoice"]
  pay["Payment"]
  loc["Location"]

  cust -->|"is a"| party
  supp -->|"is a"| party
  cust -->|"places"| order
  order -->|"is for"| prod
  supp -->|"supplies"| prod
  order -->|"is fulfilled by"| ship
  ship -->|"is sent to"| loc
  order -->|"is billed on"| inv
  inv -->|"is settled by"| pay

Data View

Conceptual Data Model

The twelve or so things the business talks about and how they relate, with no attributes, no keys and no technology.

Data Architecture Discovery

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

flowchart TB
  subgraph d1["Domain: Sales"]
    direction TB
    p1["<b>customer-360</b><br/><i>daily · 99.5% freshness SLO<br/>owner: Sales Data</i>"]
    p2["<b>pipeline-facts</b><br/><i>hourly</i>"]
  end
  subgraph d2["Domain: Fulfilment"]
    direction TB
    p3["<b>order-events</b><br/><i>streaming · &lt;60s<br/>owner: Fulfilment Eng</i>"]
    p4["<b>delivery-performance</b><br/><i>daily</i>"]
  end
  subgraph d3["Domain: Finance"]
    direction TB
    p5["<b>revenue-recognised</b><br/><i>daily · certified<br/>owner: Finance Systems</i>"]
  end

  subgraph plat["Self-Serve Platform"]
    direction LR
    s1["storage + compute"] --- s2["catalog + lineage"] --- s3["access control"] --- s4["quality + observability"]
  end

  gov["Federated Governance<br/><i>global: identity keys · classification · retention</i>"]

  p3 -->|"consumed by"| p1
  p1 -->|"consumed by"| p5
  p3 -->|"consumed by"| p5
  plat --- d1
  plat --- d2
  plat --- d3
  gov -.-> d1
  gov -.-> d2
  gov -.-> d3

Data View

Data Mesh Domain Map

Which domain owns which data product, what each one guarantees, and the shared platform underneath that makes publishing one cheap.

Data Mesh Design

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

flowchart LR
  src1[("Orders DB")] --> cdc["CDC connector"]
  cdc --> t1[["orders.raw<br/><i>12 parts · key: orderId<br/>retain 7d</i>"]]
  src2["Clickstream"] --> t2[["events.clicks<br/><i>36 parts · key: sessionId<br/>retain 3d</i>"]]

  t1 --> p1["Normalise<br/><i>stateless</i>"]
  p1 --> t3[["orders.clean<br/><i>12 parts · key: orderId<br/>compacted</i>"]]
  t3 --> p2["Enrich + join<br/><i>stateful · 30 min window</i>"]
  t2 --> p2
  p2 --> st[("RocksDB state<br/><i>checkpoint 60s</i>")]
  p2 --> t4[["orders.enriched<br/><i>12 parts · retain 30d</i>"]]
  p2 --> dlq[["orders.dlq"]]

  t4 --> sink1["Serving store"]
  t4 --> sink2["Lakehouse sink<br/><i>5 min commit</i>"]

Data View

Streaming Topology Diagram

Topics, partitions, processors and state stores in one picture, with the retention and keying decisions that determine whether it can be replayed.

Stream Processing Frameworks Design