Zachman Framework

## A classification schema, not a process The Zachman Framework, created by John Zachman in 1987 while at IBM, is best understood as a **classification schema** - an *ontology* - for the artifacts an enterprise produces and uses to describe itself, not a step-by-step process for producing them. Its structure is a matrix built from two independent axes, and understanding why each axis exists, and why they are orthogonal to each other, is the key to using the framework correctly. ## The columns: six interrogatives The horizontal axis (columns) consists of six interrogatives borrowed from classical rhetoric and journalism: What, How, Where, Who, When, and Why. Zachman's insight was that any complex object - a building, an airplane, an enterprise - can be fully described only by answering all six questions, because each captures a different, non-overlapping abstraction. - **What** describes the things/entities involved (data). - **How** describes the processes/functions that transform those things (function). - **Where** describes the geographic or network distribution of the work (location). - **Who** describes the agents/roles responsible for the work (people/organization). - **When** describes the timing, sequencing, and events that trigger activity (time). - **Why** describes the motivation, goals, and rules that justify the design (motivation/strategy). None of these columns can substitute for another - a complete data model tells you nothing about who is authorized to change the data, and a process model tells you nothing about where it physically runs. ## The rows: six perspectives The vertical axis (rows) represents six perspectives, corresponding to the audience or role that would recognize that model as their own. From top to bottom: 1. the **Executive Perspective** (Scope/Contextual) sees the enterprise as a black box bounded by its context; 2. the **Business Management Perspective** (Business Concepts/Conceptual) sees the business's own semantic model, expressed in the language of the business, independent of any IT solution; 3. the **Architect Perspective** (System Logic/Logical) translates business concepts into logical, technology-independent system models; 4. the **Engineer Perspective** (Technology Physics/Physical) constrains those logical models with a specific technology or implementation; 5. the **Technician Perspective** (Component Configuration/As-Built) is the actual configuration and physical detail as built; 6. and the **Enterprise/Functioning** row represents the actual running instance in operation. Moving down a row is not simply 'adding detail' to the row above - it's a transformation performed by a different role, for a different purpose, and it can introduce constraints (e.g., a specific database product) that didn't exist at the row above. ## Why it forces completeness thinking The framework's real power, and the reason it has stayed relevant for nearly four decades, is that it forces completeness thinking: for any artifact you're looking at, you can ask 'which cell does this belong in?' and immediately see what's missing. A team with a beautiful logical data model (`What/Logical`) but no corresponding `Who/Logical` model showing which roles can create, read, update, or delete that data has an incomplete picture, even if nobody previously framed the gap that way. This makes Zachman valuable as an audit or gap-analysis tool: overlay an organization's actual documentation onto the 36 cells, and the empty cells reveal exactly where institutional knowledge is undocumented or exists only in someone's head. ## Where a methodology takes over A critical, easily-missed rule is that the framework does not prescribe how to fill in the cells, in what order, or with what specific notation - that's precisely why it is called an ontology rather than a methodology. Frameworks like TOGAF's Architecture Development Method (ADM) prescribe a process and specific deliverables; Zachman only prescribes the classification scheme those artifacts get sorted into. In practice, many organizations pair Zachman's taxonomy for organizing and auditing artifacts with a process framework like TOGAF for actually producing them: | Framework | The question it settles | |---|---| | **Zachman** | answers 'what have we described, and what haven't we?' | | **TOGAF** | answers 'in what order and by what governance do we produce these things?' | ## The trade-off The trade-off of this axis design is that its completeness is also its biggest practical risk: 36 cells is a lot of surface area, and teams that treat the matrix as a checklist to be literally filled in - rather than a lens for asking 'is this gap actually important, and does it matter for our context?' - end up in analysis paralysis, producing artifacts nobody reads for cells nobody actually needed formalized. The framework itself offers no guidance on prioritization; that judgment call is entirely on the practitioner.