The Zachman Framework: What It Actually Is, and Isn't

Key Takeaways

• The Zachman Framework is a 6-by-6 classification grid, six interrogatives crossed with six perspectives, not a sequence of steps or a project methodology.
• Each of the 36 cells represents one type of artifact answering one question from one perspective; the same question answered from a different perspective produces a genuinely different artifact, not a more detailed version of the same one.
• Zachman doesn't replace TOGAF's Architecture Development Method or BIZBOK's guidance on capability and value stream modeling; it classifies where the artifacts those methods produce belong, which is a different job.
• Most practices that use Zachman successfully populate a handful of cells relevant to their current work rather than attempting to complete the full grid before doing anything else.
• The most common misuse is treating Zachman as a compliance checklist to complete rather than a classification tool to consult; that's what produces years-long documentation efforts that never connect back to a real decision.

Where the Framework Came From

The framework predates most of what's now taught as enterprise architecture.

John Zachman published the original version in "A Framework for Information Systems Architecture," in the IBM Systems Journal in 1987. The original framing was narrower than how the framework is used today: it was built around information systems architecture specifically, drawing an analogy to how architects and engineers use different representations, a bubble diagram, a floor plan, a construction drawing, to describe the same building for different audiences. The same logic, Zachman argued, should apply to the artifacts an enterprise produces to describe itself. Over time the framework's scope broadened from information systems to enterprise architecture generally, and it's this broader version that's referenced across the profession today.

The Grid: Six Questions, Six Perspectives

The framework's structure is its whole contribution, so it's worth being precise about it.

The six columns are the interrogatives: What (the data or things the enterprise deals with), How (the functions or processes it performs), Where (the locations and network involved), Who (the people and roles), When (the timing and events that matter), and Why (the motivation, goals, and strategy driving all of it). Every artifact an architecture practice produces answers one or more of these questions. The six rows are perspectives, moving from the most abstract to the most concrete: a planner's view of scope and context, an owner's view of the business itself, a designer's view of the logical system, a builder's view of the physical technology, a detailed, out-of-context view suited to a specific implementer, and finally the operating enterprise as it actually runs. The same question, answered from each successive perspective, gets more concrete and more specific, not just longer.

What Each Cell Represents

A cell in the grid is a type of artifact, not a document template.

Take the What column. Answered from the owner's perspective, it's typically something like a business's semantic or conceptual data model, the business entities that matter and how they relate, described in business language. Answered from the builder's perspective, the same What question produces something like a physical data schema, tables, columns, and data types, described in technical language for a specific platform. Both are legitimate, correct answers to What; they're just answering it from different vantage points for different audiences. This is the core insight of the framework: there isn't one right artifact for describing an enterprise's data, or its processes, or anything else. There are six legitimate perspectives on each question, and confusing one for another, showing an executive a physical schema, or asking a database administrator to work from a conceptual model alone, is a communication failure the framework is built to prevent.

What Zachman Is Not

The framework's biggest liability is how easily it gets mistaken for something it was never meant to be.

Zachman is not a methodology. It doesn't tell you which cell to populate first, how long that should take, or what process to follow to produce the artifact that belongs in a given cell. It's a classification system, an ontology for enterprise architecture artifacts, and organizations that treat it as a project plan, working through all 36 cells in sequence before doing anything else, tend to stall long before they reach a decision worth making. It's also not a governance process or a substitute for a capability or value stream model. Zachman can tell you that a capability map belongs somewhere in the What or How columns at the owner's perspective; it doesn't tell you how to build a capability map, what makes one well-formed, or how to govern it once it exists. That guidance comes from elsewhere.

How It Relates to Other Frameworks

Zachman and the frameworks it's most often compared against are usually doing different jobs, not competing ones.

TOGAF's Architecture Development Method gives a practice a repeatable process for producing architecture artifacts; Zachman doesn't provide a process at all, so the two aren't really in competition. The Business Architecture Guild's BIZBOK defines what a capability map or value stream map actually is and how to build one well; Zachman classifies where those artifacts sit in the bigger picture once they exist. Practitioners who use Zachman well tend to use it as a completeness check laid alongside whatever method they're actually using to do the work, not as a replacement for that method.

Using It in Practice Today

Most practices that get value from Zachman use a small slice of it, deliberately.

Very few organizations populate all 36 cells, and fewer still benefit from trying. The more common pattern is selective use: pulling out the rows most relevant to the audience in the room, often the owner and designer perspectives, and using the columns as a prompt to check that an initiative's documentation hasn't quietly skipped a question, that data and process have both been addressed, or that the motivation behind an initiative is written down somewhere rather than assumed. Used this way, the framework earns its keep as a communication and completeness tool rather than as an end in itself.

Frequently Asked Questions

Q: Is the Zachman Framework a methodology like TOGAF? A: No. TOGAF includes a defined process, the Architecture Development Method, for producing architecture. Zachman is a classification schema with no built-in process; it tells you where an artifact belongs, not how to create it or in what order. Q: How many cells does the Zachman Framework have? A: Thirty-six: six interrogative columns, What, How, Where, Who, When, and Why, crossed with six perspective rows, from planner through to the operating enterprise. Q: Do organizations need to complete all 36 cells? A: No, and most that try never finish or never connect the effort back to a real decision. Practices that get value from Zachman typically populate the cells relevant to the initiative in front of them and use the rest of the grid as a completeness check. Q: How does Zachman relate to a business capability map? A: A capability map is one of the artifacts that can be classified within the Zachman grid, generally in the What or How columns at the owner's perspective. Zachman doesn't define what makes a capability map well-formed or how to build one; that guidance comes from business architecture methods like BIZBOK. Q: Who created the Zachman Framework and when? A: John Zachman published the original framework in the IBM Systems Journal in 1987, in an article titled "A Framework for Information Systems Architecture." It was later generalized from information systems specifically to enterprise architecture more broadly.

Pro Tips

• Use Zachman as a question, not a template: before calling a set of artifacts complete, ask which of the six interrogatives hasn't been addressed for the audience you're serving, rather than trying to fill in every cell.
• If a stakeholder is confused by an artifact, check whether it's answering the right question for their perspective. A builder-level answer shown to an executive, or vice versa, causes more confusion than the artifact's actual content usually deserves.
• Pair Zachman with a method that actually tells you how to do the work, TOGAF's ADM, BIZBOK, or your organization's own architecture process. Zachman classifies; it doesn't execute.