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.

10 of 55 deliverables shown.

flowchart LR
  crm["CRM"]
  oms["Order Mgmt"]
  erp["ERP"]
  wms["WMS"]
  bill["Billing<br/><i>mainframe</i>"]
  dw[("Warehouse")]
  ptnr["Partner"]

  crm -->|"I-01 · REST · on demand"| oms
  oms -->|"I-02 · SFTP CSV · nightly"| erp
  oms -->|"I-03 · MQ · near real time"| wms
  wms -->|"I-04 · REST · on demand"| oms
  erp -->|"I-05 · flat file · nightly"| bill
  bill -->|"I-06 · DB link · nightly"| dw
  oms -->|"I-07 · CDC · continuous"| dw
  ptnr -->|"I-08 · AS2 EDI · hourly"| oms
  oms -->|"I-09 · AS2 EDI · hourly"| ptnr

Structural View

Integration Landscape Diagram

Every interface between systems, with its mechanism, direction, frequency and owner — the artifact that tells you what a migration will actually break.

Enterprise Integration Discovery

flowchart TB
  cust(["Customer"])
  agent(["Support Agent"])
  sys["Order Management<br/>the system being described"]
  pay["Payment Gateway<br/>external SaaS"]
  erp["ERP<br/>existing on-premises"]
  mail["Email Provider<br/>external SaaS"]
  crm["CRM<br/>external SaaS"]

  cust -->|"places and tracks orders"| sys
  agent -->|"amends and refunds orders"| sys
  sys -->|"authorises and captures"| pay
  sys -->|"posts financial documents"| erp
  sys -->|"sends confirmations"| mail
  sys -->|"reads account and entitlement"| crm

Structural View

System Context Diagram

The single box of your system surrounded by the people and external systems it talks to, and nothing about how it is built inside.

Context Diagrams Discovery

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 TB
  subgraph fwd["Forward path"]
    direction LR
    f1["1. Reserve stock"] --> f2["2. Authorise payment"] --> f3["3. Create consignment"] --> f4["4. Capture payment"] --> f5["5. Despatch"]
  end
  subgraph comp["Compensation"]
    direction RL
    k1["Release stock"] --- k2["Void authorisation"] --- k3["Cancel consignment"] --- k4["Refund<br/><i>visible to customer</i>"]
  end
  f1 -.->|"undo"| k1
  f2 -.->|"undo"| k2
  f3 -.->|"undo"| k3
  f4 -.->|"undo"| k4
  f5 -.->|"no undo — goods have left"| x(["point of no return"])

Behavioural View

Saga Compensation Flow

A multi-service transaction as forward steps each paired with an undo, showing where the sequence becomes irreversible.

Sagas & Compensation Design

sequenceDiagram
  autonumber
  participant C as Client
  participant G as API Gateway
  participant O as Order Service
  participant P as Payment Gateway
  participant Q as Event Log

  C->>G: POST /orders (Idempotency-Key)
  G->>O: create order
  O->>O: persist as PENDING
  O->>P: authorise (deadline 3s)
  alt authorised
    P-->>O: approved + auth id
    O->>O: mark CONFIRMED
    O->>Q: OrderConfirmed
    O-->>G: 201 Created
  else declined
    P-->>O: declined
    O->>O: mark REJECTED
    O-->>G: 402 Payment Required
  else timeout
    P--xO: no response by deadline
    O->>O: keep PENDING
    O-->>G: 202 Accepted (poll for status)
    Note over O,P: reconciliation job settles<br/>PENDING against the provider
  end
  G-->>C: response

Behavioural View

Sequence Diagram

One scenario as an ordered exchange of messages between participants, with time on the vertical axis and the failure paths drawn rather than assumed.

Sequence Diagrams Design

stateDiagram-v2
  [*] --> Pending: order placed
  Pending --> Authorised: payment approved
  Pending --> Rejected: payment declined
  Pending --> Expired: no response in 24h
  Authorised --> Picking: stock allocated
  Authorised --> Cancelled: customer cancels
  Picking --> Shipped: consignment handed to carrier
  Picking --> Backordered: stock unavailable
  Backordered --> Picking: stock replenished
  Backordered --> Cancelled: customer cancels
  Shipped --> Delivered: carrier confirms
  Shipped --> Lost: no scan in 14 days
  Delivered --> Returned: return accepted
  Rejected --> [*]
  Expired --> [*]
  Cancelled --> [*]
  Delivered --> [*]
  Returned --> [*]
  Lost --> [*]

Behavioural View

State Machine Diagram

The legal states of one entity and the events that move it between them, which is where illegal transitions become visible.

Architecture Diagrams 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

flowchart TB
  inet(["Internet"])
  dc["Corporate Data Centre<br/><i>10.0.0.0/8</i>"]

  subgraph hub["Hub — 10.100.0.0/16"]
    direction TB
    fw["Egress Firewall<br/><i>FQDN allow-list</i>"]
    vpn["VPN / Direct Link<br/><i>BGP</i>"]
    dns["Private DNS Resolver"]
  end

  subgraph spokeA["Spoke: Prod — 10.101.0.0/16"]
    direction TB
    pub["Public Subnet<br/><i>10.101.0.0/24 — ingress LB only</i>"]
    app["App Subnet<br/><i>10.101.10.0/23 — no public IPs</i>"]
    data["Data Subnet<br/><i>10.101.20.0/24 — private endpoints</i>"]
    pub --> app --> data
  end

  subgraph spokeB["Spoke: Non-Prod — 10.102.0.0/16"]
    appn["App Subnet<br/><i>10.102.10.0/23</i>"]
  end

  inet -->|"443 only"| pub
  app -->|"all egress"| fw --> inet
  appn --> fw
  dc <-->|"BGP"| vpn
  vpn --- spokeA
  vpn --- spokeB
  spokeA x--x spokeB

Deployment & Infrastructure View

Network Topology Diagram

Segments, address ranges, routes and the control points between them — the view that says what can reach what at layer three.

Networking Design

sequenceDiagram
  autonumber
  participant B as Browser
  participant A as App / BFF
  participant I as Identity Provider
  participant R as Resource API

  B->>A: GET /protected
  A-->>B: 302 to IdP (PKCE challenge, state, nonce)
  B->>I: authorise request
  I->>B: authenticate + MFA
  I-->>B: 302 back with authorisation code
  B->>A: code + state
  Note over A,I: back channel — browser never sees these
  A->>I: exchange code + PKCE verifier + client secret
  I-->>A: access token (10 min), refresh token, id token
  A->>A: store tokens server-side<br/>set HttpOnly SameSite cookie
  A-->>B: session cookie only
  B->>A: subsequent request + cookie
  A->>R: call with access token (Bearer)
  R->>I: fetch/refresh signing keys (JWKS, cached)
  R->>R: verify signature, issuer, audience,<br/>expiry, scope
  R-->>A: 200
  A-->>B: rendered response
  Note over A,I: on expiry the BFF refreshes<br/>with rotating refresh token

Security View

Authentication Flow Diagram

The exact token exchange between browser, application, authorisation server and API — including what is short-lived, what is bound and what never touches the browser.

Secure API Design 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