Zachman Framework for Enterprise Architecture

The Zachman Framework, published by John Zachman in 1987 while at IBM, is the oldest and most conceptually pure contribution to enterprise architecture. Its insight is simple but powerful: to describe an enterprise completely, you must describe it from multiple perspectives (the rows) and through multiple interrogatives (the columns). The intersection of each perspective and interrogative is a distinct, irreducible cell.

Unlike TOGAF, the Zachman Framework is not a methodology — it tells you nothing about how to develop an architecture. It is an ontology: a classification schema that tells you what a complete description contains and, just as valuably, what is missing from an incomplete one.

This page explains the six rows, six columns, and the 36 cells, how Zachman differs from process frameworks, and how modern enterprises use it alongside TOGAF to get both method and completeness.

The rows represent the perspectives from which an enterprise can be described — each corresponding to a stakeholder with a different relationship to the enterprise. They are not levels of detail in a single model; they are genuinely different points of view, each with its own language, concerns, and models.

The distinction matters because a description accurate from the builder's perspective may be meaningless to the planner, and vice versa. The framework insists that each perspective is valid and must be represented in its own terms. Collapsing perspectives — for example, letting the implementer's physical view stand in for the owner's logical view — is how enterprises end up with systems that work technically but serve the business poorly.

The columns are the six interrogatives — What, How, Where, Who, When, and Why — that together exhaust the questions one can ask about anything. Each column is independent: you can describe the What (data) of the enterprise completely without yet describing its How (function), and so on. The independence is the source of the framework's completeness.

The columns map to: What (data/inventory), How (function/process), Where (network/distribution), Who (people/organisation), When (time/motivation-events), and Why (motivation/goals). Each column, viewed across the six rows, gives a complete description of one dimension of the enterprise.

The framework's rule of thumb: each cell is independent, and every model used to describe the enterprise belongs in exactly one cell. This is not pedantry — it is what makes the framework a useful audit of completeness.

The intersection of six rows and six columns produces 36 cells. Each cell is a distinct type of model or artifact. A complete enterprise description addresses every cell that is relevant to the current question. No single project ever fills all 36 — that is not the point. The point is to know which cells you are addressing and which you are leaving for later, and to be deliberate about it.

Practical use rarely involves building all 36 models. It involves using the grid as a checklist: when scoping an initiative, ask which cells the initiative touches, and ensure those cells are represented. The framework surfaces gaps — the Where and Who questions no one has asked — that ad-hoc approaches hide.

The grid also exposes redundancy and contradiction: two teams building different models that belong in the same cell are likely producing conflicting descriptions of the same thing, and the framework makes that visible.

A recurring question is whether to use Zachman or TOGAF. The answer is almost always both. Zachman provides the classification (what a complete description contains); TOGAF provides the method (how to produce and govern that description). They operate on different axes and compose cleanly.

In practice, organisations use TOGAF's ADM as the development process and Zachman's grid as the structure of the repository and a completeness check at each ADM phase. When Phase B (Business Architecture) claims to be complete, a Zachman check across the business-related cells validates that the What, How, Where, Who, When, and Why of the business have all been addressed.

A common misconception is that Zachman is obsolete — that modern, agile enterprises have outgrown a rigid 6×6 grid. The misconception comes from treating the framework as a methodology (which it is not) and from over-literal attempts to fill every cell. Used as intended — as an ontology and a completeness lens — Zachman remains as relevant in 2026 as in 1987, because the fundamental truth it encodes (different stakeholders see the enterprise differently, and completeness requires all interrogatives) is timeless.

Modern applications include using the grid to scope AI initiatives (which cells does an AI agent touch?), to structure architecture repositories, and to perform completeness audits of existing EA artifacts. Its perspective independence also makes it an excellent tool for stakeholder communication: you can show a business owner their row, a builder their row, and make the relationships explicit.

The framework's persistence also reflects a deeper point: enterprises are still enterprises, and describing them completely still requires multiple perspectives and all six interrogatives — even when the technologies those descriptions cover now include agents, vector databases, and sovereign cloud regions.