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.

8 of 55 deliverables shown.

flowchart LR
  subgraph t1[" "]
    direction TB
    c1["cmd: Place Order"]
    e1["OrderPlaced<br/><i>fact</i>"]
    r1[("read: Order Status")]
    c1 --> e1 --> r1
  end
  subgraph t2[" "]
    direction TB
    c2["cmd: Authorise Payment"]
    e2["PaymentAuthorised<br/><i>fact</i>"]
    r2[("read: Payment Ledger")]
    c2 --> e2 --> r2
  end
  subgraph t3[" "]
    direction TB
    c3["policy: on PaymentAuthorised<br/>allocate stock"]
    e3["StockAllocated<br/><i>fact</i>"]
    r3[("read: Availability")]
    c3 --> e3 --> r3
  end
  subgraph t4[" "]
    direction TB
    c4["policy: on StockAllocated<br/>request despatch"]
    e4["ConsignmentCreated<br/><i>fact</i>"]
    r4[("read: Tracking")]
    c4 --> e4 --> r4
  end
  e1 --> c2
  e2 --> c3
  e3 --> c4

Behavioural View

Event Model

The business as a sequence of facts that happened, with the command that caused each and the read models and reactions it feeds.

Event-Driven Architecture Design

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
  cust(["Customer"])
  app["Registration<br/><i>process</i>"]
  kyc["KYC Provider<br/><i>external · EU</i>"]
  core["Core Platform<br/><i>process</i>"]
  crm[("CRM store<br/><i>EU region</i>")]
  dwh[("Analytics store<br/><i>EU region</i>")]
  mkt["Marketing SaaS<br/><i>external · US</i>"]

  cust -->|"name, DoB, address, ID image"| app
  app -->|"name, DoB, ID image"| kyc
  kyc -->|"pass/fail, risk score"| app
  app -->|"full profile"| core --> crm
  crm -->|"pseudonymised profile, nightly"| dwh
  crm -->|"email, consent flag, on change"| mkt

Data View

Data Flow Diagram

What data moves where, in what form, and how often — the view a privacy or residency question is actually answered from.

Data-Flow Diagrams Design

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

Governance Artifact

Data Contract

A producer's binding promise about a dataset — schema, semantics, freshness, quality and how it will change — enforced in the pipeline rather than in a meeting.

Data Contracts Design