Direct Answer
The Zachman Framework provides the artefact classification taxonomy that helps government agencies organise their architecture artefacts consistently across stakeholder perspectives and interrogatives. It is not a process (TOGAF provides that) and not a notation (ArchiMate provides that) — it is the two-dimensional classification grid that tells you whether your architecture programme has produced the right types of artefacts for the right stakeholder audiences. In Sparx EA, Zachman is implemented as an MDG tagging layer: existing elements receive Zachman Row tags (Row 1 Executive through Row 6 Technician) and Zachman Column tags (What / How / Where / Who / When / Why) without disrupting the primary TOGAF or FEAF governance model. This enables artefact coverage auditing — querying the repository to ask “do we have How-Row 2 artefacts for all our mission-critical processes?” — and generating Zachman population matrices that demonstrate completeness to OMB or departmental oversight authorities. For US federal agencies with OMB EA mandates, Zachman tagging provides the meta-level classification evidence that FEAF artefacts are comprehensive and stakeholder-appropriate.
The Zachman Framework Explained
What Zachman Is and Is Not
The Zachman Framework — developed by John Zachman in 1987 and refined through subsequent decades — is an ontology for enterprise architecture: a two-dimensional classification system that provides a way of organising the artefacts of an enterprise architecture programme. It is important to understand what Zachman is and is not:
Zachman is: an artefact taxonomy. It tells you what types of artefacts an architecture programme should produce, classified by the stakeholder perspective (rows) of the person who will use the artefact and the interrogative (columns) the artefact addresses.
Zachman is not: a process. It does not tell you how to do architecture work — in what sequence, with what stakeholder engagement, using what governance gates. TOGAF provides that. FEAF provides that for US federal agencies.
Zachman is not: a notation. It does not tell you how to draw diagrams or model elements. ArchiMate, SysML, UML, and BPMN provide that.
The most mature EA programmes use all three in combination: Zachman as the artefact taxonomy, TOGAF (or FEAF) as the process, and ArchiMate (or domain-specific notations) as the modelling language. Zachman adds value by making the artefact set explicit and auditable — you know whether you have covered all the required stakeholder perspectives, not just whether you have completed a given ADM phase.
The Six Rows: Stakeholder Perspectives
Zachman’s six rows represent the stakeholder perspectives from which an enterprise is described:
| Row | Perspective | Government IT Mapping |
|---|---|---|
| Row 1 | Executive (Scope Context) | CIO, Programme Executive Officer, Secretary/Minister |
| Row 2 | Business Management (Business Concepts) | Functional Manager, Programme Director, Mission Owner |
| Row 3 | Architect (System Logic) | EA Practitioner, Solution Architect Lead |
| Row 4 | Engineer (Technology Physics) | Solution Architect, Technical Architect |
| Row 5 | Technician (Tool Components) | Developer, System Administrator, Database Administrator |
| Row 6 | Enterprise (Operations) | End User, Field Operator, Mission Delivery Staff |
Each row produces a different type of description of the same enterprise. Row 1 descriptions are scope-level, contextual, and strategic. Row 6 descriptions are operational, specific, and runtime. A complete architecture programme produces artefacts at every row — or consciously chooses which rows to prioritise and documents that decision.
The Six Columns: Interrogatives
The six columns represent the interrogatives — the fundamental questions that architecture artefacts address:
| Column | Interrogative | Government IT Artefact Examples |
|---|---|---|
| What | Data / Information | Data asset inventory, data model, information architecture |
| How | Function / Process | Business process models, service blueprints, system functions |
| Where | Network / Location | Facility inventory, cloud deployment topology, network architecture |
| Who | People / Organisation | Org structure, role definitions, access control models |
| When | Time / Cycle | Programme schedules, event-driven process models, sequencing |
| Why | Motivation / Strategy | Mission statements, goals, policy requirements, strategic objectives |
The Zachman cell — the intersection of a row and a column — identifies a specific type of artefact. The How-Row 2 cell, for example, represents the business process models that functional managers (Row 2) use to understand how the agency’s mission functions are performed — not the technical implementation of those processes, and not the executive-level process overview. The specificity of the cell definition is what makes Zachman useful for artefact coverage auditing.
Zachman in Sparx EA: Implementation Approach
MDG Tagged Values for Zachman Classification
In Sparx EA, Zachman classification is implemented as an MDG tagging layer — tagged values added to existing element stereotypes without changing the primary modelling conventions:
zachman_row tagged value: Row 1 / Row 2 / Row 3 / Row 4 / Row 5 / Row 6 / Multiple (for artefacts that span stakeholder perspectives)
zachman_column tagged value: What / How / Where / Who / When / Why / Multiple (for artefacts that address more than one interrogative)
These tagged values are added to the stereotypes already in use — ArchiMate Application Component, TOGAF Deliverable, SysML Block, or any other element type. The Zachman tags sit alongside the primary governance tags without conflicting with the primary modelling structure. A TOGAF Deliverable element that represents the Application Architecture document receives tagged values: togafphase = Phase C, zachmanrow = Row 3, zachmancolumn = What and zachmancolumn = How (application architecture artefacts typically address both structure and function).
Using Zachman to Audit Artefact Coverage
Once Zachman tagged values are applied to repository elements, coverage queries can be run that answer questions previously answerable only by manual review:
- “Do we have How-Row 2 artefacts for all our mission-critical business processes?” — checking whether the business process documentation exists at the functional manager perspective, not just at architect or technician level
- “Do we have Why-Row 1 artefacts that link our technology investments to strategic objectives?” — verifying that the executive-level strategic alignment is documented, not just assumed
- “Which cells in our Zachman grid are empty — which stakeholder perspective / interrogative combinations do we have no artefacts for?” — identifying gaps that represent architecture programme risk
In Sparx EA, these queries are executed using the built-in model search and reporting features, filtered by Zachman tagged values. A Sparx EA matrix view can be configured to display the Zachman population matrix — rows on one axis, columns on the other, with cells populated by the artefact elements that carry the corresponding tags.
Generating the Zachman Population Matrix
The Zachman population matrix — the 6×6 grid showing which cells contain artefacts — is generated directly from the Sparx EA repository using a custom report or a matrix view configured on Zachman tagged values. This matrix is the evidence that an architecture programme has produced a comprehensive and stakeholder-appropriate artefact set. For government agencies subject to OMB EA mandate review or departmental audit, the Zachman population matrix demonstrates artefact completeness in a format that oversight authorities recognise.
The matrix is generated dynamically — it reflects the current state of the repository at the time it is generated. As new artefacts are added to the repository and tagged with Zachman values, the matrix updates. This makes the Zachman population matrix a live governance tool rather than a static compliance artefact.
Government Use Case: FEAF and Zachman Alignment
OMB EA Mandate
The Office of Management and Budget (OMB) has mandated Enterprise Architecture for US federal agencies under multiple policy frameworks: OMB Circular A-130, the Federal Enterprise Architecture Framework (FEAF), the FITARA legislation (Federal Information Technology Acquisition Reform Act), and the more recent Technology Modernization Fund requirements. These mandates require agencies to maintain an enterprise architecture and use it to guide technology investment decisions.
FEAF provides the reference architecture domains (Business, Data, Applications, Infrastructure, Security, Performance) and the investment alignment methodology. What FEAF does not provide is a completeness check: a way of verifying that the artefacts produced for each domain cover all the stakeholder perspectives that OMB or departmental oversight would expect.
Zachman fills this gap. A FEAF-governed architecture programme that adds Zachman tagging to its Sparx EA repository can generate a Zachman population matrix and answer oversight questions definitively: “We have Row 1 through Row 3 artefacts for the Applications domain covering How and What interrogatives; we have identified a gap in Row 2 Why artefacts for the Business domain, which represents our planned Phase B extension.”
Zachman Perspectives Applied to Government IT Context
The Zachman row-to-government-stakeholder mapping needs to be applied deliberately for government agencies:
Row 1 (Executive Scope): The CIO’s technology strategy and investment portfolio view. The programme mission context that justifies IT investments. For federal agencies, this maps to the IT Strategic Plan and the Agency Strategic Plan alignment.
Row 2 (Business Management): The functional programme office view — how programmes and operations actually work, what data they need, what systems support them. For government, this is where mission-system alignment is documented: the Agency Programme Architecture that shows what IT systems support each mission function.
Row 3 (Architect): The EA practitioner’s logical architecture: application diagrams, data flow models, integration architecture. The FEAF Architecture Segments that describe the logical system landscape.
Row 4 (Engineer): The solution architect’s technical specifications: network topology, cloud deployment patterns, security architecture implementation. The engineering artefacts that bound implementation choices.
Row 5 (Technician): The developer and administrator view: code deployment specifics, configuration baselines, operational runbooks. Often underpopulated in government EA programmes that focus on upper rows.
Row 6 (Operations): The end-user and field operator experience. User journey maps, service delivery models, operator procedures. Frequently omitted from government EA programmes despite being the domain where mission delivery happens.
FAQ
What is the Zachman Framework and how is it different from TOGAF?
The Zachman Framework is an artefact taxonomy — a two-dimensional classification grid that organises architecture artefacts by stakeholder perspective (rows 1–6) and by interrogative (What, How, Where, Who, When, Why). It tells you what types of artefacts a complete architecture programme should produce. TOGAF (The Open Group Architecture Framework) is an architecture process — specifically the Architecture Development Method (ADM), which provides a phased, iterative process for doing architecture work. The two are complementary: TOGAF tells you how to do architecture; Zachman tells you whether you have produced the right types of artefacts for the right stakeholder audiences. Most serious EA programmes use TOGAF as the primary process and Zachman as a completeness check. Neither replaces the other.
Why would a government agency choose to use Zachman if they already have FEAF?
FEAF (Federal Enterprise Architecture Framework) provides the reference architecture domains — Business, Data, Applications, Infrastructure, Security, Performance — and the investment alignment methodology that OMB mandates. What FEAF does not provide is a stakeholder perspective completeness check. An agency can have comprehensive FEAF artefacts for the Applications domain and still have no artefacts at the Row 2 (functional manager) perspective — meaning the programme office staff who actually use the systems have no architecture documentation they can engage with. Zachman fills this gap. Applying Zachman tagging to an existing FEAF-governed Sparx EA repository enables the agency to generate a population matrix showing artefact coverage by stakeholder perspective — providing the completeness evidence that OMB oversight and departmental auditors look for.
How do the six interrogatives apply in a government IT context?
The six Zachman interrogatives address the fundamental questions that government IT architecture must answer: What (data) — the information assets, data models, and data governance structures that support mission functions. How (process) — the business processes, workflows, and service delivery mechanisms that government programmes use. Where (location) — the physical and cloud deployment topology, data centre locations, field office connectivity. Who (organisation) — organisational structures, roles, access control models, and the human elements of the system. When (time) — programme schedules, event-driven process models, regulatory reporting cycles, and sequencing of technology changes. Why (motivation) — the strategic objectives, mission requirements, policy mandates, and investment rationale that justify IT decisions. In a government context, the Why column is particularly important: technology investments must be traceable to mission requirements to survive OMB review.
How do you implement Zachman tagging in Sparx EA without disrupting existing governance?
Zachman tagging in Sparx EA is implemented as an additive MDG layer — two tagged values (zachmanrow and zachmancolumn) added to existing element stereotypes without changing the primary modelling conventions. ArchiMate elements, TOGAF deliverables, UML components, and any other element type can receive Zachman tags alongside their existing governance tags. The tagging does not require changing diagram layouts, restructuring packages, or modifying existing relationships. It is applied as a retrospective classification exercise: EA practitioners review existing artefacts and assign the appropriate row and column tags. New artefacts receive Zachman tags at creation. The investment in tagging is proportionate to the coverage completeness the agency needs to demonstrate.
What does a Zachman population matrix look like and how is it generated from Sparx EA?
A Zachman population matrix is a 6×6 grid — six rows (stakeholder perspectives) by six columns (interrogatives) — where each cell is populated with the artefacts that carry the corresponding Zachman tags. In Sparx EA, the matrix is generated using a Matrix View configured to filter elements by zachmanrow and zachmancolumn tagged values, or using a custom report that queries the repository for elements with specific tag combinations. An empty cell represents a gap — a stakeholder perspective and interrogative combination for which the architecture programme has produced no artefacts. A fully populated matrix represents a comprehensive architecture programme. Agencies typically use the matrix to identify the highest-priority gaps and plan the artefacts needed to address them, rather than aiming for immediate full population.
How does Zachman support the OMB EA mandate for federal agencies?
The OMB EA mandate requires federal agencies to maintain enterprise architecture and use it to guide technology investment decisions. Oversight questions typically include: Is your architecture comprehensive? Does it cover all domains? Does it support investment decisions? Does it address all stakeholder perspectives? A Zachman-tagged Sparx EA repository provides defensible answers to these questions: the population matrix shows artefact coverage by stakeholder perspective and interrogative, the FEAF domain alignment shows domain coverage, and the investment traceability (Why column artefacts linking investments to mission requirements) shows decision support capability. Agencies that have Zachman-tagged repositories can answer OMB questions in hours from the repository rather than assembling documentation over days.
Should a government agency implement Zachman from scratch or apply it to an existing TOGAF programme?
Almost always, apply Zachman to an existing TOGAF programme. Starting a fresh Zachman implementation from scratch — building the artefact set from a blank Zachman grid — produces artefacts that are comprehensive in classification but often disconnected from operational reality. The value of Zachman is as a completeness check on an existing architecture programme, not as a starting methodology. A government agency with an existing FEAF or TOGAF-governed Sparx EA repository should apply Zachman tagging retrospectively to existing artefacts, generate the population matrix, identify the gaps, and use the gap analysis to prioritise the next phase of architecture work. This approach delivers the oversight value of Zachman within weeks, without requiring a programme restart.
What is the recommended Sparx Services engagement for government agencies adopting Zachman?
The recommended engagement is Amplify — the governance enhancement practice that adds Zachman tagging to an existing Sparx EA repository, generates the initial population matrix, identifies artefact coverage gaps, and establishes the tagging conventions that allow the matrix to be maintained going forward. Amplify is typically a 6–10 week engagement for a medium-sized government agency, priced in the $45K–$100K range depending on repository size and the number of existing artefacts requiring Zachman classification. For agencies that do not yet have a governed Sparx EA repository, a Discover engagement first assesses the current architecture documentation landscape and designs the Sparx EA governance model before Amplify applies the Zachman layer. Contact Sparx Services for a scoped estimate.
Next Step: Add Zachman Completeness to Your Government EA Programme
Government EA programmes that cannot demonstrate artefact completeness by stakeholder perspective are vulnerable to OMB oversight findings and departmental audit. Zachman provides the completeness taxonomy; Sparx EA generates the population matrix; Amplify delivers both in a practical timeframe.
An Amplify engagement from Sparx Services adds Zachman tagging to your existing Sparx EA repository and delivers the population matrix your oversight authority needs.
Talk to Sparx Services about an Amplify engagement for government EA
Amplify engagements start at $45K. Deliver the Zachman population matrix in weeks, not quarters.
