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.

7 of 55 deliverables shown.

flowchart LR
  sales["Sales<br/><i>quote, opportunity, discount</i>"]
  orders["Ordering<br/><i>order, line, fulfilment</i>"]
  billing["Billing<br/><i>invoice, credit note, dunning</i>"]
  ship["Shipping<br/><i>consignment, manifest</i>"]
  legacy["Legacy Mainframe<br/><i>account master</i>"]

  sales -->|"Customer / Supplier"| orders
  orders -->|"Customer / Supplier"| billing
  orders -->|"Published Language"| ship
  legacy -->|"Anti-Corruption Layer"| orders
  billing -.->|"Shared Kernel — party identity"| sales

Structural View

Bounded Context Map

The domain model's fault lines — which parts of the business have their own language, and what kind of relationship each pair of them has.

Bounded Contexts Design

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 LR
  subgraph cust["Customer"]
    direction TB
    c1(["Submits claim"])
  end
  subgraph intake["Intake — automated"]
    direction TB
    a1["Validate policy"]
    a2{"Policy active<br/>and in cover?"}
    a3["Auto-assess<br/><i>rules + model</i>"]
    a4{"Confidence<br/>&ge; threshold?"}
  end
  subgraph handler["Claims Handler"]
    direction TB
    h1["Manual review"]
    h2{"Approve?"}
  end
  subgraph fin["Finance"]
    direction TB
    p1["Schedule payment"]
  end

  c1 --> a1 --> a2
  a2 -->|"no"| r1(["Reject — notify with reason"])
  a2 -->|"yes"| a3 --> a4
  a4 -->|"yes"| p1
  a4 -->|"no"| h1 --> h2
  h2 -->|"yes"| p1
  h2 -->|"no"| r2(["Decline — notify with appeal route"])
  p1 --> e1(["Paid"])

Behavioural View

BPMN Process Diagram

A business process as tasks in swim lanes with explicit decision points and handoffs, where crossing a lane boundary is the interesting event.

Business Processes Discovery

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

flowchart LR
  u1(["Employee<br/><i>managed laptop</i>"])
  u2(["Contractor<br/><i>unmanaged device</i>"])
  u3["Workload<br/><i>service identity</i>"]

  subgraph pep["Policy Enforcement"]
    direction TB
    px["Proxy / Gateway<br/><i>terminates every session</i>"]
  end

  subgraph pdp["Policy Decision"]
    direction TB
    eng{"Policy engine"}
    sig1["Identity + MFA"]
    sig2["Device posture"]
    sig3["Risk + location"]
    sig4["Resource sensitivity"]
    sig1 --> eng
    sig2 --> eng
    sig3 --> eng
    sig4 --> eng
  end

  subgraph res["Resources"]
    direction TB
    r1["Internal app"]
    r2[("Database")]
    r3["SaaS"]
  end

  u1 --> px
  u2 --> px
  u3 --> px
  px <-->|"authorise this request"| eng
  px -->|"allow · scoped · time-bound"| r1
  px -->|"allow · read-only"| r2
  px -->|"deny · posture fail"| r3
  log[("Decision log<br/><i>every allow and deny</i>")]
  eng --> log

Security View

Zero Trust Architecture Diagram

Access decided per request from identity, device and context rather than from network position, with the policy decision point drawn explicitly.

Network Security Design

flowchart TB
  t1["T-7d · Dry run in staging<br/><i>full rehearsal, timed</i><br/>owner: Delivery"]
  t2["T-1d · Freeze changes · verify backups<br/>confirm rota and bridge<br/>owner: Ops"]
  t3["T-0 00:00 · Enable read-only on legacy<br/>owner: Ops"]
  t4["T-0 00:15 · Final delta migration<br/><i>est 90 min · checkpoint at 60</i><br/>owner: Data"]
  t5["T-0 01:45 · Reconcile counts + checksums<br/>owner: Data"]
  g1{"T-0 02:15 · GO / NO-GO<br/><i>criteria: 100% row match,<br/>0 critical defects, all owners present</i>"}
  t6["T-0 02:30 · Repoint DNS + feature flag<br/><i>TTL pre-lowered to 60s</i><br/>owner: Platform"]
  t7["T-0 02:45 · Smoke suite + 10 manual journeys<br/>owner: QA"]
  g2{"T-0 03:30 · Accept or roll back"}
  t8["T-0 03:30 · Open to 10% traffic<br/>owner: Platform"]
  t9["T-0 06:00 · 100% traffic<br/>owner: Platform"]
  t10["T+24h · Hypercare ends<br/>legacy kept read-only 30d"]
  rb(["ROLLBACK · revert DNS<br/>re-enable legacy writes<br/><i>est 20 min</i>"])
  pnr["POINT OF NO RETURN<br/><i>after first write to new system<br/>rollback needs reverse migration</i>"]

  t1 --> t2 --> t3 --> t4 --> t5 --> g1
  g1 -->|"no-go"| rb
  g1 -->|"go"| t6 --> t7 --> g2
  g2 -->|"roll back"| rb
  g2 -->|"accept"| t8 --> t9 --> t10
  t8 -.-> pnr

Planning Artifact

Cutover Plan

The hour-by-hour sequence of go-live, with owners, checkpoints, the rollback decision point and the moment rollback stops being possible.

Zero-Downtime Migration Build