The Zachman Framework
1. Overview
A. Definition
The Zachman Framework is a two-dimensional classification schema (ontology) that classifies the artifacts making up an enterprise (organization) as the intersections of six questions (columns) — "what, how, where, who, when, why" — and six stakeholder perspectives (rows): "Planner, Owner, Designer, Builder, Implementer, User." In other words, it is a normalized map that prescribes what must be documented; it is not a methodology that prescribes how to build.
The Zachman Framework is often likened to "the periodic table of enterprise architecture (EA)." Just as the periodic table of chemistry does not tell you how to synthesize elements yet prescribes, completely and without overlap, the slot into which every element belongs, the Zachman Framework likewise offers no procedure for producing an organization's architecture artifacts, yet it completely prescribes which artifact belongs in which cell. This is precisely what distinguishes it decisively from methodologies such as TOGAF's ADM, and it is why the two are not competitors but complement each other as classification schema (Zachman) + development process (TOGAF).
There are three core characteristics. First, the 6×6 = 36 cells form a normalized structure that is mutually independent and non-overlapping. Second, each cell is a primitive model dealing with a single variable, so an artifact mixing two or more variables (a composite model) is expressed not as that cell but as a combination of cells. Third, it is neutral with respect to any specific tool, notation, or methodology, so any modeling language (UML, ERD, BPMN, etc.) can fill a cell.
To understand the Zachman Framework correctly, one must be clear that "the framework does not build the architecture for you." The framework merely provides the "empty classification bins" into which architecture artifacts will be placed; what to draw in each bin and how is left to the methodology, notation, and tools the organization chooses. Because of this neutrality, Zachman has stayed alive for more than three decades without being tied to any particular vendor or fad, while at the same time drawing the complaint from practitioners that "so what exactly should we do first?" This two-sidedness is not a flaw but a natural consequence of its true identity as a classification schema.
B. Background and Necessity
The Zachman Framework originated in "A Framework for Information Systems Architecture," published by John A. Zachman in the IBM Systems Journal in 1987. At the time, as large information systems proliferated, there was a serious problem: for one and the same enterprise, the planning department, the business users, the designers, and the developers each described the system in different languages and artifacts, breaking down communication. Zachman sought to port into information systems the way mature engineering disciplines such as architecture and aircraft manufacturing had, over centuries, systematized "describing the same object through drawings from multiple perspectives."
The first driver is the breakdown of communication across perspectives. The "customer" an executive speaks of and the "customer table" a DBA speaks of are at different levels of abstraction, yet when mixed into one document, different people end up imagining different things. By separating the rows (perspectives), the framework forces one to make explicit "which level of abstraction are we talking about right now."
The second driver is controlling omission and duplication of artifacts. When architecture documents reach hundreds of kinds, there is no criterion for judging "what is missing and what overlaps." The fixed coordinate system of 36 cells serves as a checklist, surfacing early, for example, that "the business-model cell of the Why column (motivation/rules) is empty → the risk that business rules were not reflected in the design."
The third driver is traceability and change-impact analysis. When how the requirements of the upper rows (scope, business) descend into the artifacts of the lower rows (technology, implementation) is connected by coordinates, one can trace along columns and rows the data, functions, and systems affected when a particular business rule changes. Korea, too, in the course of introducing the information-technology architecture (ITA/EA) based on the Electronic Government Act, drew widely on Zachman's classification ideas as the basis of its artifact metamodel.
The fourth driver is maturing as an engineering discipline. Zachman held that building information systems still remained in an immature stage dependent on the craftsman's experience, and pointed out that architecture and manufacturing had developed into reproducible and controllable engineering by "systematizing the same object through multiple formal drawings." The framework provides the precondition for that maturity — namely, a standard coordinate system for "what must be described from which perspective." This aim remains valid today: as organizations and systems grow more complex with digital transformation, architecture dependent on tacit knowledge falls out of control, and the need for an explicit classification schema grows rather than shrinks.
2. Structure of the Framework — Two Axes and 36 Cells
The essence of the Zachman Framework lies in "completely decomposing one enterprise along two independent axes." The horizontal axis (columns) represents the kind of abstraction; the vertical axis (rows) represents the degree of concretization (realization). Because the two axes are orthogonal, any architecture artifact is classified by a single coordinate: "which question does it answer (column) × whose perspective is it (row)." This orthogonality is the device that fundamentally prevents duplication and omission.
graph TD
Z["Zachman Framework<br/>(6 x 6 classification matrix)"]
Z --> COL["Horizontal axis: the six questions (kind of abstraction)"]
Z --> ROW["Vertical axis: stakeholder perspectives (degree of concretization)"]
COL --> C1["What: Data"]
COL --> C2["How: Function"]
COL --> C3["Where: Network"]
COL --> C4["Who: Organization/People"]
COL --> C5["When: Time/Schedule"]
COL --> C6["Why: Motivation/Rules"]
ROW --> R1["Scope (Planner/Executive)"]
ROW --> R2["Business Model (Owner/Business)"]
ROW --> R3["System Model (Designer/Architect)"]
ROW --> R4["Technology Model (Builder/Engineer)"]
ROW --> R5["Detailed Representation (Implementer/Technician)"]
ROW --> R6["Functioning Enterprise (User/Enterprise)"]
A. The Six Columns — Six Fundamental Questions
The columns correspond to the six primal questions (the interrogatives) a person asks when explaining any object. What (Data) deals with the things/concepts an organization handles — that is, entities and their relationships. How (Function) deals with the transformation logic of the processes/functions an organization performs. Where (Network) deals with the locations where work is performed and the communication/logistics structure linking them. Who (Organization) deals with the people/roles/responsibilities performing the work and the authority system. When (Time) deals with temporal constraints such as the order, cycle, and schedule of events. Why (Motivation) deals with the reason all of it exists — namely, strategy, goals, and business rules.
An important rule is that there is no inherent order among the columns. There is no reason What must come before How; the six questions are equal axes of decomposition. Moreover, each column has its own simple and unique basic model. For example, the basic model of the What column is an "entity–relationship" structure, while that of the Who column is a "role–responsibility" structure, and the two are not reducible to each other. In practice, people often draw only data (What) and function (How) in detail and leave Who, When, and Why empty; because this signifies design gaps regarding organization, rules, and timing, the framework makes those blanks visible and induces their completion.
Why the six columns constitute a "complete decomposition" follows from the fact that no more fundamental question exists beyond them. If, for instance, one describes the lending business of a bank, What holds entities such as "loan, collateral, customer"; How holds the "loan review, execution, collection" processes; Where holds the processing locations of "head office, branch, review center"; Who holds the authorities of "reviewer, branch manager, credit committee"; When holds the timing of "application → review → approval → execution" and the maturity cycle; and Why holds "BIS-ratio regulation, internal lending-limit rules," respectively. Answer all six and the lending business is described without omission; leave even one blank and the explanation is incomplete by that much. Thus the columns serve as the "MECE (mutually exclusive, collectively exhaustive) axes of explanation."
B. The Six Rows — Six Stakeholder Perspectives
The rows are the perspectives of different stakeholders looking at the same enterprise, and as one goes from top to bottom, they are realized from abstract to concrete. Row 1, Scope (Planner perspective), is the outline at the level of the business scope and key lists seen by executives. Row 2, Business Model (Owner perspective), is the conceptual-level business structure understood by the business users. Row 3, System Model (Designer perspective), is the logical design independent of implementation technology. Row 4, Technology Model (Builder perspective), is the physical design bound to specific products/platforms. Row 5, Detailed Representation (Implementer perspective), is the detailed specification per constituent unit, such as programs and DDL. Row 6, Functioning Enterprise (User perspective), is the actually operating organization/system itself.
The key point is that each row is one independent, complete perspective. The designer perspective (row 3) is not merely a detailing of the owner perspective (row 2) but the result of "transforming" the owner's requirements into the designer's language. Therefore, gather the six cells of a row horizontally and you get the complete model of the organization seen from that perspective; gather the six cells of a column vertically and you get the entire process by which one question (e.g., data) is refined from abstract to concrete. The example below shows how the What (Data) column is realized along the six rows.
Concretely, taking a certain public-service portal down through the six rows looks as follows. At Scope (row 1), the business outline of "online civil-complaint intake and processing" and the list of target complaints are defined; at the Business Model (row 2), the conceptual business flow of "intake → assignment → processing → notification" and the concepts of complaint/handler are drawn. At the System Model (row 3), these are designed as use cases, a logical data model, and service interfaces; at the Technology Model (row 4), they are concretized into a physical structure fitted to specific WAS, DBMS, and API-gateway products. The Detailed Representation (row 5) is the per-unit artifacts such as screens, programs, and DDL; the Functioning Enterprise (row 6) is the actually operating complaint portal itself. This example makes it clear that the same object — "complaint" — is expressed in entirely different languages as it descends the rows.
That a row is "transformation" rather than "detailing" is often overlooked in practice and breeds confusion. If it were detailing, one would only add items to the upper artifact; but if it is transformation, when the perspective changes the responsible party and the language of expression change wholesale. For example, if the owner (row 2) describes the business rule "send a bill to the customer once a month," the designer (row 3) transforms this into a logical composition of "a billing batch job + a billing entity + a send event," and the builder (row 4) transforms it again into a specific batch scheduler and message-queue product. Because information is added and assumptions concretized at each step, there must be a traceability link between the upper and lower rows that verifies "whether the requirement was correctly transformed." When this link breaks, the typical failure occurs in which the rule agreed upon above silently vanishes in the lower implementation.
graph LR
D1["Scope: list of key business data (candidate entities)"] --> D2["Business Model: conceptual data model (subject-area ERD)"]
D2 --> D3["System Model: logical data model (normalized ERD)"]
D3 --> D4["Technology Model: physical data model (DBMS-bound design)"]
D4 --> D5["Detailed Representation: table DDL/index scripts"]
D5 --> D6["Functioning Enterprise: the actual operating database instance"]
3. The Nature of Cells and the Rules of the Framework
A. The Framework's Basic Rules
The rules Zachman proposed guarantee that the framework is not an arbitrary table but a logically closed classification schema. The core rules can be summarized as follows.
- Columns have no order: the six questions are equal, with no precedence or superiority. There is no mandate that a particular column be drawn first.
- Each column has a simple, unique basic model: What is entity–relationship, Who is role–responsibility; each column has an irreducible, proprietary model.
- Each row is one distinct, complete perspective: it is not a detailing of the upper row but the result of transforming the perspective.
- Each cell is unique: the 36 cells do not overlap in meaning, and if two or more conflicting artifacts occupy the same coordinate, it is a governance problem.
- The combination of cells in a row is the complete model of that perspective: the horizontal combination forms the integrated view of that stakeholder.
- No meta-concept is placed in a cell: concepts explaining the framework cannot be the content of a cell (maintaining normalization).
B. Primitive Models and Composite Models
The reason the framework is called an "ontology" rather than a mere 6×6 table is its strict rules.
The practice of interpreting composite artifacts as combinations of cells lets one accurately grasp the nature of practical documents. For example, a data-flow diagram (DFD) decomposes into the combination of data (What) and processing (How); a use-case specification into the combination of function (How), actor (Who), and event order (When); a business-continuity plan into the combination of location (Where), time (When), and motivation (Why). Decomposing in this way reveals "which questions this document answers and which questions it omits," so the framework also serves as a lens for conversely checking the completeness of artifacts.
The distinction between primitive and composite models matters from the reuse perspective too. A primitive model (a single cell) has only one variable, so it can be reused as is in another context, whereas a composite model (a combination of cells) is bound to a particular combination and has lower reusability. Thus the framework implies the design philosophy "accumulate normalized as primitive models where possible, and derive composite artifacts as their combinations." This is isomorphic to the thinking in data normalization that removes duplication to reduce anomalies, and applying the normalization concept to architecture artifacts is Zachman's original contribution. That said, in reality it is hard to keep every artifact as a primitive model, and composite artifacts are often more efficient for communication, so it is realistic to operate with a division of roles: "accumulate normalized, communicate composite."
The practical utility this rule provides is "determining the location of an artifact." When a new document is created, ask "what question does this answer and whose perspective is it," and the coordinate is fixed; if another document already sits at the same coordinate, one may suspect duplication or a version conflict. As in the case where, in a next-generation financial project, both the "core-banking data standard" and the "product data dictionary" were classified as (What, row 3 System Model) and it was discovered that two organizations were operating conflicting logical models, the framework functions as the coordinate system for conflict detection in governance.
| Category | Columns (What ~ Why) | Rows (Scope ~ Functioning Enterprise) |
|---|---|---|
| Meaning | Kind of abstraction (question) | Degree of concretization (realization) |
| Order | No order (equal) | Realized top → bottom |
| Horizontal combination | — | Complete model of one perspective |
| Vertical combination | Refinement process of one question | — |
| Representative artifact examples | Data model, process map, org chart, schedule, rulebook | Vision → conceptual model → logical design → physical design → code → operation |
4. Comparison and Application Cases — Relationship with TOGAF and Government EA
Understanding the Zachman Framework as opposed to TOGAF is a common misconception. The two deal with different questions entirely. Zachman is a classification schema prescribing "what artifacts" must be described to be complete, while TOGAF ADM is a methodology prescribing "in what order (how-to process)" to build them. In actual public-sector and financial EA projects, a hybrid approach is widely used in which the artifact metamodel (kinds of artifacts and coordinates) is defined with Zachman's cell system, and the drafting procedure is run with the stages of TOGAF ADM (vision → business, data, application, technology architecture → opportunity and migration plan).
| Perspective | Zachman Framework | TOGAF | FEA (Federal EA) |
|---|---|---|---|
| Essence | Classification schema (ontology) | Development methodology (ADM) | Reference-model centric |
| Core question | What to document | How to develop | What to measure/share |
| Procedure provided | None (prescribes only "what") | Yes (iterative ADM) | Partial |
| Strength | Completeness, omission checking | Execution procedure, governance | Performance, reference models |
| Limitation | Does not present how to draft | Classification completeness is separate | Complex to apply |
As a numerical application case, in one public institution's EA upgrade, among the 36 cells only those related to data/application were over 70% filled, while the Why (motivation/rules) and When (time) columns were drafted at under 20%. This revealed that "rules and schedules exist only implicitly in the design," and led to an improvement task of separately building a business-rule repository. In another manufacturing case, the Where (Network) column was made explicit on the basis of factory lines and logistics hubs and used as the reference map for OT/IT integration design during the smart-factory transition. Thus the value of the framework lies not in "the completed 36 cells" but in "the diagnostic power to discover the empty cells."
Seeing the comparison not as an enumeration of items but as "the reason the difference arises" makes it clearer. The difference between Zachman and TOGAF ultimately stems from the character difference of classification vs. procedure. Because Zachman is a static coordinate system, it is strong at judging "completeness" but cannot answer "so what to draft first and how." Conversely, because TOGAF ADM provides an iterative procedure, it is strong at execution but does not itself guarantee that the drafted artifacts cover the whole organization without omission. So combining the two yields the complementarity of "run the ADM, but map each stage's artifacts to Zachman cells to check for omissions." ArchiMate adds a notation here, letting cell contents be drawn as consistent diagrams.
Another variable that decides success in practical application is the level of integration with governance. If only the classification coordinates are defined and there is no governance controlling the creation, update, and review of artifacts, the 36 cells become "dead documents" that diverge from reality once filled. What successful cases have in common is that they linked the cell coordinates with configuration management and metadata repositories, so that when a business rule (Why) changes, the affected data (What) and function (How) cells are automatically traced and put through change review. That is, Zachman does not end as a "static classification table"; it yields a return on investment only when it lives on as the index of the change-management process.
5. In Depth — Zachman 3.0 and Reinterpretation in the Digital-Transformation Era
Since its first publication in 1987, the Zachman Framework has had its notation and terminology refined several times. It began with three columns (data, function, network) and three rows, but later the Who, When, and Why columns and the Detailed Representation and Functioning Enterprise rows were added to complete the current 6×6 structure. This expansion process itself reflects the aim of "exhaustively covering the axes of explanation."
Zachman Framework 3.0, released in 2011, refined the terminology to make the columns What (Inventory), How (Process), Where (Distribution), Who (Responsibility), When (Timing), and Why (Motivation), and the rows Executive, Business Management, Architect, Engineer, Technician, and Enterprise Perspective. In particular, it made clear that the bottommost row is not "the implementation" but "the operating enterprise," emphasizing that architecture aims not at documents but at the operating reality.
In the era of digital transformation, cloud, and microservices, there is a criticism that "heavy EA filling in all 36 cells is behind the times," but this confuses the classification schema with the manner of drafting. Even in agile/lean environments, the coordinate system for "what to document" itself remains valid; the point is simply that adaptive use — filling only the needed cells, in a timely and lightweight way — is recommended rather than excessively producing all cells up front. Recently, attempts have also been observed to repurpose Zachman's cell classification as the metadata classification of data governance/data catalogs or as the upper ontology of an enterprise knowledge graph, and to borrow it as a labeling system when generative AI automatically classifies and summarizes organizational documents. That said, since such recent applications are unstandardized attempts, it is appropriate to understand them at the level of "direction" rather than as assertions.
The microservices/cloud-native environment paradoxically highlights the importance of Zachman's Where (Distribution) and When (Timing) columns. In the monolithic era, most processing occurred sequentially in one location, so Where and When were simple; but now, with hundreds of services distributed across multiple regions/availability zones and interacting via asynchronous events, "where it runs and in what order it happens when" has become the core challenge of design. Zachman's column distinction responds naturally to this change, forcing the distributed topology and event timing to be treated as separate explicit design dimensions. In this respect, because the framework's decomposition axes are grounded in the fundamental structure of explanation rather than in a particular technology fashion, they are robust against technological change.
6. Considerations and Implications (from the Professional Engineer's View)
- Application strategy — use it as a completeness-checking tool: If one accepts Zachman as "a duty to fill in all cells," documentation costs explode. The key success factor is to take the 36 cells as a checklist to diagnose the missing perspectives (especially Why, When, Who), and to adaptively operate by filling the higher-priority cells first in line with the organization's maturity.
- Trade-off — completeness vs. agility: The framework's completeness is strong for governance/traceability, but excessive up-front production hampers agile speed. One must keep the classification schema yet take the timing and volume of production in a lean way, and complement the artifact-creation procedure with a methodology such as TOGAF ADM.
- Related technology — combining with methodology and governance: Because Zachman ("what") is not self-complete, it is effective only when combined with TOGAF ADM (procedure), ArchiMate (notation), EA governance (principles/review), and metadata/configuration management (artifact storage/versioning). In particular, linking artifact coordinates with configuration management and data catalogs becomes the basis for automating change-impact analysis.
- Outlook — enduring value as a classification ontology: Development methodologies have changed with fashion, but the classification idea of "decomposing an enterprise into 6×6" is tool-neutral and therefore long-lived. The more the complexity of digital-transformation artifacts grows, the greater the value of a coordinate system prescribing "what to put where," and there is a possibility that its reach will extend to data governance and AI knowledge management.
- Risk — guard against formalism: If EA degenerates into "mass production of documents for reporting," it becomes dead paper divorced from reality. One must periodically verify consistency with the operating reality (row 6) and secure a governance loop that actually uses the architecture in decision-making.
- Organizational capability — placing per-perspective expertise: Because the six rows demand different expertise, the roles responsible for each perspective (business planning, business users, architects, engineers, etc.) must actually be placed within the organization for the framework to work. If a particular perspective's staffing is a gap, the cells of that row are filled only formally, and this must be approached as a problem of organizational design rather than of artifact quality.
References
- John A. Zachman, "A Framework for Information Systems Architecture", IBM Systems Journal, 1987 — https://www.zachman.com/
- Zachman International, "The Zachman Framework" (3.0) — https://www.zachman.com/about-the-zachman-framework
- The Open Group, TOGAF Standard — https://www.opengroup.org/togaf
In one line: The Zachman Framework is a normalized classification schema that decomposes enterprise artifacts into 36 cells — "the six questions (columns) × stakeholder perspectives (rows)" — and, combined with a methodology (TOGAF) that supplies the drafting procedure, serves as EA's coordinate system for diagnosing omission and duplication.