Aldermont's core consolidation program has produced a lot of documents. There is a customer data model from the data architects, a set of process maps from the business analysts, a network diagram from the infrastructure team, a project schedule from the program office, and a list of regulatory obligations from compliance. Each is correct. Each was made by a different group for a different reason. And no one can say whether, together, they describe the same bank completely, or whether there are gaps between them where something important has fallen through.
The chief enterprise architect has a nagging question. Do we actually have a full description of this bank, or just a pile of overlapping partial views? To answer that, you need a way to lay every one of those documents out on a single grid and see, at a glance, what is covered and what is missing. That grid is the Zachman Framework.
What Zachman is, and what it is not
The Zachman Framework was created by John Zachman in the 1980s, and it is the oldest of the well-known enterprise architecture frameworks. It is also the most misunderstood, almost always because people expect it to be the same kind of thing as TOGAF. It is not.
TOGAF, from the previous post, is a method: it tells you what to do and in what order. Zachman tells you to do nothing at all. It is a classification schema, a way of organizing descriptions of an enterprise so that every kind of description has exactly one place to live. It is closer to the periodic table than to a recipe. The periodic table does not tell you how to run an experiment; it gives every element a defined position so you can see the whole space at once and notice what is missing.
The core idea: Zachman is a two-dimensional grid. One axis asks six fundamental questions about the enterprise. The other axis asks from six different perspectives. Every artifact an organization produces, every model, document, and diagram, belongs in exactly one cell where a question meets a perspective. Fill the grid and you have a complete description. See the empty cells and you have found your blind spots.
That is the whole value proposition. Zachman does not produce artifacts and it does not sequence work. It gives you a filing system precise enough that the gaps become visible. Everything else follows from the two axes, so those are worth understanding properly.
The first axis — six questions
The columns of the grid are the six basic interrogatives, the questions you can ask about anything at all. Zachman's insight was that a complete description of an enterprise has to answer all six, and that they are genuinely independent: answering one tells you nothing about the others.
What covers the data and things the enterprise deals with. For Aldermont: customers, accounts, transactions, loans. How covers the processes and functions, the things the enterprise does: originate a mortgage, settle a payment, detect fraud. Where covers locations and the network: the data centers, the branches, the cloud regions. Who covers the people and organization: the roles, teams, and responsibilities. When covers timing and events: the batch cycles, the settlement windows, the event triggers. Why covers motivation: the goals, strategies, and regulatory drivers behind everything else.
The discipline of the six questions is that they force completeness. It is easy to produce a detailed answer to "what" and "how" and quietly never address "why" or "when." A bank that has modeled its data and processes beautifully but never wrote down the regulatory motivations behind them has an invisible gap, and the columns make that gap a named, empty space rather than an unnoticed absence.
The second axis — six perspectives
The rows of the grid are six perspectives, and this is the more subtle axis. The same enterprise looks completely different depending on who is describing it, and Zachman's point is that these are not more-or-less detailed versions of one description. They are genuinely different descriptions, each valid, each owned by different people.
The perspectives run from the most abstract at the top to the most concrete at the bottom. The Scope perspective is the executive's view: the bank as a list of the things it cares about, no detail. The Business Model perspective is the business owner's view: how the bank actually operates, in business terms. The System Model perspective is the architect's view: the logical design, independent of technology. The Technology Model perspective is the engineer's view: how it is built with specific technologies. The Detailed Representation perspective is the subcontractor's view: the actual configurations and code. And the bottom row is the Functioning Enterprise: the running reality itself, the live systems as they actually operate.
The reason this axis matters is that the same word means different things at different rows, and confusing them causes real damage. "Customer" at the Business Model row is a business concept: a person or organization the bank has a relationship with. "Customer" at the Technology Model row is a specific database table with typed columns. Both are correct descriptions of the same thing from different perspectives, and a discussion that slides between the two without noticing is how architecture meetings go in circles.
The grid itself
Put the two axes together and you get a 6x6 matrix of thirty-six cells. Each cell is the intersection of one question and one perspective, and each holds a specific, distinct kind of description.
The rule that makes the grid work is that each cell holds one specific kind of model, and no cell duplicates another. The What column at the Business Model row holds a conceptual data model in business language. The What column at the Technology Model row holds a physical database schema. Same question, different perspective, genuinely different artifact. A well-run architecture practice can point to which cell any given document belongs in, and if two documents claim the same cell, one of them is redundant or they disagree.
Putting an Aldermont artifact in its cell
Abstraction dissolves the moment you place a real document on the grid. Take the customer data model the data architects produced for the consolidation program. Which cell does it belong in?
It answers the What question, so it is in the first column. It is a logical design, technology-independent, expressing what a customer is in structural terms without committing to a specific database. That puts it at the System Model perspective. So it lands in exactly one cell: What, System Model. Naming that cell is not pedantry. It immediately tells you what this document is not, and therefore what else must exist for the description to be complete.
Now the grid earns its keep. That single data model sits at one cell in one column. The framework immediately prompts the questions no one had asked: where is the What model at the Business perspective, the plain-language definition the business owners agreed to? Where is the Why column entirely, the regulatory motivations that constrain what a customer record must contain? The data architects produced an excellent artifact for one cell and, without a grid, no one could see that thirty-five other cells were sitting empty or unowned.
How Zachman and TOGAF fit together
Because the two frameworks are so often framed as rivals, it is worth being clear: they are not competitors, because they are not the same kind of thing. One is a method and one is a schema, and an organization can use both at once without contradiction.
The clean way to see it is that TOGAF's ADM is the process that produces artifacts, and Zachman's grid is the filing system those artifacts get sorted into. As Aldermont runs the ADM and generates its business, data, application, and technology models, each deliverable can be dropped into a Zachman cell. The grid then serves as a completeness check on the method's output: run a phase, file what it produced, and look at which cells are still empty.
This is also why Zachman is rarely adopted on its own in practice. A pure filing system with no method behind it gives you nowhere to start; you can classify artifacts you already have, but the grid will not generate the missing ones for you. Zachman is at its best as a lens laid over an active architecture practice, not as the practice itself.
Where you will actually encounter it
Few organizations run a formal, fully populated Zachman grid. What is common is Zachman thinking, often without the name attached. Any time someone asks "have we looked at this from the business perspective as well as the technical one," that is the perspective axis. Any time a review catches that a design answers what and how but never addresses why or when, that is the question axis doing its job.
The framework's most durable contribution is the discipline of the two axes as a mental checklist. Even an architect who has never drawn the full grid benefits from internalizing that a complete description answers all six questions from all the perspectives that matter, and that sliding between perspectives without noticing is a reliable source of confusion. That habit of mind outlasts any particular diagram.
Summary
The Zachman Framework is a classification schema, not a method, and almost every misunderstanding of it comes from expecting otherwise. It is a 6x6 grid: six questions (what, how, where, who, when, why) crossed with six perspectives (from the executive's scope down to the functioning enterprise). Every artifact an organization produces belongs in exactly one cell, and the framework's power is that the empty cells are as informative as the full ones.
For Aldermont, the grid answered the chief architect's nagging question. The pile of correct-but-overlapping documents was not a complete description of the bank; it was a scattering of filled cells with conspicuous holes, an unowned Why column and a missing business-perspective data model chief among them. Zachman does not build anything, and used alone it stalls for lack of a method. Laid over an active practice like a running ADM, it becomes the completeness check that catches the gap before the gap becomes an incident. TOGAF tells you how to do the work; Zachman tells you whether the work is done.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.