Insight · Frameworks

Applying the Zachman Framework to Government IT Architecture in Sparx EA

By Sparx Services · November 21, 2025

The Zachman Framework is the artifact-classification taxonomy that helps government agencies organize their architecture artifacts consistently across stakeholder perspectives and interrogatives. It is neither a process (TOGAF provides that) nor a notation (ArchiMate provides that). It is the two-dimensional grid that tells you whether your architecture program has produced the right types of artifacts 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 Enterprise) and Column tags (What / How / Where / Who / When / Why) without disrupting the primary TOGAF or FEAF governance model. That enables artifact-coverage auditing (“do we have How / Row 2 artifacts for all our mission-critical processes?”) and the generation of Zachman population matrices that show completeness to OMB or departmental oversight.

An architect in a government program uses this to answer one question for oversight: does the architecture cover the right perspectives for the right audiences? Today the architect classifies artifacts by hand and builds the coverage matrix in a spreadsheet. The AI-augmented way is for the architect to decide the classification rules and what counts as complete, and for AI to tag existing artifacts, generate the matrix and flag the gaps in the repository. The skill is knowing the rows and columns well enough to state the classification rules and to review the tags AI applies.

What Zachman is and is not

The Zachman Framework, developed by John Zachman in 1987 and refined over the decades since, is an ontology for enterprise architecture: a two-dimensional classification system for organizing the artifacts of an architecture program. What it is, and isn’t, matters:

Zachman is an artifact taxonomy. It tells you what types of artifacts a program should produce, classified by the stakeholder perspective (rows) of whoever uses the artifact and the interrogative (columns) it addresses.
Zachman is not a process. It doesn’t tell you how to do architecture work: in what sequence, with what stakeholder engagement, through what governance gates. TOGAF does that; FEAF does it for US federal agencies.
Zachman is not a notation. It doesn’t tell you how to draw diagrams or model elements. ArchiMate, SysML, UML, and BPMN do that.

The most mature programs use all three: Zachman as the artifact taxonomy, TOGAF (or FEAF) as the process, and ArchiMate (or domain-specific notations) as the modeling language. Zachman adds value by making the artifact set explicit and auditable. You know whether you’ve covered all the required stakeholder perspectives, not just whether you’ve completed a given ADM phase.

The six rows: stakeholder perspectives

Zachman’s rows represent the perspectives from which an enterprise is described:

The six rows: stakeholder perspectives
Row	Perspective	Government IT mapping
Row 1	Executive (Scope Context)	CIO, Program Executive Officer, Secretary / Minister
Row 2	Business Management (Business Concepts)	Functional Manager, Program 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 description of the same enterprise. Row 1 is scope-level and strategic, and Row 6 is operational and runtime. A complete program produces artifacts at every row, or consciously chooses which rows to prioritize and documents that decision.

The six columns: interrogatives

The columns represent the fundamental questions architecture artifacts answer:

The six columns: interrogatives
Column	Interrogative	Government IT artifact 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 / Organization	Org structure, role definitions, access-control models
When	Time / Cycle	Program schedules, event-driven process models, sequencing
Why	Motivation / Strategy	Mission statements, goals, policy requirements, strategic objectives

A Zachman cell, the intersection of a row and a column, identifies a specific artifact type. The How / Row 2 cell, for instance, is the business process models that functional managers use to understand how the agency’s mission functions are performed: not the technical implementation, and not the executive overview. That specificity makes Zachman useful for coverage auditing.

Zachman in Sparx EA: the implementation approach

MDG tagged values for Zachman classification

In Sparx EA, Zachman classification is an MDG tagging layer: tagged values added to existing element stereotypes without changing the primary modeling conventions:

zachman_row: Row 1 / Row 2 / Row 3 / Row 4 / Row 5 / Row 6 / Multiple (for artifacts spanning perspectives)
zachman_column: What / How / Where / Who / When / Why / Multiple (for artifacts addressing more than one interrogative)

These tags attach to the stereotypes already in use (ArchiMate Application Component, TOGAF Deliverable, SysML Block, or anything else), sitting alongside the primary governance tags without conflict. A TOGAF Deliverable representing the Application Architecture document receives, for example: togaf_phase = Phase C, zachman_row = Row 3, and zachman_column = What, How (application architecture typically addresses both structure and function).

Using Zachman to audit artifact coverage

Once the tags are applied, coverage queries answer questions that previously required manual review:

“Do we have How / Row 2 artifacts for all mission-critical business processes?” This checks that process documentation exists at the functional-manager perspective, not only at architect or technician level.
“Do we have Why / Row 1 artifacts linking technology investments to strategic objectives?” This verifies that executive-level alignment is documented, not assumed.
“Which cells in our grid are empty?” This identifies the perspective and interrogative combinations with no artifacts, which represent program risk.

These run on Sparx EA’s built-in model search and reporting features, filtered by the Zachman tags. A matrix view can display the population matrix directly: rows on one axis, columns on the other, cells populated by the artifacts carrying the corresponding tags.

Generating the Zachman population matrix

The population matrix, the 6×6 grid showing which cells contain artifacts, is generated straight from the repository using a custom report or a matrix view configured on the Zachman tags. It is the evidence that a program has produced a complete, stakeholder-appropriate artifact set. For agencies under OMB EA mandate review or departmental audit, the matrix shows completeness in a format that is easy to explain to oversight authorities. And because it’s generated dynamically, it reflects the repository’s current state, a live governance tool, not a static compliance document.

