Skip to content

Zachman Framework Primer & Modelling Guide — Enterprise Architecture with Linked.Archi

Architecture teams produce capability maps, data models, process flows, and deployment diagrams with no shared way to say what each artifact describes or where the gaps are. The Zachman Framework provides that classification schema; formalizing it as semantic assets lets you tag artifacts to cells, query coverage gaps, and reconcile classifications across frameworks.

This guide introduces the Zachman Framework as formalized in Linked.Archi, explains how its concepts map to semantic assets, and demonstrates practical classification through worked examples.

Phase 1 — Understanding the Zachman Framework

What is the Zachman Framework?

The Zachman Framework for Enterprise Architecture, created by John Zachman in 1987, is a two-dimensional classification schema for organizing the descriptive representations of an enterprise. It is formed by the intersection of six primitive communication interrogatives and six reification transformations, producing a bounded 6×6 matrix of 36 cells.

The Zachman Framework is not a methodology — it does not prescribe a process for creating architecture, does not define a modelling notation, and does not tell you which artifacts to produce. It classifies the complete logical space of what could be described about an enterprise.

"The Zachman Framework is a schema — the intersection of two historical classifications that have been in use for literally thousands of years. The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from reification, the transformation of an abstract idea into an instantiation." — John Zachman, The Concise Definition of The Zachman Framework

References: - Zachman, J.A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3). - Zachman, J.A. (2008). The Concise Definition of The Zachman Framework. Business Rules Community. - About the Zachman Framework — Zachman International / FEAC Institute - Zachman International

The Two Axes

Communication Interrogatives (Columns)

The six primitive questions that can be asked about any complex thing:

Column Interrogative Abstraction Name What it describes
1 What Inventory The things of the enterprise — material compositions, inventory sets
2 How Process The functioning of the enterprise — process transformations, process flows
3 Where Distribution The locations and connectivity — distribution networks, geographic topology
4 Who Responsibility The people and organizations — responsibility assignments, authority structures
5 When Timing The events, cycles, and schedules — timing cycles, temporal ordering
6 Why Motivation The goals, strategies, and rules — motivation intentions, ends and means

Reification Transformations (Rows)

The six levels of progressive concretization from abstract identification to physical instantiation:

Row Transformation Common Perspective What it produces
1 Identification Executive / Planner Scope contexts — naming and bounding the enterprise
2 Definition Business Management / Owner Business concepts — defining in business terms
3 Representation Architect / Designer System logic — logical models independent of technology
4 Specification Engineer / Builder Technology physics — technology-constrained physical models
5 Configuration Technician / Implementer Tool components — tool-specific implementation details
6 Instantiation Enterprise / Worker Operations instances — the functioning enterprise

The 36 Cells

Each cell is the intersection of one interrogative and one reification transformation. It represents a primitive descriptive representation — the most atomic type of enterprise description.

block-beta
    columns 7
    space:1 c1["What<br/>(Inventory)"] c2["How<br/>(Process)"] c3["Where<br/>(Distribution)"] c4["Who<br/>(Responsibility)"] c5["When<br/>(Timing)"] c6["Why<br/>(Motivation)"]
    r1["Identification<br/>(Planner)"] r1c1["Inventory<br/>Identification"] r1c2["Process<br/>Identification"] r1c3["Distribution<br/>Identification"] r1c4["Responsibility<br/>Identification"] r1c5["Timing<br/>Identification"] r1c6["Motivation<br/>Identification"]
    r2["Definition<br/>(Owner)"] r2c1["Inventory<br/>Definition"] r2c2["Process<br/>Definition"] r2c3["Distribution<br/>Definition"] r2c4["Responsibility<br/>Definition"] r2c5["Timing<br/>Definition"] r2c6["Motivation<br/>Definition"]
    r3["Representation<br/>(Designer)"] r3c1["Inventory<br/>Representation"] r3c2["Process<br/>Representation"] r3c3["Distribution<br/>Representation"] r3c4["Responsibility<br/>Representation"] r3c5["Timing<br/>Representation"] r3c6["Motivation<br/>Representation"]
    r4["Specification<br/>(Builder)"] r4c1["Inventory<br/>Specification"] r4c2["Process<br/>Specification"] r4c3["Distribution<br/>Specification"] r4c4["Responsibility<br/>Specification"] r4c5["Timing<br/>Specification"] r4c6["Motivation<br/>Specification"]
    r5["Configuration<br/>(Implementer)"] r5c1["Inventory<br/>Configuration"] r5c2["Process<br/>Configuration"] r5c3["Distribution<br/>Configuration"] r5c4["Responsibility<br/>Configuration"] r5c5["Timing<br/>Configuration"] r5c6["Motivation<br/>Configuration"]
    r6["Instantiation<br/>(Enterprise)"] r6c1["Inventory<br/>Instantiation"] r6c2["Process<br/>Instantiation"] r6c3["Distribution<br/>Instantiation"] r6c4["Responsibility<br/>Instantiation"] r6c5["Timing<br/>Instantiation"] r6c6["Motivation<br/>Instantiation"]
    space:1 e1["Inventory<br/>Sets"] e2["Process<br/>Flows"] e3["Distribution<br/>Networks"] e4["Responsibility<br/>Assignments"] e5["Timing<br/>Cycles"] e6["Motivation<br/>Intentions"]

    style r1 fill:#4A90D9,color:#fff
    style r2 fill:#E8A838,color:#000
    style r3 fill:#7BC67B,color:#000
    style r4 fill:#9B59B6,color:#fff
    style r5 fill:#E74C3C,color:#fff
    style r6 fill:#95A5A6,color:#000

