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.

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

Security View

Security Control Matrix

Each required control mapped to the specific mechanism that implements it, the evidence it produces and the person accountable for it.

Compliance Frameworks Design

flowchart LR
  user(["Customer<br/><i>untrusted</i>"])
  admin(["Admin<br/><i>privileged</i>"])

  subgraph edge["Boundary 1 — public edge"]
    cdn["CDN / WAF"]
  end

  subgraph app["Boundary 2 — application tier"]
    direction TB
    api["Order API"]
    auth["Auth Service"]
  end

  subgraph datab["Boundary 3 — data tier"]
    direction TB
    db[("Order Store<br/><i>PII + card token</i>")]
    kms[("Key Vault")]
  end

  ext["Payment Provider<br/><i>third party</i>"]

  user -->|"F1 HTTPS"| cdn
  cdn -->|"F2 HTTPS + mTLS"| api
  admin -->|"F3 admin console"| api
  api -->|"F4 token introspection"| auth
  api -->|"F5 TLS + parameterised"| db
  api -->|"F6 fetch DEK"| kms
  api -->|"F7 HTTPS outbound"| ext
  ext -->|"F8 webhook — signed"| cdn

Security View

Threat Model Data Flow Diagram

Processes, stores and flows with trust boundaries drawn across them, so that every boundary crossing can be enumerated for threats.

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