The Zachman Framework is a way to organize everything you know about an enterprise so that nothing important goes undocumented. It is a 6×6 grid: six questions you can ask about any organization (what, how, where, who, when, why) crossed with six points of view (from the executive down to the person running the system). Where a question meets a point of view, you get one cell, and each cell holds one model. Thirty-six cells, thirty-six models, one complete picture.
The single most useful thing to understand up front: Zachman is an ontology, not a methodology. It tells you what to describe and how the pieces relate. It does not tell you how to build anything or in what order. That is why teams often pair it with TOGAF, which supplies the process the Zachman grid deliberately leaves out. This guide covers the structure, a worked example filled in for an ERP rollout, the honest limits, and what certification actually costs.
What is the Zachman Framework?
John Zachman developed the framework at IBM in the 1980s and published it formally in 1987, in the paper “A Framework for Information Systems Architecture” (IBM Systems Journal, Vol. 26, No. 3). It is widely credited as the first formal framework for enterprise architecture, and most of the frameworks that came after it borrow its idea of describing an enterprise from several viewpoints at once.
The framework does one job well: it classifies. Every document, diagram, data model, and configuration your organization produces has exactly one place in the grid. If a cell is empty, you have found a gap in what you know about your own enterprise. If two teams have filled the same cell with different answers, you have found an inconsistency worth resolving. That is the whole value proposition, and it is a real one.
Ontology vs methodology
This distinction trips up most people who meet Zachman for the first time, so it is worth being precise.
| Ontology (what Zachman is) | Methodology (what Zachman is not) |
| A structured way to classify the things that make up an enterprise and show how they relate. It is the schema, the set of boxes and the rules for what belongs in each. The Zachman Framework is an ontology. | A sequence of steps that takes you from one state to another: gather requirements, design, build, deploy. Methodologies tell you what to do next. TOGAF’s ADM, Agile, and most project methods are methodologies. |
Because it is an ontology, Zachman never goes out of date the way a process can. It also never delivers anything on its own. You still need a method to fill the cells and a project to act on them.
The six columns and six rows
The six columns are the plain questions you can ask about anything. Each has a formal model name in the current version of the framework:
- What (Inventory Sets) – the data and things the enterprise works with
- How (Process Flows) – the functions and processes it performs
- Where (Distribution Networks) – the locations and how they connect
- Who (Responsibility Assignments) – the roles, people, and organizations
- When (Timing Cycles) – the events, schedules, and cycles
- Why (Motivation Intentions) – the goals, drivers, and rules
The six rows are points of view, running from the most abstract at the top to the working system at the bottom. In the current version (3.0), the official names are:
- Executive Perspective (Scope Contexts) – the planner’s boundary lists: what is in scope
- Business Management Perspective (Business Concepts) – the owner’s view of how the business actually works
- Architect Perspective (System Logic) – the designer’s technology-neutral logical models
- Engineer Perspective (Technology Physics) – the builder’s technology-specific physical design
- Technician Perspective (Tool Components) – the out-of-context, tool-level detail
- Enterprise Perspective (Operations Instances) – the functioning enterprise in production
As you move down a column, the same subject gets more concrete. The “What” column, for example, starts as a list of the things you care about, becomes a business data model, then a logical data model, then a physical database design, then the actual tables, and finally the live data sitting in production.
Zachman Framework example: an ERP implementation, cell by cell
Most explanations of Zachman describe the grid and stop. Here is the part that is usually missing: the grid actually filled in. The table below maps a single, concrete project, a manufacturer rolling out ERP across a head office, three plants, and two distribution centers, onto all thirty-six cells. Read a column top to bottom to watch one subject move from a scope list to running production. Read a row left to right to see one stakeholder’s complete picture.
| Perspective (stakeholder) | What – Data | How – Process | Where – Network | Who – People | When – Time | Why – Motivation |
|---|---|---|---|---|---|---|
| Executive (scope) | List of entities the ERP will hold: items, BOMs, customers, suppliers, GL accounts | List of processes in scope: order-to-cash, procure-to-pay, plan-to-produce | List of sites: head office, 3 plants, 2 distribution centers | List of affected functions: finance, procurement, production, sales | List of business cycles: fiscal calendar, month-end close, weekly MRP run | Business goals: cut inventory 15%, one source of truth, retire the legacy system |
| Business Management (owner) | Semantic model linking Customer, Order, Item, BOM, and Invoice | BPMN model of order-to-cash the way the business runs it today | Material-flow map between plants and distribution centers | Org chart plus a RACI for PO and production-release approvals | Master schedule and the close timeline | Business rules: credit limits, reorder points, approval thresholds |
| Architect (designer) | Normalized logical data model: entities, keys, relationships | Use cases and application function specifications | Logical application topology and integration points | Role-based access design | System event model: batch triggers and state changes | Decision tables that encode the business rules |
| Engineer (builder) | Physical database schema, tables and indexes, in the ERP database | Configured transactions and custom extensions (RICEF objects) | Servers, cloud regions, and network configuration | Security profiles and single sign-on configuration | Job-scheduler setup and interface timing | Workflow and approval rules configured inside the ERP |
| Technician (tool detail) | DDL scripts and field-level configuration | Function-module code and integration scripts | Host, IP, and port definitions | Individual user accounts and identity records | Specific job and timer definitions | Validation rules written in code |
| Enterprise (operations) | Live master and transactional data in production | The ERP processing real orders every day | The running infrastructure in service | Employees doing the work inside the system | Actual events: today’s MRP run, tonight’s close | The company pursuing its targets in real time |
Two things fall out of this the moment you try it on a real project. First, most teams never fill every cell, and that is fine. You populate the cells that answer a question someone is actually asking. Second, the grid is a completeness check: the day someone asks “where is our approval logic documented,” you can point at one cell (Why, Engineer row) instead of guessing.
Zachman vs TOGAF: which to use
Zachman and TOGAF are the two names that come up most in enterprise architecture, and they are usually framed as rivals. They are not. They answer different questions, and the strongest teams use both.
| Dimension | Zachman Framework | TOGAF |
|---|---|---|
| Type | Ontology: a classification schema | Methodology: a process (the ADM) |
| Answers | What to document, and whether it is complete | How to develop and govern the architecture |
| Structure | 6×6 matrix of perspectives by interrogatives | Architecture Development Method: eight phases (A to H) plus preliminary |
| Prescribes steps? | No | Yes |
| Output | A populated set of models, one per cell | A delivered, governed architecture and roadmap |
| Certification | ZCEA (Zachman International / FEAC), four levels | TOGAF (The Open Group), Foundation and Practitioner |
| Best fit | Coverage and completeness; regulated, documentation-heavy environments | End-to-end delivery, governance, and roadmapping |
A simple decision rule: choose TOGAF when you need a repeatable process for delivering and governing architecture. Reach for Zachman when your problem is coverage, when you need to be certain that every viewpoint has been captured and nothing is missing. Mature teams run the Zachman grid as the completeness checklist inside TOGAF’s ADM: Zachman guarantees coverage, TOGAF guarantees delivery.
Zachman certification: levels, format, and cost
Certification is run by Zachman International through the FEAC Institute, under the Zachman Certified – Enterprise Architect (ZCEA) program. There are four progressive levels:
- Enterprise Architect Associate (Level 1): the fundamentals of the framework and how to read the grid.
- Enterprise Architect Practitioner (Level 2): applying the framework to real enterprise problems.
- Enterprise Architect Professional (Level 3): awarded on a reviewed case study of your own work.
- Enterprise Architect Educator (Level 4): qualification to teach the framework.
The Level 1 course runs as roughly two weeks of self-study, then a three-day facilitated workshop, and ends with a two-hour online exam. One useful detail: a single Level 1 registration also covers the Level 2 assessment, so you can submit a case study for Practitioner or Professional consideration at no extra cost.
What Zachman certification costs
Unlike The Open Group, which publishes fixed TOGAF exam fees, Zachman International does not post a standing price list; the fee is set per scheduled course. On the FEAC Institute’s 2025 virtual-classroom schedule, ZCEA registration was listed at $2,799 early-bird and $2,999 regular (USD), with the certification fee included in that price. Two discounts are published: current FEAC Certified Enterprise Architects get 50% off (code FEACCEA), and there is separate regional pricing for India. Experienced architects who skip the course and prove competence through the Challenge Path instead pay a non-refundable $299 application fee. Always confirm the current figure on the FEAC schedule, since it changes by session and region.
Benefits: what the grid actually buys you
- Completeness. The grid is a checklist. An empty cell is a visible gap in your documentation, which is far better than a gap you do not know about.
- A shared language. A planner and a database administrator can both point at “the data model” and mean the same cell. That alone removes a surprising amount of cross-team confusion.
- Traceability. You can trace a business goal in the top row down to the configuration and code that deliver it in the lower rows, which is what auditors and change-impact analysis both need.
- Tool independence. Zachman says what to capture, not which tool to capture it in, so it sits on top of UML, BPMN, ERD, or an ERP’s own configuration without conflict.
When the Zachman Framework falls short
The framework has real limits, and being honest about them saves projects from disappointment.
- It classifies; it does not build. There is no method, no sequence, no delivery step. On its own it will not move a project forward, which is exactly why it is paired with TOGAF’s ADM or an Agile process.
- Full population is expensive. Filling all thirty-six cells to real depth is a large documentation effort. John Zachman himself remarked in 2004 that he knew of no organization that had implemented the entire framework. Most teams complete only the cells that earn their keep.
- Adoption is uneven. Use concentrates in government, defense, and large regulated enterprises, where traceability and completeness are requirements rather than nice-to-haves. In fast-moving product teams, awareness is low and the overhead rarely pays off.
Where the Zachman Framework is used
Documented adoption is heaviest in government, defense, and large regulated organizations, the environments where the completeness and audit trail justify the overhead. Public examples include the US Department of Defense, NASA, and aerospace programs; see, for instance, the Aerospace Corporation’s use of the framework in systems engineering. It shows up far less often in fast-cycle commercial software, for the reasons in the section above.
A brief history
John A. Zachman developed the framework at IBM through the 1980s and published it in 1987 as “A Framework for Information Systems Architecture” in the IBM Systems Journal. In its first form it had three columns (what, how, where). In 1992, Zachman and John Sowa extended and formalized it in a follow-up paper, and the remaining three interrogatives (who, when, why) were added to complete the six-column grid. Zachman published a concise official definition in 2008, and the current version, Zachman Framework 3.0, was released around 2011 after consultation with practitioners. The structure has been stable since: the refinements have been to naming and presentation, not to the underlying idea.
FAQs
How much does Zachman certification cost?
Zachman International does not publish a standing price list. On the FEAC Institute’s 2025 virtual-classroom schedule, the Zachman Certified – Enterprise Architect (ZCEA) course was listed at $2,799 early-bird and $2,999 regular in USD, with the certification fee included. Current FEAC Certified Enterprise Architects receive 50% off, separate regional pricing is offered for India, and experienced architects can use the Challenge Path for a $299 application fee. One Level 1 registration also covers the Level 2 assessment at no extra charge.
Is the Zachman Framework still used?
Yes. The current version is Zachman Framework 3.0, released around 2011, and it is still taught and certified through Zachman International and the FEAC Institute. Adoption concentrates in government, defense, and large regulated enterprises, where completeness and traceability matter most. It is less common in fast-moving commercial software teams.
Zachman vs TOGAF: which should I use?
They are complementary, not competitors. Zachman is an ontology that tells you what to document and whether your coverage is complete. TOGAF is a methodology (the ADM) that tells you how to develop and govern the architecture. Use Zachman as a completeness checklist and TOGAF as the delivery process; many mature teams use both together.
What are the rules of the Zachman Framework?
Four rules keep the grid consistent. Alignment: each cell should fit with the cells directly above and below it. Uniformity: within a row, all cells describe the enterprise from one consistent perspective. Uniqueness: each cell serves a distinct purpose and does not repeat another. Completeness: taken together, the cells in a row give a full view of the enterprise from that angle. In short, every piece of information has one place, fits the pieces around it, and adds to a complete picture.
What are the benefits of integrating UML, BPMN, and ERD tools with the Zachman Framework?
Because Zachman is tool-neutral, you can slot specialized notations into the relevant cells. UML models software architecture and system interactions. BPMN visualizes business processes for analysis and improvement. ERD captures data structure for database design and integrity. Each tool fills the cells it is best suited to, while the framework keeps the overall picture consistent.
Conclusion
The Zachman Framework endures because it does one thing no methodology does: it guarantees you have looked at the whole enterprise, from the executive’s scope down to the running system, across all six questions. It will not manage your project or build your architecture. Pair it with a delivery method for that. Used for what it is, a completeness lens rather than a process, it remains one of the clearest ways to be sure nothing about your enterprise has gone undocumented.
References
- John A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal, Vol. 26, No. 3 (1987)
- Zachman International / FEAC Institute – About the Zachman Framework
- Zachman Framework – overview and version history