Module 1: Start Here

Overview

This module answers one question, and every page is a step toward it:

What is this job, and what am I actually responsible for here?

Most people move into architecture carrying a definition picked up by osmosis — usually “the person who chooses the technology” or “the person who draws the diagrams”. Both are wrong, and both take about a year to unlearn on the job. This module tries to skip that year.

How the module is built

Two sections. The first is about the job as it has existed for decades. The second is about what has changed recently, and it is not a footnote — it is roughly half the module.

graph TD
  subgraph S1["Section 1 — The architect's working context"]
    A["1 · What architecture<br/>actually is"]
    B["2 · Why the job exists:<br/>creating value"]
    C["3 · Standing on other<br/>people's work: frameworks"]
    D["4 · Who you actually serve:<br/>stakeholders and expectations"]
    A --> B --> C --> D
  end
  subgraph S2["Section 2 — The AI-era paradigm shift"]
    E["5 · Code as Liability"]
    F["6 · Probabilistic<br/>architecture"]
    G["7 · Domain Authority"]
    H["8 · Guardrails"]
    I["9 · New primitives:<br/>agents, RAG, MCP"]
    J["10 · AI-Readiness:<br/>Documentation as Code"]
    E --> F --> G --> H --> I --> J
  end
  D ==> E
  J ==> K(["Workbook — Exercise 1"])

  classDef s1 fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef s2 fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cap fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A,B,C,D s1
  class E,F,G,H,I,J s2
  class K cap

The module’s path. Each topic hands a question to the next one.

Section 1 — The architect’s working context

What the job is → why it exists → what tools exist for it → who you answer to.

1. What architecture actually isA usable definition, and the three types that share the word.

2. Why the job exists: creating valueThe chain from business driver to system structure.

3. Standing on other people's work: frameworksTOGAF and Zachman, adapted rather than adopted.

4. Who you actually serve: stakeholdersInterests versus positions, and the charter that defines your remit.

Section 2 — The AI-era paradigm shift

What changes when the systems you design are no longer predictable.

5. Code as LiabilityThe shift from writing to verifying.

6. Probabilistic architectureDesigning when the same input gives different answers.

7. Domain AuthorityWhy business understanding outranks syntax.

8. GuardrailsSetting boundaries for systems that act on their own.

9. New primitivesMulti-agent systems, RAG and MCP — what each costs architecturally.

10. AI-ReadinessBuilding systems that machines can understand too.

How to work this module

About five hours, split roughly three to two:

1. Read the ten topics — about 3 hours. That’s study time, not skim time; stopping at the diagrams and answering the closing questions is where the value is.

2. Optional — Workbook exercise 1 — about 2 hours. Four documents, all for the same company.

Read in order. Each topic assumes the one before it, and several later ones call back to earlier ones by name.

In the workbook

Four documents for Lintel, the company you design for across all ten modules:

• A business-value brief — the initiative in the CFO’s language, not engineering’s
• An architecture charter — your remit, and explicitly what you are not accountable for
• A system context diagram — what surrounds the system, not what’s inside it
• A stakeholder map — a first-impression reading, revised much later in Module 8

These build up as you read rather than arriving all at once at the end. Each topic that feeds one says so.

Before you start

Read the Lintel case first. Every topic refers to its people and numbers, and none of them will re-explain it.

This guide assumes you already know how systems are built. Distributed systems, databases, queues, caching, security — assumed background, referenced in a line rather than taught. What’s being taught here is the part that isn’t in those books: how architecture actually gets done inside a company that has opinions, history, and no spare capacity.

Check your understanding

Write down your current answers. Come back at the end of the module and compare — the gap is the point.

1. In one sentence, what do you currently think an architect is accountable for?
2. Think of a technical decision you made recently. What business outcome did it change, and could you put a number on it?
3. If a component gave a slightly different answer each time it ran, which part of your usual design approach would stop working?

→ Start with What architecture actually is.