The oldest EA framework, born from a 1987 IBM Systems Journal paper. Zachman observed that complex engineering disciplines (aircraft, buildings) describe one product from multiple perspectives, each answering different questions — and that information systems needed the same discipline. The result is a 6×6 classification matrix: it tells you what kinds of descriptions exist, never how or in what order to produce them.

Columns are the interrogatives — What (data), How (function), Where (network), Who (people), When (time), Why (motivation). Rows are audiences, from the executive setting scope down to the running enterprise. Each cell holds one primitive model. The key rule: moving down a row is a transformation of perspective, not just "more detail" — the owner's business-entity model and the architect's logical data model are different models of the same thing.

Zachman names the movement down the rows reification — the process by which an abstract idea becomes a running instance: Identification (executive names what matters) → Definition (business management defines the concepts) → Representation (architect represents them as system logic) → Specification (engineer specifies the technology) → Configuration (technician configures the tools) → Instantiation (the enterprise runs). Each arrow is a translation between audiences, and every translation is a place where intent can be lost — which is exactly where architects add value.

Read the column bottom-up and you get audit traceability: which executive concern does this table serve? Read it top-down and you get impact analysis: if the business redefines "Order", what breaks? This column trace — not the full grid — is how Zachman gets used in anger (see Case study 04 below).

The most widely adopted EA framework. Where Zachman classifies, TOGAF prescribes a process: the Architecture Development Method (ADM), a repeatable cycle for taking an enterprise from a current state to a target state with governance along the way. It covers four architecture domains — Business, Data, Application, Technology (BDAT) — and TOGAF 10 restructured the content into a small stable core plus extended guidance so it can be adopted piecemeal.

The ABB → SBB distinction is TOGAF's quiet masterstroke: phases B–D specify ABBs, phase E maps them to SBBs. Keeping the two apart is what lets you change vendors without rewriting the architecture.

A TOGAF principle has four mandatory parts — Name, Statement, Rationale, Implications. The implications are what separate a principle from a poster on the wall:

Keep 5–10 principles, no more. When two principles conflict on a real decision (they will), the resolution is an ADR — and that's the system working, not failing.

Every domain phase (B, C, D) ends the same way: draw a matrix with baseline building blocks as rows, target building blocks as columns. Where a baseline block maps to a target block — carried forward (possibly upgraded). A baseline row with no target column — eliminated (deliberately, or you've found an accidental omission). A target column with no baseline row — new, and every "new" cell is a gap that must land in a work package in Phase E. The discipline isn't the matrix; it's that nothing gets eliminated or created by accident.

The ADM diagram looks like a waterfall; the standard itself says it isn't. It runs as nested loops: an Architecture Capability iteration (Preliminary + A) when the practice itself changes, an Architecture Development iteration (B–D) that cycles as understanding improves, a Transition Planning iteration (E–F) as plans meet budget reality, and an Architecture Governance loop (G–H) that runs continuously. The Landscape is also layered by altitude — strategic (the whole enterprise, low detail), segment (one business area), capability (one capability increment, high detail) — and a full ADM cycle can run at any of the three. A two-week capability-level cycle is still TOGAF.

The standard notation for enterprise architecture — what UML is to software design, ArchiMate is to the enterprise. It defines a precise vocabulary of elements and relationships across layers, so a model means the same thing to every reader. TOGAF says when to model; ArchiMate says how to draw it.

Each layer is crossed with three aspects: active structure (who/what acts), behavior (what happens), and passive structure (what is acted upon). This layer × aspect grid is ArchiMate's quiet homage to Zachman.

Every ArchiMate layer repeats one service-oriented pattern: internal active structure (a component, a team) is assigned to internal behavior (a process, a function), which realizes an externally visible service, exposed through an interface, which serves the layer above. That's why the language composes so cleanly across layers: the business layer consumes application services; the application layer consumes technology services. Once you see the pattern, you can model anything in it — and spot models that break it (an app "serving" another app's database directly, say) at a glance.

Goal "Reduce claim settlement time" (motivation) is realized by capability "Claims Management" (strategy) ← realized by business process "Handle claim" performed by role "Claims handler" (business) ← served by application service "Claims processing service" realized by component "ClaimCenter" (application) ← served by technology service "Container platform" realized by node "AKS cluster" (technology). One connected chain — so when someone proposes retiring ClaimCenter, the model answers instantly: which process stalls, which capability degrades, which goal is at risk. That query is the business case for maintaining the model.