Key Principles

  1. Each cell is primitive. A cell represents one and only one intersection. Real-world artifacts are often composite — they combine descriptions from multiple cells.

  2. Cells are classification slots, not deliverables. Architecture deliverables (Architecture Definition Documents, roadmaps, governance packages) are compositions that aggregate multiple artifacts/views, each of which may cover one or more cells.

  3. Cells are not viewpoints. A Zachman cell may correspond to a viewpoint family, but it only becomes a proper ISO 42010 viewpoint if stakeholders, concerns, model kinds, notations, and construction rules are explicitly defined. The Linked.Archi asset zachman-viewpoints.ttl derives 36 viewpoints — one per cell — each adding the stakeholder, aspect, and perspective declarations that the bare classification slot lacks, and linking back to the cell it operationalises via zach:classifiedByCell.

  4. The framework is not a methodology. It does not prescribe which cells to fill, in what order, or how much architecture to create. It classifies what could exist, not what should exist.

  5. Rows have a meaningful order. The reification transformations progress from abstract (Identification) to concrete (Instantiation). Columns have no inherent methodological order.

Phase 2 — The Linked.Archi Semantic Model

Namespace and Assets

File Namespace Content
zachman-onto.ttl https://meta.linked.archi/zachman/onto# OWL ontology: Framework individual, properties
zachman-tax.ttl https://meta.linked.archi/zachman/tax# SKOS taxonomy: 6 Aspects, 6 Perspectives, 36 Cells
zachman-viewpoints.ttl https://meta.linked.archi/zachman/viewpoints# Viewpoints: 36 viewpoints (one per cell), Aspect/Perspective individuals
zachman-shapes.ttl https://meta.linked.archi/zachman/shapes# SHACL validation: completeness and consistency checks
zachman-deliverable-templates.ttl https://meta.linked.archi/zachman/deliverable-templates# EA Artifact Coverage Report (5 sections)
zachman-metamodel.ttl https://meta.linked.archi/zachman/metamodel# Metamodel manifest (entry point)

Concept Scheme Structure

The Zachman taxonomy is a single skos:ConceptScheme with five top concepts:

<https://meta.linked.archi/zachman/tax#>
    skos:hasTopConcept zachtax:Aspect,        # 6 columns (Inventory, Process, Distribution, Responsibility, Timing, Motivation)
                       zachtax:Perspective,    # 6 rows (Executive, Business Management, Architect, Engineer, Technician, Enterprise)
                       zachtax:EnterpriseType, # 6 enterprise description categories (Inventory Sets, Process Flows, ...)
                       zachtax:ModelType,      # 6 model categories (Scope Contexts, Business Concepts, ...)
                       zachtax:Cell .          # 36 intersections (e.g., Inventory Identification, Process Representation, ...)
  • Aspect (also known as: column, classification name, interrogative, communication interrogative) — Inventory/What, Process/How, Distribution/Where, Responsibility/Who, Timing/When, Motivation/Why
  • Perspective (also known as: row, audience perspective, reification transformation) — Executive/Identification, Business Management/Definition, Architect/Representation, Engineer/Specification, Technician/Configuration, Enterprise/Instantiation
  • Enterprise Type — the category of enterprise description produced by each column: Inventory Sets, Process Flows, Distribution Networks, Responsibility Assignments, Timing Cycles, Motivation Intentions
  • Model Type — the category of model produced by each row: Scope Contexts, Business Concepts, System Logic, Technology Physics, Tool Components, Operations Instances
  • Cell — the intersection of one Aspect and one Perspective — e.g., zachtax:R3C1_InventoryRepresentation, zachtax:R2C2_ProcessDefinition

