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.

4 of 55 deliverables shown.

flowchart TB
  subgraph sell["Sell"]
    direction LR
    s1["CRM<br/><i>SaaS · Sales</i>"]
    s2["Quoting<br/><i>bespoke · Sales</i>"]
    s3["Pricing A<br/><i>legacy · Sales</i>"]
    s4["Pricing B<br/><i>legacy · Regional</i>"]
  end
  subgraph fulfil["Fulfil"]
    direction LR
    f1["Order Mgmt<br/><i>bespoke · Ops</i>"]
    f2["WMS<br/><i>COTS · Ops</i>"]
    f3["Carrier Portal<br/><i>SaaS · Ops</i>"]
  end
  subgraph support["Support"]
    direction LR
    b1["ERP<br/><i>COTS · Finance</i>"]
    b2["Billing<br/><i>mainframe · Finance</i>"]
    b3["HRIS<br/><i>SaaS · HR</i>"]
    b4["Expenses<br/><i>SaaS · unowned</i>"]
  end
  s3 -.->|"same capability"| s4

Structural View

Application Landscape Diagram

Every application in the estate placed against the business areas it serves, so duplication and orphans become visible.

Application Portfolio Management Discovery

flowchart TB
  subgraph core["Customer-Facing"]
    direction LR
    c1["Customer<br/>Management"]
    c2["Product &<br/>Catalogue"]
    c3["Order<br/>Capture"]
    c4["Fulfilment"]
  end
  subgraph enable["Enabling"]
    direction LR
    e1["Pricing &<br/>Promotion"]
    e2["Inventory<br/>Management"]
    e3["Payments &<br/>Settlement"]
    e4["Returns &<br/>Claims"]
  end
  subgraph support["Supporting"]
    direction LR
    s1["Finance &<br/>Accounting"]
    s2["Human<br/>Resources"]
    s3["Procurement"]
    s4["Risk &<br/>Compliance"]
  end

Structural View

Business Capability Map

What the business is able to do, arranged as a stable nested hierarchy of abilities with no processes, systems or org units on it.

Capability Mapping Discovery

flowchart TB
  subgraph l1["Experience"]
    direction LR
    e1["Web"] --- e2["Mobile"] --- e3["Partner Portal"]
  end
  subgraph l2["Channel & API"]
    direction LR
    c1["API Gateway"] --- c2["BFF"] --- c3["Event Ingress"]
  end
  subgraph l3["Business Services"]
    direction LR
    b1["Ordering"] --- b2["Pricing"] --- b3["Fulfilment"] --- b4["Billing"]
  end
  subgraph l4["Integration"]
    direction LR
    i1["Message Broker"] --- i2["Adapters"] --- i3["File Transfer"]
  end
  subgraph l5["Data"]
    direction LR
    d1["Operational Stores"] --- d2["Analytical Platform"] --- d3["Cache"]
  end
  subgraph l6["Infrastructure"]
    direction LR
    f1["Compute"] --- f2["Network"] --- f3["Storage"]
  end
  l1 --> l2 --> l3 --> l4 --> l5 --> l6

  sec["Security<br/>&<br/>Identity"]
  ops["Observability<br/>&<br/>Operations"]

Structural View

Layered Architecture Diagram

The solution as horizontal capability tiers with cross-cutting concerns as vertical bars — the picture executives expect and the one most often drawn without meaning.

Reference Models Design

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