Skip to content

Zachman Framework vs EA on a Page — Two Lenses on the Same Artifacts

The Zachman Framework (1987) and EA on a Page (2017) are both artifact classification frameworks. Neither is a methodology: Zachman deliberately prescribes nothing beyond the classification itself, and EA on a Page describes the three processes it has observed empirically rather than prescribing them. They classify from different angles — and together they provide a richer picture than either alone.

This article maps the two frameworks against each other, shows where they align and diverge, and demonstrates how to use both in Linked.Archi.

See also: Zachman Primer & Modeling Guide for a standalone introduction to the Zachman Framework and its Linked.Archi semantic model.

See also: EA on a Page Primer & Modeling Guide for a standalone introduction to EA on a Page and its Linked.Archi semantic model.

The Core Difference

Zachman classifies descriptive representations by two dimensions: - Communication Interrogative (column): What question does the description answer? — What, How, Where, Who, When, Why - Reification Transformation / Perspective (row): At what level of transformation is the description expressed? — Identification, Definition, Representation, Specification, Configuration, Instantiation — commonly associated with Planner, Owner, Designer, Builder, Implementer, and Enterprise perspectives.

This produces a 6×6 grid of 36 cells. Each Zachman cell identifies a classification slot for an architecture artifact or view, defined by the intersection of a communication interrogative and a reification level, commonly associated with a stakeholder perspective. Architecture deliverables may combine multiple artifacts, views, or cells.

EA on a Page classifies artifacts by two different dimensions: - Type (CSVLOD): How is the artifact used? — Considerations, Standards, Visions, Landscapes, Outlines, Designs - Usage frequency: How commonly is it used? — Essential, Common, Uncommon

And two additional classification axes: - Nature: What does the artifact describe? — Rules (Considerations, Standards), Structures (Visions, Landscapes), Changes (Outlines, Designs) - Focus: Who is the primary audience? — Business-focused (Considerations, Visions, Outlines), IT-focused (Standards, Landscapes, Designs)

This produces 6 types with 24 specific artifacts, validated empirically across 27+ organizations.

The key insight: Zachman is theoretical and complete (36 cells, whether or not anyone fills them). EA on a Page is empirical and practical (24 artifacts that organizations actually produce). Zachman describes the logical space of what could be described. EA on a Page describes the artifacts commonly produced in EA practice.

The Mapping

CSVLOD Types → Zachman Rows

Column names below use the interrogatives with their classic IT-centric aliases (Data, Function, Network, People, Time, Motivation) for familiarity; the formal Linked.Archi names are Inventory, Process, Distribution, Responsibility, Timing, and Motivation — see the Zachman primer for the mapping.

EA on a Page's six types map roughly to Zachman's reification/perspective rows, but not one-to-one — they cut across perspectives:

CSVLOD Type Primary Zachman Rows Rationale
Considerations Row 1 (Planner) Principles and policies are set at the executive/planner level
Standards Row 3 (Designer) + Row 4 (Builder) Technology standards bridge the architect and engineer perspectives
Visions Row 1 (Planner) + Row 2 (Owner) Future-state artifacts serve both executives and business owners
Landscapes Row 3 (Designer) + Row 4 (Builder) Current-state inventories serve architects and engineers
Outlines Row 3 (Designer) Solution overviews are the architect's primary deliverable
Designs Row 4 (Builder) + Row 5 (Implementer) Detailed designs serve engineers and implementers

Notice that Zachman's Row 6 (Worker/User) and Row 2 (Owner) are underrepresented in EA on a Page. This is not a gap — it reflects Kotusev's empirical finding that EA practices primarily produce artifacts for rows 1, 3, and 4. Business owners consume Visions, and end users consume the running system — neither group typically receives dedicated EA artifacts.

CSVLOD Types → Zachman Columns

Each CSVLOD type spans multiple Zachman interrogatives:

CSVLOD Type Zachman Columns Covered
Considerations Why (Motivation) — principles express intent and rationale
Standards How (Function) + What (Data) — technology standards define approved approaches and data formats
Visions What (Data) + How (Function) + When (Time) + Why (Motivation) — capability models, target architectures, roadmaps, and strategy
Landscapes What (Data) + How (Function) + Where (Network) — inventories, application maps, integration diagrams
Outlines What + How + Where + Who — solution overviews cover data, function, deployment, and organization
Designs All six — detailed designs address every interrogative for a specific solution