Classification Properties

Linked.Archi provides this property for Zachman classification:

Property Purpose Level
zach:classifiedByCell Links an artifact directly to a Zachman Cell Cell-level

The same property is used on deliverables that aggregate multiple artifacts, where it expresses the deliverable's derived coverage summary (see Example 2).

And for navigating the framework structure:

Property Purpose Direction
zach:hasAspect Links a Cell to its column Cell → Aspect
zach:hasPerspective Links a Cell to its row Cell → Perspective
zach:relatedEnterpriseType Links an Aspect to its enterprise description category Aspect → Enterprise Type
zach:relatedModelType Links a Perspective to its model category Perspective → Model Type
zach:rowOrder Display ordering for rows (1-6) on Perspective (denormalized on each Cell)
zach:columnOrder Display ordering for columns (1-6) on Aspect (denormalized on each Cell)

Cell Properties

Each of the 36 cells carries two linking properties (one per axis):

zachtax:R3C1_InventoryRepresentation
    a               skos:Concept ;
    skos:broader    zachtax:Cell ;
    skos:prefLabel  "Inventory Representation"@en ;
    skos:altLabel   "Logical Data Model"@en ;
    zach:hasAspect       zachtax:Inventory ;
    zach:hasPerspective  zachtax:Architect ;
    zach:rowOrder   3 ;
    zach:columnOrder 1 ;
.

Relationship to Other Linked.Archi Concepts

graph TD
    DEL["Architecture Deliverable<br/><i>e.g., Architecture Definition Document</i><br/>zach:classifiedByCell → ProcessDefinition, ..."]
    ART1["Architecture Artifact / View<br/><i>e.g., Business Process Model</i><br/>zach:classifiedByCell → ProcessDefinition<br/>arch:viewConformsToViewpoint → BPMNProcessViewpoint"]
    ART2["Architecture Artifact / View<br/><i>e.g., Logical Data Model</i><br/>zach:classifiedByCell → InventoryRepresentation<br/>arch:viewConformsToViewpoint → DataModelViewpoint"]

    DEL -->|arch:contains| ART1
    DEL -->|arch:contains| ART2

    style DEL fill:#4A90D9,color:#fff
    style ART1 fill:#7BC67B,color:#000
    style ART2 fill:#7BC67B,color:#000

Phase 3 — Practical Classification

Example 1: Classifying individual artifacts

Paste this to classify individual artifacts against the Zachman cells they cover:

@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 business capability map
ex:CapabilityMap a arch:Model ;
    skos:prefLabel "Enterprise Capability Map"@en ;
    zach:classifiedByCell zachtax:R2C1_InventoryDefinition .

# A logical data model
ex:CustomerDataModel a arch:Model ;
    skos:prefLabel "Customer Domain Logical Data Model"@en ;
    zach:classifiedByCell zachtax:R3C1_InventoryRepresentation .

# A deployment diagram
ex:ProductionDeployment a arch:Diagram ;
    skos:prefLabel "Production Deployment Architecture"@en ;
    zach:classifiedByCell zachtax:R4C3_DistributionSpecification .

# A business process model
ex:OrderFulfillmentProcess a arch:Model ;
    skos:prefLabel "Order Fulfillment Process Model"@en ;
    zach:classifiedByCell zachtax:R2C2_ProcessDefinition .

Example 2: Deliverable aggregating artifacts

Use this pattern for a deliverable that aggregates artifacts and rolls up their cell coverage:

@prefix zach: <https://meta.linked.archi/zachman/onto#> .
@prefix zachtax: <https://meta.linked.archi/zachman/tax#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix ex:   <https://model.example.com/myea#> .

# Individual artifacts
ex:ProcessFlowView a arch:View ;
    skos:prefLabel "Order Processing Flow"@en ;
    zach:classifiedByCell zachtax:R2C2_ProcessDefinition .

ex:InformationModelView a arch:View ;
    skos:prefLabel "Order Information Model"@en ;
    zach:classifiedByCell zachtax:R2C1_InventoryDefinition .

ex:OrgResponsibilityView a arch:View ;
    skos:prefLabel "Order Fulfillment Responsibilities"@en ;
    zach:classifiedByCell zachtax:R2C4_ResponsibilityDefinition .

# Deliverable that aggregates them
ex:OrderDomainArchitecture a arch:Model ;
    skos:prefLabel "Order Domain Architecture Definition"@en ;
    arch:contains ex:ProcessFlowView ;
    arch:contains ex:InformationModelView ;
    arch:contains ex:OrgResponsibilityView ;
    # Derived coverage summary
    zach:classifiedByCell zachtax:R2C2_ProcessDefinition ;
    zach:classifiedByCell zachtax:R2C1_InventoryDefinition ;
    zach:classifiedByCell zachtax:R2C4_ResponsibilityDefinition .

