Standing on Other People's Work: Frameworks

Overview

TOGAF and Zachman are the two best-known architecture frameworks. Both were built for large enterprises with dedicated architecture departments. You are probably one architect in a company that has none.

Adopting either wholesale would bury you. Ignoring them means re-deriving things people worked out decades ago. This topic is the middle path.

The first distinction

TOGAF — The Open Group Architecture Framework — is a method. It describes a process for developing architecture: what to do, in what order, what to produce at each step. Its centrepiece is the ADM, the Architecture Development Method, a cycle of phases.

Zachman — the Zachman Framework — is not a method. It’s a classification scheme: a grid saying what kinds of description a complete architecture contains. It tells you what should exist; it says nothing about how to produce it.

They’re often mentioned in the same breath, but one is a recipe and the other is a checklist of ingredients. Confusing them is the first mistake.

What’s worth stealing from TOGAF

The four phases worth taking — these survive the trip to a mid-sized company:

graph LR
  A["A · Architecture Vision<br/>agree the goal,<br/>get it endorsed"] --> B["B · Business Architecture<br/>understand how the<br/>work actually happens"]
  B --> E["E · Opportunities<br/>& Solutions<br/>options, then a decision"]
  E --> F["F · Migration Planning<br/>getting there is its<br/>own design problem"]

  classDef keep1 fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef keep2 fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef keep3 fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef keep4 fill:#4E9A94,stroke:#3B7A75,stroke-width:2px,color:#ffffff
  class A keep1
  class B keep2
  class E keep3
  class F keep4

The full cycle they come from — the greyed phases assume governance staff you do not have:

graph TD
  P["Preliminary"] --> A["A · Architecture Vision"]
  A --> B["B · Business Architecture"]
  B --> C["C · Information Systems"]
  C --> D["D · Technology Architecture"]
  D --> E["E · Opportunities & Solutions"]
  E --> F["F · Migration Planning"]
  F --> G["G · Implementation Governance"]
  G --> H["H · Change Management"]
  H -->|"cycle repeats"| A

  classDef keep fill:#E8A33D,stroke:#C4832A,stroke-width:3px,color:#ffffff
  classDef skip fill:#D8D3CB,stroke:#B8B2A8,stroke-width:1px,color:#5E5E5E
  class A,B,E,F keep
  class P,C,D,G,H skip

The TOGAF ADM cycle. Four phases survive the trip to a mid-sized company; the rest assume governance staff you don’t have.

Vision before detail (A). Agree what you’re trying to achieve, and get it endorsed, before designing anything. In practice: the business-value brief agreed with your sponsor and whoever holds the budget, before any technology is chosen.

Business before technology (B). Understand how the work actually happens — who does what, where time goes, what the headline number really counts — before designing the system that changes it.

Options, then a decision (E). Generate several approaches, evaluate against requirements, record why you chose. This is the discipline that survives your departure.

Migration as its own design problem (F). Getting from here to there is a design problem in its own right, especially where there’s no spare capacity and an existing migration already consumes everything.

What to leave: the full document set, formal governance, the architecture board, compliance reviews. Not because they’re wrong, but because they assume an organisation with people to staff them. Below a certain size they produce paperwork nobody reads.

Zachman as a coverage checklist

Zachman’s grid crosses six questions — what, how, where, who, when, why — against perspectives from executive down to implementer.

Ignore the formality. Keep the six questions, and use them to find the gap in your own thinking:

Question	Applied to an AI support platform
What	Which data? Documentation, historical tickets, customer records — which contain personal data?
How	What does the process do, step by step, including handoff to a human?
Where	Which region does each piece run in? Often a hard constraint, not a preference
Who	Which people and systems act? The support team, the agent itself, the customer
When	What’s real-time, what’s batch? How fresh must the index be?
Why	Which business driver does each part serve?

Run this over any design and one column is usually empty. In AI projects it’s most often where and who — teams design the flow of information and forget which jurisdiction it runs in, and who is accountable when it acts wrongly. Both are frequently the difference between a design your compliance lead approves and one they block.

That’s the whole value: a cheap way to notice what you forgot.

Framework theater

Framework theater is producing the artifacts without doing the thinking. It looks like architecture and costs like architecture, but nothing is decided.

The signs:

• Documents describing the current state in detail and making no decisions
• A diagram everyone approves and nobody uses
• Templates filled in because the template exists
• Architecture reviews where the outcome is never “no”

The reason it happens is worth understanding, because it isn’t stupidity. Frameworks offer certainty. When you’re accountable for decisions you can’t fully justify — the normal condition of the job — following a documented method feels safer than exercising judgment. If the method was followed and the project fails, the method was at fault.

The defence is to keep asking what a document is for. Who reads it? What decision does it enable? What changes if it doesn’t exist? A document with no answer isn’t architecture. It’s insurance.

Sizing the practice

You have no architecture practice at all — no board, no decision records, no templates. So you don’t have a theater problem yet. You have the opposite: nothing is written down, and decisions live in people’s heads.

The right move at this size is the smallest thing that helps, letting it earn its place. Take the four TOGAF ideas, keep Zachman’s six questions as a private checklist, and add process only when its absence visibly hurts.

The cost of going light: less consistency, and more depending on you personally. That’s the correct trade at 140 engineers. It stops being correct somewhere around 400 — knowing when it flips is Module 10’s problem.

Feeds the workbook

Run Zachman’s six questions over your business-value brief. Whichever column comes out thinnest is where the brief is weakest.

Check your understanding

1. Which of the four “steal this” phases would be hardest to do in your organisation, and why?
2. Run the six questions over the initiative in the case. Which column is emptiest for you, and what would you need to find out to fill it?
3. A compliance lead asks for “the architecture document” before approving anything, without saying what they need in it. How do you respond without producing theater?

---

→ Frameworks tell you how to think. They don’t tell you who has to agree. — Who you actually serve: stakeholders and expectations