The 24 Artifacts Placed in the Zachman Grid

Note: The mapping below is a Linked.Archi interpretation, not an official Zachman or Kotusev mapping. EA on a Page artifacts are not defined in Zachman terms, and many artifacts can legitimately span multiple Zachman cells depending on scope, audience, and level of abstraction.

Here's where each of EA on a Page's 24 artifacts falls in the Zachman matrix:

EA on a Page Artifact Zachman Row Zachman Column(s) Usage
Considerations
Principles Planner Why Essential
Policies Planner Why + How Common
Conceptual Architectures Planner + Owner How + What Common
Guidelines Designer How Uncommon
Standards
Technology Reference Models Designer How + What Essential
Patterns Designer How Common
IT Principles Designer + Builder How + Why Common
Technology Guidelines Builder How Uncommon
Visions
Business Capability Models Owner What + Why Essential
Target State Architectures Designer How + What + Where Essential
Roadmaps Planner When Essential
Value Chains Owner How + Why Common
Landscapes
Landscape Diagrams Designer How + Where Essential
Inventories Builder What Essential
Enterprise System Portfolios Designer + Builder What + How Common
Integration Maps Designer Where + How Common
Outlines
Solution Overviews Designer How + What + Where Essential
Options Assessments Designer How + Why Essential
Initiative Architectures Designer How + What + Where + Who Common
Architecture Briefs Designer How + Why Uncommon
Designs
Solution Designs Builder How + What + Where Essential
Detailed Specifications Builder + Implementer How + What Common
Interface Contracts Builder How + Where Common
Deployment Architectures Builder Where Uncommon

What This Reveals

  1. Zachman's "Designer" row is the busiest. 14 of 24 EA on a Page artifacts involve the Architect/Designer perspective. This confirms what practitioners know — architects are the primary producers and consumers of EA artifacts.

  2. Zachman's "How" column dominates. Almost every artifact addresses "How" (Function). This makes sense — architecture is fundamentally about structure and behavior.

  3. Zachman's outer rows are sparse. The Planner (Row 1) gets Considerations and Visions. The Implementer (Row 5) gets Designs. The Worker (Row 6) gets nothing — they use the running system, not EA artifacts. This matches Kotusev's empirical findings.

  4. EA on a Page's "Essential" artifacts cluster in the center. The most commonly used artifacts (Principles, Technology Reference Models, Capability Models, Target Architectures, Roadmaps, Landscape Diagrams, Inventories, Solution Overviews, Options Assessments, Solution Designs) all fall in Zachman rows 1-4 and columns What/How/Where/Why. The periphery (Who, When, rows 5-6) is less populated.

Where They Diverge

Zachman Has No Artifact Lifecycle Dimension

Zachman has a Timing column (When), but it does not model artifact lifecycle, creation sequence, governance cadence, or EA practice process. The grid classifies artifacts by content and audience but says nothing about when they're created, how long they live, or how they're used. EA on a Page adds:

  • Lifecycle: permanent (Considerations, Standards) vs long-lived (Visions, Landscapes) vs short-lived (Outlines, Designs)
  • Scope: organization-wide vs initiative-scoped vs project-scoped
  • Process: which EA process uses the artifact (Strategic Planning, Initiative Delivery, Technology Optimization)

EA on a Page Has a Coarse Audience Distinction

EA on a Page has a coarse business/IT focus distinction, but it does not have Zachman's explicit six-row audience/reification axis. It classifies by usage, not by audience. It doesn't distinguish between an artifact created for the CIO and one created for a developer — it only cares about the artifact's role in the EA practice. Zachman's perspective rows fill this gap.

Zachman Is Complete but Theoretical

Zachman's 36 cells are exhaustive by construction — every combination of interrogative and reification transformation is a valid cell, representing a primitive descriptive representation. But many cells are rarely populated in practice. Kotusev's research (2021) found that organizations typically produce only a subset of the 24 artifact types — commonly in the 8–15 range — concentrated in the center of the grid. Real-world architecture artifacts are often composite — a single document may combine descriptions from several cells.

EA on a Page Is Practical but Incomplete