Example 3: Dual classification with EA on a Page

Use this when an artifact needs both a Zachman cell and an EA on a Page type:

@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 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
    zach:classifiedByCell zachtax:R3C2_ProcessRepresentation ,
                          zachtax:R3C1_InventoryRepresentation .

Example 4: Coverage gap analysis

Run this query to find Zachman cells that have no classified artifacts:

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 cells have no artifacts?
SELECT ?cell ?cellLabel ?perspLabel ?aspectLabel WHERE {
    ?cell skos:broader zachtax:Cell ;
          skos:prefLabel ?cellLabel ;
          zach:hasPerspective ?perspective ;
          zach:hasAspect ?aspect ;
          zach:rowOrder ?row ;
          zach:columnOrder ?col .
    ?perspective skos:prefLabel ?perspLabel .
    ?aspect skos:prefLabel ?aspectLabel .
    FILTER NOT EXISTS { ?artifact zach:classifiedByCell ?cell . }
}
ORDER BY ?row ?col

Example 5: Query by reification level

Run this query to list all artifacts at the Representation (logical/architect) level:

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#>

# All artifacts at the Representation (logical/architect) level
SELECT ?artifact ?label ?aspect ?aspectLabel WHERE {
    ?cell zach:hasPerspective zachtax:Architect ;
          zach:hasAspect ?aspect .
    ?artifact zach:classifiedByCell ?cell ;
              skos:prefLabel ?label .
    ?aspect skos:prefLabel ?aspectLabel .
}

Validate Classifications with SHACL

The zachman-shapes.ttl file provides validation rules:

  • Valid values: zach:classifiedByCell must point to a concept narrower than zachtax:Cell in the Zachman scheme.
  • Consistency: If an artifact is classified by a Cell, any explicit aspect or perspective declaration (via arch:viewpointCoversAspect / arch:viewpointAddressesPerspective) must match the Cell's row and column.
  • Completeness (reporting): The coverage report flags cells with no classified artifacts (see Example 4).

Run validation:

.scripts/validate.sh --shacl zachman

Appendix A — Common Misconceptions

Misconception Reality
"Zachman is a methodology" It is a classification schema. It does not prescribe process, sequence, or governance.
"Each cell is a deliverable" Cells classify primitive descriptions. Deliverables are compositions of multiple artifacts/views.
"Each cell is a viewpoint" Cells are classification slots. A viewpoint requires additional semantics (concerns, model kinds, notations).
"You must fill all 36 cells" The framework classifies what could exist. Organizations typically populate only a fraction of the 36 cells in practice.
"Columns are Data/Function/Network/People/Time/Motivation" Those are IT-centric aliases. The formal classification names are Inventory/Process/Distribution/Responsibility/Timing/Motivation.
"Rows are just stakeholder audiences" Rows are reification transformations (Identification→Instantiation). Audience perspectives (Planner→Enterprise) are associated labels for the same concept.

Appendix B — Mapping Common Artifacts to Cells

This mapping is heuristic — artifacts may legitimately span multiple cells depending on scope and abstraction level.

Artifact Primary Cell(s) Rationale
Business Capability Map Inventory Definition Defines the things the business does, in business terms
Business Process Model (BPMN) Process Definition Defines how the business works, in business terms
Logical Data Model Inventory Representation Represents data entities as a logical model
Application Architecture Process Representation Represents system functions as a logical model
Network Topology Diagram Distribution Specification Specifies network in technology terms
Organization Chart Responsibility Definition Defines who is responsible, in business terms
Roadmap Timing Identification Identifies key events and milestones at scope level
Strategy Map Motivation Identification Identifies goals and strategies at scope level
Physical Data Model Inventory Specification Specifies data in technology-specific terms
Deployment Diagram Distribution Specification Specifies deployment in technology terms
Security Model Responsibility Representation Represents access and authority as a logical model
Business Rules Motivation Representation Represents constraints as a logical model
DDL / Schema Inventory Configuration Configures data in tool-specific terms
Source Code Process Configuration Configures processes in tool-specific terms

Appendix C — Comparison Articles

For detailed comparisons of the Zachman Framework with other frameworks in Linked.Archi:

References

Disclaimer: This is a community semantic representation of the Zachman Framework for interoperability purposes. It is not produced by, endorsed by, or affiliated with Zachman International, Inc. "Zachman Framework" is a registered trademark of Zachman International, Inc.