Applying the Zachman Framework to Government IT Architecture in Sparx EA

The Zachman Framework is the artifact-classification taxonomy that helps government agencies organize their architecture artifacts 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 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 Technician) 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 demonstrate completeness to OMB or departmental oversight.

---

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:

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 scope-level and strategic, Row 6 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:

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 is exactly what 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, anything — 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?” — checking 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?” — verifying that executive-level alignment is documented, not assumed.
• “Which cells in our grid are empty?” — identifying the perspective / 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 comprehensive, stakeholder-appropriate artifact set. For agencies under OMB EA mandate review or departmental audit, that matrix demonstrates completeness in a format oversight authorities recognize. 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 has mandated enterprise architecture for US federal agencies under multiple policy frameworks: OMB Circular A-130, FEAF, the FITARA legislation, and the Technology Modernization Fund requirements. 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 definitively: “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 — 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 landscape.
• 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, despite being where mission delivery actually happens.

---

Frequently asked questions

---

Add Zachman completeness to your government EA program

Government EA programs that can’t demonstrate artifact completeness by stakeholder perspective are exposed to OMB oversight findings and departmental audit. Zachman provides the completeness taxonomy; Sparx EA generates the population matrix; the work is to tag existing artifacts, surface the gaps, and establish conventions that keep the matrix current. For agencies without a governed repository yet, that starts with assessing the current documentation landscape and designing the Sparx EA governance model before the Zachman layer goes on — the kind of structured starting point our work with architecture leaders is built around.