People often say the Zachman Framework is 'an ontology, not a methodology.' What does that distinction actually mean, and what's the practical consequence for a team adopting it?

## What the word ontology is doing here The word 'ontology' in the context of the Zachman Framework is being used in something close to its philosophical sense: a systematic classification of the kinds of things that exist within a domain, along with the relationships between those kinds. Zachman's ontology asserts that every artifact an enterprise ever produces to describe itself - a data dictionary, an org chart, a network diagram, a business rule catalog, a Gantt chart, a strategy deck - falls into exactly one of 36 categories defined by crossing six interrogatives against six perspectives. What the framework does **not** do is tell you: - in what sequence to produce those artifacts; - who signs off on them; - what tooling to use; - how long each should take; - or what governance body reviews them. That's the job of a **methodology** - a defined, repeatable process with phases, entry/exit criteria, and roles. ## What a methodology adds This distinction matters because the two kinds of frameworks solve different problems and fail in different ways when misapplied. A methodology like TOGAF's Architecture Development Method (ADM) is a cyclical, phase-based process, with each phase producing specific deliverables and requiring specific stakeholder sign-offs before the next phase begins: 1. Preliminary 2. Architecture Vision 3. Business Architecture 4. Information Systems Architectures 5. Technology Architecture 6. Opportunities & Solutions 7. Migration Planning 8. Implementation Governance 9. Architecture Change Management ADM tells a team exactly what to do this week and next week. Zachman tells you nothing about weeks; it only tells you, once you have an artifact in hand, which cell it belongs in and, by implication, what else in that row or column might be missing or inconsistent. ## What goes wrong with the ontology alone The practical consequence shows up immediately when a team tries to 'adopt Zachman' as if it were a project plan. Without a companion process, a team handed the 6x6 matrix has no answer to 'what do we do Monday morning' - there's no phase 1, no kickoff deliverable, no defined exit criteria for being 'done' with a cell. Organizations that try to run architecture practice on Zachman alone typically drift into one of two failure modes: - **They never start**, because the matrix looks like 36 undifferentiated obligations with no priority order. - **They start producing artifacts opportunistically**, with no governance, and end up with loosely-related documents that were never validated against each other for consistency (a `Who/Logical` role model that silently disagrees with the `How/Logical` process model, for instance). ## The mature pattern: use both The mature pattern is to use Zachman and a methodology together, each doing the job it's suited for. | Layer | Its contribution | |---|---| | **TOGAF's ADM** (or an internal equivalent) | supplies the process: what phase we're in, what deliverable is due, who has to approve it, how change requests move through governance | | **Zachman** | supplies the completeness check and classification discipline: for the deliverables the process calls for, which Zachman cell does each one satisfy, and does that leave any cell conspicuously and importantly empty for this initiative? | Zachman is also frequently used standalone, detached from any formal methodology, purely as an audit or gap-analysis tool - an architect walks a legacy system's existing documentation, tags each document by cell, and the empty cells become the backlog for a documentation or discovery effort. In that mode, Zachman is doing exactly what an ontology is good at: making the invisible-because-undocumented visible by giving it a labeled, expected slot. ## The ordering trap A common failure mode worth naming explicitly is treating Zachman's neutrality about sequence as an invitation to fill cells in an arbitrary or convenient order, then discovering inconsistencies late. Zachman's own guidance (echoed by most serious practitioners) is that cells within the same row should be produced together or at least reconciled against each other, because they describe the same system from the same stakeholder's vantage point - a Business Concepts row's data model, process model, and org model should describe a mutually consistent picture of 'the business as the business owner understands it,' even though the framework provides no enforcement mechanism for that consistency; it relies entirely on the practitioner's discipline. ## Why the classification outlives the process Finally, it's worth noting that because Zachman is 'just' a classification scheme, it is comparatively durable: while methodologies like ADM have gone through multiple major version revisions since TOGAF's introduction, the core 6x6 Zachman matrix has been stable, with only minor terminology refinements, since roughly the mid-1990s. A classification scheme changes less often than a process, because the underlying questions (what, how, where, who, when, why) and stakeholder perspectives (executive down to as-built) are far more stable than any given organization's preferred delivery process.