TOGAF with Zachman

The official Zachman framework page is explicit. It describes the Zachman Framework as a schema, then more specifically as an ontology. It also states plainly that the framework is not a methodology. That is not a weakness to apologise for. It is a design choice that defines what the framework does and does not claim to do.

That gives this comparison a firmer footing than many casual summaries do. Zachman is being positioned by its creator as a structured classification and ontology for descriptive representations of an enterprise, not as an end-to-end process for running architecture work.

Schema versus method: the central distinction

A schema tells you what kinds of descriptions are possible and how they relate to one another. A method tells you how to produce those descriptions, who should be involved, what governance applies, and how to move from current state to target state. Both are useful. They solve different problems.

Understanding this distinction is the single most important step in comparing TOGAF and Zachman honestly. Without it, every comparison table will test Zachman against capabilities it never claimed to provide and conclude, incorrectly, that it is inferior.

The Zachman matrix is structured around two dimensions: six interrogative columns and six audience rows. Each cell in the matrix represents a specific type of enterprise description viewed from a specific audience perspective.

The six interrogative columns

• What (data). What things does the enterprise deal with? This covers data entities, business objects, and the information the enterprise needs to manage.
• How (function). How does the enterprise operate? This covers processes, functions, and the transformations the enterprise performs.
• Where (network). Where does the enterprise operate? This covers locations, networks, and the geographic or logical distribution of enterprise elements.
• Who (people). Who is involved? This covers roles, responsibilities, organisational units, and the human actors in the enterprise.
• When (time). When do things happen? This covers events, cycles, schedules, and the timing relationships that govern enterprise behaviour.
• Why (motivation). Why does the enterprise do what it does? This covers goals, strategies, rules, and the motivational factors that drive enterprise decisions.

The six audience rows

• Scope (planner). The executive or planner perspective. What is the enterprise boundary? What is in scope?
• Business model (owner). The business owner perspective. How does the business work? What are the key business concepts?
• System model (designer). The architect or designer perspective. What logical structures support the business model?
• Technology model (builder). The builder perspective. What technology choices implement the logical design?
• Detail representations (implementer). The implementer perspective. What specific configurations, code, and specifications are needed?
• Functioning enterprise (worker). The operational perspective. How does the running enterprise actually behave?

What each cell represents

Each cell in the 6x6 matrix represents a specific type of description. For example, the intersection of "What" and "Business model" asks: what data does the business own, from the business owner's perspective? The intersection of "Where" and "Technology model" asks: where are technology components deployed, from the builder's perspective?

The power of this structure is that it forces completeness questions. If you have described the "What" for every row but never described the "When," you have a gap in your enterprise description. If you have described everything from the planner and owner perspectives but nothing from the builder and implementer perspectives, you have a different kind of gap.

If you compare TOGAF and Zachman as if both are methodologies, the discussion immediately becomes confused. TOGAF offers phases, governance, content guidance,capability logic, and tailoring decisions. Zachman is giving you a structure for thinking about descriptive completeness.

That is why the right mental model is not framework versus framework in a flat list. It is method versus classification lens. The two operate at different conceptual levels and serve different purposes.

What TOGAF provides that Zachman does not

• An architecture development method. The ADM provides phases from Preliminary through Phase H and Requirements Management. Zachman does not define a development process.
• Governance structures. TOGAF defines Architecture Boards, compliance reviews, architecture contracts, and exception handling. Zachman does not address governance.
• Migration planning. Phase E and Phase F provide explicit guidance on gap analysis, work packages, transition states, and roadmap sequencing. Zachman does not address migration.
• Content metamodel. The content metamodel defines the entities, attributes, and relationships that structure the architecture repository. Zachman provides a classification grid but not a metamodel for repository content.
• Stakeholder management. TOGAF provides guidance on stakeholder identification, concern analysis, and viewpoint selection. Zachman's audience rows identify perspectives but do not provide stakeholder management techniques.

What Zachman provides that TOGAF does not

• A completeness framework for enterprise descriptions. The 6x6 matrix provides a systematic way to check whether all relevant types of description have been considered. TOGAF does not provide this kind of structured completeness challenge.
• A classification ontology. Zachman classifies enterprise descriptions by type and audience in a way that is independent of any particular method. This makes it usable as a review lens regardless of which method produced the descriptions.
• Perspective balance. The audience rows force practitioners to consider whether descriptions exist for all relevant perspectives, from executive scope through to operational detail. TOGAF addresses perspectives through viewpoints but does not structure them as a completeness grid.

The most common confusions in TOGAF-Zachman comparisons follow predictable patterns. Understanding these patterns helps practitioners avoid them.

Mistaking a matrix for a method

A classification scheme can help you organise questions and artefacts, but it does not by itself tell you how to scope work, govern change, or sequence transition states. Practitioners who try to "follow Zachman" as if it were a process quickly discover that it does not tell them what to do next. That is because it was never designed to.

Ignoring governance

Even a very complete descriptive structure still needs decision rights, exception handling, and delivery interfaces if architecture is meant to influence change. The Zachman matrix can show you that all six interrogatives have been addressed for all six audience levels. It cannot tell you who decides, who reviews, who approves exceptions, or how architecture connects to delivery governance.

Overstating equivalence

Saying Zachman and TOGAF are simply two alternative EA methods hides the fact that they operate at different conceptual levels. This is the most persistent confusion in the comparison literature. It leads to comparison tables that test both against the same criteria and conclude that one is "missing" capabilities that it never claimed to provide.