Born as a reaction to two failure modes: meaningless boxes-and-lines on whiteboards, and heavyweight UML nobody maintains. C4 describes one software system at four zoom levels — "Google Maps for your codebase" — with strict notation hygiene so every diagram is self-explanatory.

C4's real contribution isn't the diagrams; it's the shared abstraction model: a person uses a software system, which is made of containers, which are made of components, which are made of code — connected by relationships. Agree on those words first and any notation works; skip that agreement and no notation saves you. This is why a team fluent in C4 can whiteboard coherently: they're not sharing a drawing style, they're sharing a vocabulary.

workspace "Checkout" {
  model {
    customer = person "Customer" "Buys products online"
    checkout = softwareSystem "Checkout System" {
      spa    = container "Checkout SPA"  "Cart & payment UI"   "React"
      api    = container "Checkout API"  "Order orchestration" "Spring Boot"
      db     = container "Orders DB"     "Order storage"       "PostgreSQL" "Database"
      events = container "Event Bus"     "Order events"        "Kafka"
    }
    stripe = softwareSystem "Stripe" "Payment provider" "External"

    customer -> spa    "Uses"                "HTTPS"
    spa      -> api    "Calls"               "JSON/HTTPS"
    api      -> db     "Reads from / writes to" "JDBC"
    api      -> events "Publishes events to" "Kafka protocol"
    api      -> stripe "Charges cards via"   "REST"
  }
  views {
    systemContext checkout "Context"   { include *  autolayout lr }
    container     checkout "Containers" { include *  autolayout lr }
  }
}

One model, two views — and the point is what happens next: rename api once and every view updates; add a container and the context diagram doesn't change (right altitude, no noise). The file lives in Git, so architecture changes show up in pull requests next to the code that caused them.

Two complementary open templates. arc42 answers "how do we document a system?" with twelve sections, each answering exactly one question. ADRs (Architecture Decision Records) answer "why is it built this way?" — one significant decision per file, written when the decision is made, immutable afterwards.

arc42's sharpest discipline: a quality goal isn't an adjective, it's a scenario — stimulus → environment → response → measure. The measure is what makes it testable, and testable is what makes it architecture rather than aspiration:

Pick the top 3–5 and rank them (§1.2) — an architecture that optimizes everything optimizes nothing. The full scenario catalog lives in §10 as a tree: quality attribute → refinement → concrete scenarios.

§5 is hierarchical white-box / black-box decomposition. Level 1: the whole system as a white box — show its top-level building blocks (these are your C4 containers) and, for each, a black-box description: responsibility, interfaces, quality characteristics. Level 2: open only the blocks that are complex or risky enough to warrant it — each becomes its own white box (C4 components). Level 3 is rare. Two rules keep it honest: every white box needs a stated decomposition rationale (by domain? by team? by rate of change?), and you stop decomposing when the next level would only restate the code.

Three more names you'll meet in job specs and RFPs — each real, each with a legitimate niche, each worth understanding properly even if you never adopt it.

Born from the Clinger-Cohen Act (1996), which legally required US federal agencies to maintain an IT architecture. FEAF's core is a set of shared reference models — a common taxonomy so that spending and systems can be compared across agencies and duplicates consolidated. That purpose (compare & consolidate at portfolio scale) is why it looks bureaucratic from a delivery seat: it isn't for building systems, it's for governing thousands of them.

DoDAF (US Department of Defense) organizes architecture descriptions into viewpoint families, each a set of prescribed views. Its center of gravity is interoperability: forcing hundreds of contractors' systems to document themselves the same way so they can be integrated and compared. MODAF was the UK's adaptation; both now converge on the NATO Architecture Framework (NAF). If you work in defense, aerospace, or national-scale public safety, the RFP will name these and compliance is non-negotiable; outside those worlds you'll never see them.

Worth stealing even outside defense: the OV/SV split — describe the mission without technology first, then map systems onto it — is the same discipline as capability-before-application, enforced by contract.

The Business Architecture Guild's body of knowledge (with its own certification, CBA). Its premise: the business can and should be modeled independently of IT — then IT maps onto it. Four core artifact types interlock:

Heat mapping is the signature move: color the capability map by any lens — strategic importance, current maturity, IT spend, incident volume — and misalignment becomes visible to a board in seconds ("our most strategic capability has our weakest systems"). In TOGAF terms all of this slots into Phase B; in this skill it's Mode 4's foundation.