Government use case: FEAF and Zachman alignment

The OMB EA mandate

The Office of Management and Budget requires enterprise architecture for US federal agencies under several policies and laws, including OMB Circular A-130, the Clinger-Cohen Act, and FITARA, with FEAF as the common framework. These require agencies to maintain an enterprise architecture and use it to guide technology investment decisions.

FEAF supplies the reference domains (Business, Data, Applications, Infrastructure, Security, Performance) and the investment-alignment methodology. What it doesn’t supply is a completeness check: a way to verify that the artifacts for each domain cover all the stakeholder perspectives oversight would expect. Zachman fills that gap. A FEAF-governed program that adds Zachman tagging to its Sparx EA repository can generate the matrix and answer oversight directly: “We have Row 1 through Row 3 artifacts for the Applications domain covering How and What; we’ve identified a gap in Row 2 Why artifacts for the Business domain, which is our planned Phase B extension.”

Zachman perspectives in a government context

The row-to-stakeholder mapping needs deliberate application for agencies:

Row 1 (Executive Scope): the CIO’s technology strategy and investment portfolio view; the program mission context that justifies IT investment. For federal agencies, this maps to the IT Strategic Plan and Agency Strategic Plan alignment.
Row 2 (Business Management): the functional program-office view of how programs and operations work, what data they need, what systems support them, and where mission-system alignment is documented.
Row 3 (Architect): the EA practitioner’s logical architecture: application diagrams, data flow models, integration architecture; the FEAF Architecture Segments describing the logical estate.
Row 4 (Engineer): the solution architect’s technical specifications: network topology, cloud deployment patterns, security implementation.
Row 5 (Technician): the developer and administrator view: deployment specifics, configuration baselines, operational runbooks. Often underpopulated in programs focused on the upper rows.
Row 6 (Operations): the end-user and field-operator experience: user journey maps, service delivery models, operator procedures. Frequently omitted, even though it is where mission delivery happens.

Frequently asked questions

What is the Zachman Framework, and how is it different from TOGAF?

The Zachman Framework is an artifact taxonomy: a two-dimensional grid that organizes architecture artifacts by stakeholder perspective (rows 1-6) and interrogative (What, How, Where, Who, When, Why). It tells you what types of artifacts a complete program should produce. TOGAF is an architecture process: the Architecture Development Method (ADM), a phased, iterative way of doing the work. The two are complementary: TOGAF tells you how to do architecture; Zachman tells you whether you’ve produced the right artifacts for the right audiences.

Why would a government agency use Zachman if they already have FEAF?

FEAF provides the reference domains and the OMB-mandated investment-alignment methodology, but not a stakeholder-perspective completeness check. An agency can have complete FEAF artifacts for the Applications domain and still have nothing at the Row 2 perspective, meaning the program-office staff who use the systems have no architecture they can engage with. Applying Zachman tagging to an existing FEAF-governed repository lets the agency generate a population matrix showing coverage by perspective.

How do the six interrogatives apply in government IT?

What (data): information assets and data governance supporting mission functions. How (process): workflows and service delivery. Where (location): physical and cloud deployment, and field connectivity. Who (organization): structures, roles, access control. When (time): schedules, event-driven models, reporting cycles. Why (motivation): strategic objectives, mission requirements, investment rationale. The Why column is especially important in government: technology investments must trace to mission requirements to survive OMB review.

How do you add Zachman tagging in Sparx EA without disrupting existing governance?

As an additive MDG layer, two tagged values (zachman_row and zachman_column) on existing element stereotypes, with no change to modeling conventions. ArchiMate elements, TOGAF deliverables, UML components, and any other type can carry Zachman tags alongside their existing governance tags. It requires no diagram changes, package restructuring, or relationship edits, and is applied as a retrospective classification exercise, with new artifacts tagged at creation. AI can propose the tags for existing artifacts, and the architect reviews them.

What does a Zachman population matrix look like, and how is it generated?

A 6×6 grid, six stakeholder perspectives by six interrogatives, where each cell holds the artifacts carrying the matching tags. In Sparx EA it’s generated from a Matrix View filtered by zachman_row and zachman_column, or a custom report. An empty cell is a gap, and a fully populated matrix is a complete program. Agencies typically use it to prioritize the highest-value gaps rather than chasing immediate full population.

Should an agency implement Zachman from scratch or apply it to an existing program?

Almost always, apply it to an existing TOGAF or FEAF program. Building an artifact set from a blank Zachman grid tends to produce artifacts that are well-classified but disconnected from operational reality. Zachman’s value is as a completeness check, not a starting methodology. Tag retrospectively, generate the matrix, identify the gaps, and use the gap analysis to prioritize the next phase, without a program restart.

What this means for the architect

Government EA programs that cannot show artifact completeness by stakeholder perspective are harder to defend in oversight reviews and audits. Zachman provides the completeness taxonomy, Sparx EA generates the population matrix, and the work is to tag existing artifacts, surface the gaps, and set conventions that keep the matrix current. The architect decides the classification rules, and AI does the tagging and the matrix for review. For agencies without a governed repository yet, the start is to assess the current documentation estate and design the governance model before the Zachman layer goes on, the structured starting point our work with architecture leaders is built around.

Prove artifact completeness to your oversight authority.

We can teach your architects to apply Zachman classification with AI on your own repository and mentor them until it sticks, or build the plan and the classification layer for you and hand it over. Most teams want some of both.

Book a call

Keep reading