EA on a Page captures what organizations actually do, but it may miss artifacts that are valuable but uncommon. Zachman's grid can reveal these gaps — "we have no artifacts in the Who × Designer cell" might prompt creating an organization model.

Zachman Cells Are Not Viewpoints or Deliverables

A Zachman cell is not itself a full ISO 42010 architecture viewpoint, nor is it a deliverable. Understanding these distinctions is important for correct usage in Linked.Archi.

Cell ≠ Viewpoint. A viewpoint defines conventions for constructing and interpreting views: stakeholders, concerns, model kinds, notations, and correspondence rules. ISO 42010:2022 explicitly specifies requirements for architecture viewpoints and model kinds that go well beyond classification. A Zachman cell may correspond to a viewpoint family, but only becomes a proper ISO 42010 viewpoint if stakeholders, concerns, model kinds, notations, and construction rules are defined.

Cell ≠ Deliverable. A Zachman cell classifies a type of primitive descriptive representation — an artifact, view, or view component. Architecture deliverables (such as an Architecture Definition Document, Architecture Requirements Specification, roadmap, or governance package) are compositions that aggregate multiple artifacts/views. A deliverable therefore typically covers many Zachman cells.

The relationship hierarchy:

Architecture Deliverable
  └── contains Architecture Artifacts / Views
        ├── governed by Viewpoints
        └── classified by Zachman cell(s)

In Linked.Archi terms, a Zachman cell can be interpreted in three ways:

Zachman concept Linked.Archi / ISO 42010 interpretation
Cell as classification slot A lightweight tag on an artifact, view, or view component — no notation or model kind prescribed
Cell as viewpoint candidate A reusable viewpoint family, if Linked.Archi defines concerns, stakeholders, model kinds, and conventions for it
Cell as viewpoint A complete ISO 42010 viewpoint — only if additional viewpoint semantics (concerns, model kinds, correspondence rules) are explicitly defined

The Linked.Archi position: Zachman cells are classification slots for architecture artifacts, views, or view components — not deliverables. Each cell is defined by the intersection of a communication interrogative and a reification transformation, commonly associated with a stakeholder perspective. Architecture deliverables typically aggregate multiple artifacts/views and therefore may cover many Zachman cells. This is why the Linked.Archi Zachman metamodel does not declare arch:architectureViewpoints — it provides classification, not viewpoint definitions.

Classification at artifact level vs deliverable level

Classify individual views by their Zachman cell:

@prefix zach: <https://meta.linked.archi/zachman/onto#> .
@prefix zachtax: <https://meta.linked.archi/zachman/tax#> .
@prefix arch: <https://meta.linked.archi/core#> .

# An individual view classified by Zachman cell
ex:SomeProcessFlowView
    a arch:Diagram ;
    skos:prefLabel "Order Processing Flow"@en ;
    arch:viewConformsToViewpoint ex:BusinessProcessViewpoint ;
    zach:classifiedByCell zachtax:R2C2_ProcessDefinition .

A deliverable (Model) aggregates views — its cell coverage is derived:

# A deliverable that contains multiple views
ex:ArchitectureDefinitionDocument
    a arch:Model ;
    skos:prefLabel "Architecture Definition Document"@en ;
    arch:contains ex:SomeProcessFlowView ;
    arch:contains ex:InformationModelView ;
    arch:contains ex:CapabilityMapView .

# Derived/summary coverage (optional — for portfolio queries)
ex:ArchitectureDefinitionDocument
    zach:classifiedByCell zachtax:R2C2_ProcessDefinition ;
    zach:classifiedByCell zachtax:R2C1_InventoryDefinition ;
    zach:classifiedByCell zachtax:R2C4_ResponsibilityDefinition .

Using Both in Linked.Archi

Dual Classification

Every architecture artifact in Linked.Archi can carry both classifications:

@prefix eaop:    <https://meta.linked.archi/eaonapage/onto#> .
@prefix eaoptax: <https://meta.linked.archi/eaonapage/tax#> .
@prefix zach:    <https://meta.linked.archi/zachman/onto#> .
@prefix zachtax: <https://meta.linked.archi/zachman/tax#> .
@prefix arch:    <https://meta.linked.archi/core#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:      <https://model.example.com/myea#> .