Filling cells for completeness rather than value

A subtler confusion arises when teams use the Zachman matrix and interpret every empty cell as an artefact gap that must be filled. The matrix identifies possible descriptions. It does not say that every possible description is necessary for every enterprise problem. Using Zachman well means asking whether a gap matters for real decisions, not automatically creating artefacts to fill every cell.

The most productive relationship between TOGAF and Zachman is complementary: TOGAF runs the architecture work, and Zachman provides a structured lens for reviewing descriptive coverage and perspective balance.

The integration pattern

1. Use TOGAF to run the architecture work. The ADM provides the phases, the content metamodel structures the repository, and the governance framework defines decision rights. This is the operating backbone.
2. Use Zachman as a review lens. At key review points (after Phase B, after Phase C, after Phase D, or during Implementation Governance), use the Zachman matrix to challenge the completeness of the architecture pack. Are all six interrogatives addressed where they matter? Are all relevant audience perspectives covered?
3. Treat any Zachman-based gap as a question, not an order. If the matrix reveals that timing-related descriptions are thin, the right response is to investigate whether that gap affects real decisions. If it does, strengthen the descriptions. If it does not, note the gap and accept it as a proportionate tailoring choice.
4. Return the result to the TOGAF repository. Any artefacts created in response to a Zachman completeness review should be stored in the architecture repository and governed through the same decision process as all other architecture content.
5. Do not duplicate the governance layer. Zachman does not provide governance. Do not create a parallel governance structure to manage Zachman-identified artefacts separately from the TOGAF governance process.

When the Zachman lens is most valuable

• When the architecture pack feels lopsided: rich in some areas and silent in others.
• When different stakeholders are getting inconsistent levels of architectural attention.
• When the enterprise suspects that some interrogative dimensions (particularly "When" and "Why") are under-described relative to "What" and "How."
• When a repository review reveals that artefacts cluster around certain types of description and leave others empty.

While TOGAF and Zachman operate at different conceptual levels, their concepts do map to one another. Understanding these mappings helps practitioners use both without confusion.

Column-to-domain mappings

• What (data) maps to TOGAF's data architecture in Phase C, data domains, and the content metamodel's data entities.
• How (function) maps to TOGAF's business processes and functions in Phase B, and application services in Phase C.
• Where (network) maps to TOGAF's technology architecture in Phase D, including infrastructure, platforms, and deployment topology.
• Who (people) maps to TOGAF's organisation units, roles, and stakeholder analysis in Phase B and the stakeholder management approach.
• When (time) maps partially to TOGAF's transition architectures, roadmap sequencing, event-driven process models, and the change-triggered re-architecture discipline of Phase H (Architecture Change Management). This is the weakest mapping because TOGAF does not have a single "timing architecture" phase, but the mapping is genuinely partial rather than absent: time-of-day sequencing lives in process models, multi-year sequencing lives in the roadmap, and change-triggered iteration lives in Phase H.
• Why (motivation) maps to TOGAF's architecture principles, business scenarios, concerns, and the Architecture Vision in Phase A.

Row-to-perspective mappings

• Scope (planner) maps to TOGAF's Strategic Architecture and the Architecture Landscape at segment and strategic levels.
• Business model (owner) maps to TOGAF's Phase B business architecture, capability models, and value streams.
• System model (designer) maps to TOGAF's logical architecture in Phase C, including Architecture Building Blocks.
• Technology model (builder) maps to TOGAF's Phase D technology architecture and Solution Building Blocks.
• Detail representations (implementer) maps to TOGAF's implementation-level artefacts and the Implementation Governance phase.
• Functioning enterprise (worker) maps to TOGAF's baseline architecture and the operational reality described during Architecture Change Management.

The London repository could use Zachman as a coverage challenge. Are customer, process, data, timing, network, governance, and motivation questions all being described at the right level for the right audiences? That is a legitimate use of the Zachman lens.

Applying the Zachman lens to London

• What. London's data architecture covers asset data, customer data, network data, and regulatory data. The Zachman lens would ask: is this described for all six audience levels?
• How. London's process architecture covers connections delivery, outage management, and data publication. The Zachman lens would ask: are these processes described from the planner perspective down to the operational worker perspective?
• Where. London's network topology covers substations, feeders, and distribution assets. The Zachman lens would ask: is the geographic and logical distribution described at each audience level?
• Who. London's stakeholder map covers Ofgem, NESO, customers, and internal teams. The Zachman lens would ask: are roles and responsibilities clear at every level from executive scope to operational delivery?
• When. This is likely London's weakest dimension. Timing-related descriptions (event sequences, regulatory deadlines, maintenance cycles, seasonal demand patterns) may be under-described relative to the other five interrogatives.
• Why. London's principles and regulatory drivers provide motivation. The Zachman lens would ask: is the "why" traceable from strategic goals through to operational rules?

What London still needs

What London still needs, however, is TOGAF's method for getting from scope and principles through business, information, technology, migration, and governance. The Zachman lens can sharpen the pack. It does not run the pack. The ADM provides the operating backbone. The governance framework provides the decision rights. The content metamodel structures the repository. Zachman provides the completeness challenge that keeps all of those focused.

• For London, Zachman is a completeness aid, not the operating backbone.
• The strongest comparison is ontology and schema versus method and governance.
• The practical integration is to use Zachman at review points to challenge descriptive coverage and then return the results to the TOGAF-governed repository.