# A technology reference model — classified by both frameworks
ex:TechRefModel a eaop:Standard ;
    skos:prefLabel "Enterprise Technology Reference Model"@en ;
    # EA on a Page classification
    eaop:classifiedByType eaoptax:TechnologyReferenceModel ;
    eaop:usedInProcess eaop:TechnologyOptimization ;
    # Zachman classification (cell-level)
    zach:classifiedByCell zachtax:R3C2_ProcessRepresentation ,
                          zachtax:R3C1_InventoryRepresentation .

# A business capability model
ex:CapabilityMap a eaop:Vision ;
    skos:prefLabel "Enterprise Capability Map"@en ;
    eaop:classifiedByType eaoptax:BusinessCapabilityModel ;
    eaop:usedInProcess eaop:StrategicPlanning ;
    # Zachman classification
    zach:classifiedByCell zachtax:R2C1_InventoryDefinition .

# A solution design
ex:PaymentDesign a eaop:Design ;
    skos:prefLabel "Payment Service Detailed Design"@en ;
    eaop:classifiedByType eaoptax:SolutionDesign ;
    eaop:usedInProcess eaop:InitiativeDelivery ;
    # Zachman classification (spans multiple cells)
    zach:classifiedByCell zachtax:R4C2_ProcessSpecification ,
                          zachtax:R4C1_InventorySpecification ,
                          zachtax:R4C3_DistributionSpecification .

Completeness Analysis

Use Zachman to check if your EA practice has gaps:

PREFIX zach: <https://meta.linked.archi/zachman/onto#>
PREFIX zachtax: <https://meta.linked.archi/zachman/tax#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

# Which Zachman perspectives have the fewest artifacts?
SELECT ?perspective ?perspectiveLabel (COUNT(?artifact) AS ?count) WHERE {
    ?perspective skos:broader zachtax:Perspective ;
                 skos:prefLabel ?perspectiveLabel .
    OPTIONAL {
        ?cell zach:hasPerspective ?perspective .
        ?artifact zach:classifiedByCell ?cell .
    }
}
GROUP BY ?perspective ?perspectiveLabel
ORDER BY ?count

Portfolio Overview

Use EA on a Page to understand your artifact portfolio:

PREFIX eaop:    <https://meta.linked.archi/eaonapage/onto#>
PREFIX eaoptax: <https://meta.linked.archi/eaonapage/tax#>
PREFIX skos:    <http://www.w3.org/2004/02/skos/core#>

# Artifact portfolio by CSVLOD type
SELECT ?group ?groupLabel (COUNT(?artifact) AS ?count) WHERE {
    ?group skos:broader eaoptax:ArtifactTypes ;
           skos:prefLabel ?groupLabel .
    OPTIONAL {
        ?type skos:broader ?group .
        ?artifact eaop:classifiedByType ?type .
    }
}
GROUP BY ?group ?groupLabel
ORDER BY ?group

Summary

Dimension Zachman EA on a Page
Origin Theoretical (1987) Empirical (2017, 27+ orgs)
Nature A priori classification (classificatory, not prescriptive) Descriptive observation (empirical)
Classification axis 1 Interrogative (What/How/Where/Who/When/Why) Type (CSVLOD)
Classification axis 2 Reification Transformation / Perspective (Identification→Instantiation; Planner→Enterprise) Usage frequency (Essential/Common/Uncommon)
Classification axis 3 — Nature (Rules/Structures/Changes)
Classification axis 4 — Focus (Business-focused/IT-focused)
Temporal dimension Timing column (but no artifact lifecycle) Lifecycle (permanent/long-lived/short-lived)
Process dimension None Three processes (Strategic Planning, Initiative Delivery, Technology Optimization)
Completeness 36 cells (exhaustive) 24 artifacts (empirically validated)
Practical value Gap analysis — "what are we missing?" Portfolio management — "what do we actually produce?"
In Linked.Archi zach:classifiedByCell against the 36 zachtax: SKOS cells a eaop:Standard (OWL type) + eaop:classifiedByType eaoptax:… (24 SKOS artifacts) + inter-type relationships

Use Zachman to ensure completeness. Use EA on a Page to ensure relevance. Use both to classify every artifact in your knowledge graph.

Zachman helps classify fine-grained architecture artifacts or views across the logical space of enterprise description. EA on a Page identifies common EA artifacts used in practice. In both cases, deliverables are compositions that may contain several artifacts and may span multiple cells or types.

References

Further Reading