# Zachman Framework Classification: [Enterprise or scope]

> Classification of an enterprise's architecture artefacts against the
> Zachman Framework for Enterprise Architecture (version 3.0, 2011): an
> artefact inventory, a six by six cell inventory showing which
> perspective and interrogative each artefact answers, the split between
> primitive and composite models, coverage gaps, cross-row alignment
> checks, a mapping to other frameworks and a prioritised remediation
> plan with cell owners. The Zachman Framework is a classification
> schema (an ontology), not a method: use this template to see what your
> repository describes and what it leaves out, then use a method such as
> the TOGAF ADM to produce what is missing. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Work in this order: 1 (decide why you classify and what scope) -> 2
  (agree how to read the rows and columns) -> 4 (inventory artefacts)
  -> 5 (place them in cells) -> 6 (split composites) -> 7 and 8 (find
  gaps and misalignments) -> 10 and 11 (prioritise and assign owners).
- Classify what exists. Do not create artefacts to fill cells for their
  own sake; a gap matters only when a decision or risk depends on it.
- Use only the row and column labels. Do not copy the content of the
  framework graphic into this document; write your own one-line notes.
- The worked examples describe a fictional regional bank classifying
  its payments domain. Delete them once your own rows exist.
-->

## Document control

<!-- Guidance: Identify the scope being classified and the repository snapshot used. A classification is a point-in-time view; record the snapshot date so later comparisons are honest. -->

| Field | Value |
|---|---|
| Document ID | [ZFC-001] |
| Enterprise or scope classified | [Enterprise, business unit, domain or programme] |
| Repository snapshot | [Repository name, export date YYYY-MM-DD] |
| Framework version used | Zachman Framework for Enterprise Architecture, version 3.0 (2011) |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@enterprise-architect] |
| Approvers/reviewers | [@chief-architect], [@head-of-business-architecture], [@data-architect] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief architect | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Business architecture lead | [@name] | [Decision] | YYYY-MM-DD |
| Data and technology architecture leads | [@names] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First classification of the repository snapshot |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Composite models split into primitives; gaps scored |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Remediation plan approved by the architecture board |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Framework structure used](#2-framework-structure-used)
3. [Classification method](#3-classification-method)
4. [Artefact inventory](#4-artefact-inventory)
5. [Cell inventory](#5-cell-inventory)
6. [Primitive and composite models](#6-primitive-and-composite-models)
7. [Coverage and gap analysis](#7-coverage-and-gap-analysis)
8. [Cross-row and cross-column alignment](#8-cross-row-and-cross-column-alignment)
9. [Mapping to other frameworks](#9-mapping-to-other-frameworks)
10. [Priorities and remediation plan](#10-priorities-and-remediation-plan)
11. [Ownership and governance](#11-ownership-and-governance)
12. [Glossary and references](#12-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Say which decision the classification informs. Typical reasons: an audit of the architecture repository, scoping a transformation, preparing for a merger, or showing a regulator that the enterprise is described consistently. -->

### 1.1 Purpose

This document classifies the architecture artefacts of [scope] against
the six interrogatives and six perspectives of the Zachman Framework, so
that [Organisation] can [see which questions its models answer and for
whom, find gaps that create risk, remove duplicated models, and plan the
next architecture work].

### 1.2 What classification is and is not

| It is | It is not |
|---|---|
| A way to label each artefact by the question it answers and the audience it serves | A process for producing architecture |
| A coverage check across the whole enterprise description | A demand to fill all 36 cells for every scope |
| A neutral vocabulary that works alongside TOGAF, ArchiMate, C4 or arc42 | A replacement for those methods, languages or templates |
| A way to separate single-question (primitive) models from mixed (composite) ones | A judgement on the quality of each model |

### 1.3 Scope

- **Enterprise boundary**: [payments domain of the retail bank,
  including outsourced card processing].
- **Artefact sources**: [architecture repository, wiki spaces, the ADR
  log, the CMDB, the process library].
- **Excluded**: [project management documents with no architecture
  content; draft models older than 24 months].
- **Snapshot date**: YYYY-MM-DD.

### 1.4 Related documents

| ID | Document | Relationship |
|---|---|---|
| REF-01 | Business Capability Map (`architecture/business-capability-map`) | Classified as a Why or How model at the Business Management perspective |
| REF-02 | Value Stream Map (`architecture/value-stream-map`) | Composite model, split in section 6 |
| REF-03 | TOGAF Architecture Vision (`architecture/togaf-architecture-vision`) | Executive perspective artefact; consumes the gaps in section 7 |
| REF-04 | Architecture Definition Document (`architecture/architecture-definition-document`) | Architect and Engineer perspective content |
| REF-05 | Architecture Description (ISO/IEC/IEEE 42010) (`architecture/architecture-description-42010`) | Views and viewpoints mapped in section 9 |
| REF-06 | Architecture Repository index | [Location] |

## 2. Framework structure used

<!-- Guidance: Agree how your organisation reads each column and row before you classify. Write the reading notes in your own words. Different teams interpret the rows differently; a shared reading prevents arguments later. -->

### 2.1 Columns: the six interrogatives

The columns are the six questions that can be asked about any thing.
The notes are this organisation's own reading aids, not definitions
from the framework.

| Column | Interrogative | Reading aid for this organisation | Typical artefacts here *(Example)* |
|---|---|---|---|
| C1 | What | The things the enterprise must know about and keep track of | Conceptual data model, information concepts, product catalogue |
| C2 | How | The transformations that turn inputs into outputs | Process models, capability map, application function lists |
| C3 | Where | The locations and the connections between them | Site list, network topology, deployment diagrams |
| C4 | Who | The parties, roles and the work assigned to them | Organisation chart, RACI, role catalogue, access model |
| C5 | When | The events and cycles that drive timing | Business calendar, event catalogue, batch schedules |
| C6 | Why | The goals, strategies, rules and constraints | Strategy, principles, business rules, policies |

The version 3.0 graphic orders the columns What, How, Where, Who, When,
Why. Keep that order in every table so cells are easy to compare.

### 2.2 Rows: the six perspectives

Each row is the viewpoint of an audience with a different level of
abstraction, moving from scope to operating reality. The audience labels
below are those commonly shown on the version 3.0 graphic, and the
transformation labels follow the reification names given on the
publisher's page (Identification, Definition, Representation,
Specification, Configuration, Instantiation). Check both, and where they
sit on the graphic, against the current official version before
publishing.

| Row | Audience perspective | Transformation | Reading aid for this organisation |
|---|---|---|---|
| R1 | Executive | Identification | Lists and boundaries: what is in scope, at the level of a strategy paper |
| R2 | Business Management | Definition | Business models in business terms, independent of any system |
| R3 | Architect | Representation | Logical models of systems, technology-neutral |
| R4 | Engineer | Specification | Physical design bound to chosen technologies |
| R5 | Technician | Configuration | Tool-level configuration, code and settings |
| R6 | Enterprise | Instantiation | The running enterprise: actual records, events, people and sites |

### 2.3 Classification rules

- **One cell per primitive**: an artefact that answers one question for
  one audience goes in exactly one cell.
- **Composites are split**: an artefact that answers several questions
  is recorded as composite and decomposed in section 6.
- **Rows are not detail levels**: a very detailed business process model
  is still Business Management (R2) if it is free of system design.
  Rows change the audience and the kind of constraint, not merely the
  amount of detail.
- **Row 6 is reality**: operational records belong in R6 only as a
  pointer to where the actual instances live (CMDB, HR system, data
  catalogue); do not copy them into the repository.
- **Recursion is allowed**: a domain, a product line or a programme can
  be classified as its own enterprise. Record the scope in section 1.3.

## 3. Classification method

<!-- Guidance: Follow the same steps each time so that repeat classifications can be compared. Time-box the exercise; the aim is a usable picture, not a perfect inventory. -->

The diagram shows the steps; each step lists its output.

```mermaid
flowchart TD
  A[Define scope and snapshot] --> B[Collect artefact list]
  B --> C[Interview owners: question answered, audience]
  C --> D{Answers one question for one audience?}
  D -- Yes --> E[Place in one cell as primitive]
  D -- No --> F[Record as composite and split into primitives]
  F --> E
  E --> G[Score coverage per cell]
  G --> H[Check alignment across rows and columns]
  H --> I[Identify and prioritise gaps]
  I --> J[Assign cell owners and remediation]
```

| Step | Activity | Output | Responsible |
|---|---|---|---|
| 1 | Agree scope, repository snapshot and reading aids (section 2) | Signed-off scope | [@enterprise-architect] |
| 2 | Export or list every candidate artefact | Draft inventory (section 4) | [@repository-manager] |
| 3 | Ask each owner which question the artefact answers and for which audience | Classified inventory | Artefact owners |
| 4 | Split composite models (section 6) | Primitive list | [@enterprise-architect] |
| 5 | Score each cell (section 5.2 scale) | Cell inventory | Domain architects |
| 6 | Run alignment checks (section 8) | Misalignment list | Domain architects |
| 7 | Prioritise gaps and agree remediation (section 10) | Remediation plan | Architecture board |

## 4. Artefact inventory

<!-- Guidance: List every artefact in scope with its owner, currency and source. Currency matters more than existence: a ten-year-old data model is often a gap in disguise. -->

| Artefact ID | Artefact | Type | Owner | Last reviewed | Current (Yes / Stale / Unknown) | Primary cell | Primitive or composite |
|---|---|---|---|---|---|---|---|
| ART-001 *(Example)* | Payments strategy 2026 to 2028 | Document | [@head-of-payments] | YYYY-MM-DD | Yes | R1 C6 | Primitive |
| ART-002 *(Example)* | Payments business capability map | Model | [@business-architect] | YYYY-MM-DD | Yes | R2 C2 | Primitive |
| ART-003 *(Example)* | Conceptual payments data model | Model | [@data-architect] | YYYY-MM-DD | Stale | R2 C1 | Primitive |
| ART-004 *(Example)* | Make Payment value stream map | Model | [@business-architect] | YYYY-MM-DD | Yes | R2 C2 | Composite |
| ART-005 *(Example)* | Logical application architecture, payments hub | Model | [@solution-architect] | YYYY-MM-DD | Yes | R3 C2 | Composite |
| ART-006 *(Example)* | Payments database physical schema | Model | [@dba-lead] | YYYY-MM-DD | Yes | R4 C1 | Primitive |
| ART-007 *(Example)* | Kubernetes deployment manifests | Code | [@platform-lead] | YYYY-MM-DD | Yes | R5 C3 | Primitive |
| ART-008 *(Example)* | Payments ADR log | Log | [@solution-architect] | YYYY-MM-DD | Yes | R3 C6 | Primitive |
| ART-009 *(Example)* | Batch and cut-off schedule | Schedule | [@ops-lead] | YYYY-MM-DD | Unknown | R5 C5 | Primitive |
| ART-010 *(Example)* | Payments operations RACI | Table | [@ops-lead] | YYYY-MM-DD | Yes | R2 C4 | Primitive |
| [ART-NNN] | [Artefact] | [Type] | [@owner] | YYYY-MM-DD | [Currency] | [Rn Cn] | [Type] |

## 5. Cell inventory

<!-- Guidance: Fill the six by six table with artefact IDs, then score each cell. Empty cells are not automatically problems; section 7 decides which ones matter. -->

### 5.1 Coverage matrix

Each cell lists the artefact IDs (primitive models or primitives split
out of composites) that answer that question for that audience. In the
example, ART-011 to ART-023 are further rows of the section 4 inventory
that are not shown there to keep the table short; your inventory must
list every ID used here.

| Perspective | C1 What | C2 How | C3 Where | C4 Who | C5 When | C6 Why |
|---|---|---|---|---|---|---|
| R1 Executive *(Example)* | ART-011 | ART-002 (L1 only) | none | ART-012 | none | ART-001 |
| R2 Business Management *(Example)* | ART-003 (stale) | ART-002, ART-004a | none | ART-010 | ART-004c | ART-013 |
| R3 Architect *(Example)* | ART-014 | ART-005a | ART-005b | none | ART-015 | ART-008 |
| R4 Engineer *(Example)* | ART-006 | ART-016 | ART-017 | ART-018 | none | ART-019 |
| R5 Technician *(Example)* | ART-020 | ART-021 | ART-007 | ART-022 | ART-009 | ART-023 |
| R6 Enterprise *(Example)* | Pointer: data catalogue | Pointer: process mining | Pointer: CMDB | Pointer: HR system | Pointer: event logs | Pointer: policy register |
| [Row] | [IDs] | [IDs] | [IDs] | [IDs] | [IDs] | [IDs] |

### 5.2 Coverage score per cell

Use one scale for every cell and record the score in a copy of the
matrix.

| Score | Meaning |
|---|---|
| 0 | No artefact answers this question for this audience |
| 1 | An artefact exists but is stale, partial or unowned |
| 2 | A current, owned artefact exists but is not linked to neighbouring cells |
| 3 | A current, owned artefact exists and is aligned with the cells above and beside it |

| Perspective | C1 | C2 | C3 | C4 | C5 | C6 |
|---|---|---|---|---|---|---|
| R1 Executive *(Example)* | 2 | 2 | 0 | 2 | 0 | 3 |
| R2 Business Management *(Example)* | 1 | 3 | 0 | 2 | 1 | 2 |
| R3 Architect *(Example)* | 2 | 2 | 2 | 0 | 1 | 3 |
| R4 Engineer *(Example)* | 3 | 2 | 2 | 2 | 0 | 2 |
| R5 Technician *(Example)* | 3 | 3 | 3 | 2 | 1 | 2 |
| R6 Enterprise *(Example)* | 2 | 1 | 3 | 3 | 2 | 1 |

In this example the R1 to R3 rows of the Where and When columns are
weak: the bank has good technical deployment models but no business
view of locations or of the events that drive payment cut-offs.

## 6. Primitive and composite models

<!-- Guidance: Most real artefacts are composites: a value stream map or an application architecture diagram mixes several questions. Split each composite into the primitive parts it contains, so coverage is counted honestly and reuse becomes visible. -->

### 6.1 Why the split matters

A primitive model answers a single question for a single audience, so it
can be reused in many composites. A composite model combines several
primitives to support a particular decision. Composites are useful and
often necessary, but if a cell is covered only by fragments inside
composites, nobody owns the underlying primitive and the composites
drift apart. The split shows which primitives deserve their own owned
artefact.

### 6.2 Composite decomposition

| Composite | Primitive part ID | Part | Cell | Stand-alone primitive exists? | Action |
|---|---|---|---|---|---|
| ART-004 Make Payment value stream *(Example)* | ART-004a | Stages and their order | R2 C2 | Yes (ART-002 links) | None |
| ART-004 *(Example)* | ART-004b | Participating units | R2 C4 | Partly (ART-010) | Reconcile with RACI |
| ART-004 *(Example)* | ART-004c | Trigger and cut-off events | R2 C5 | No | Create business event catalogue |
| ART-005 Logical application architecture *(Example)* | ART-005a | Application functions | R3 C2 | No | Extract application function list |
| ART-005 *(Example)* | ART-005b | Logical nodes and links | R3 C3 | No | Keep in composite for now |
| [ART-NNN] | [ART-NNNx] | [Part] | [Rn Cn] | [Yes / Partly / No] | [Action] |

### 6.3 Composite usage register

| Composite | Decision it supports | Primitives it draws on | Owner |
|---|---|---|---|
| ART-004 *(Example)* | Payment portfolio priorities | ART-002, ART-010, ART-004c | [@business-architect] |
| ART-005 *(Example)* | Hub replacement design | ART-014, ART-005a, ART-005b, ART-008 | [@solution-architect] |
| [ART-NNN] | [Decision] | [IDs] | [@owner] |

## 7. Coverage and gap analysis

<!-- Guidance: Turn low scores into gaps only when a decision, risk or obligation depends on the cell. State the consequence of each gap in business terms; "cell R2 C5 is empty" convinces nobody, "nobody can say which business events drive cut-off times" does. -->

| Gap ID | Cell | Gap description | Consequence if not addressed | Decision or risk affected | Severity (1 to 5) |
|---|---|---|---|---|---|
| GAP-001 *(Example)* | R2 C5 | No business event and cycle model for payments | Cut-off changes are made in batch schedules without business review | Instant payments programme, regulatory deadlines | 5 |
| GAP-002 *(Example)* | R2 C1 | Conceptual data model is stale | New products introduce conflicting meanings of "payment" | Data governance, reporting | 4 |
| GAP-003 *(Example)* | R1 C3, R2 C3 | No business view of locations and jurisdictions | Data residency obligations are hard to show | Regulatory reporting, cloud migration | 4 |
| GAP-004 *(Example)* | R3 C4 | No logical role and access model | Access rules are designed per application | Security architecture, audit findings | 3 |
| [GAP-NNN] | [Rn Cn] | [Description] | [Consequence] | [Decision or risk] | [1 to 5] |

Patterns to look for:

- **Bottom-heavy**: rows R4 and R5 well covered, R1 to R3 thin. The
  enterprise knows how it runs systems but not why or for whom.
- **Top-heavy**: strategy and business models without logical or
  physical counterparts. Plans are not reaching delivery.
- **Single-column**: one column well covered across all rows (often How)
  while others are empty. The repository reflects the interests of one
  discipline.
- **Orphan composites**: cells covered only by fragments of composites.

## 8. Cross-row and cross-column alignment

<!-- Guidance: Coverage is not enough; the models in a column must agree with each other from row to row, and models in a row must agree across columns. Check the links that cause trouble most often. -->

### 8.1 Vertical checks (same column, adjacent rows)

| Check ID | Column | Rows | Question | Result | Finding |
|---|---|---|---|---|---|
| ALN-001 *(Example)* | C1 | R2 to R3 | Does every concept in the conceptual model appear in the logical model? | Fail | 4 concepts missing, see GAP-002 |
| ALN-002 *(Example)* | C2 | R2 to R3 | Is every capability realised by at least one application function? | Partial | 3 capabilities unsupported |
| ALN-003 *(Example)* | C6 | R1 to R3 | Do ADRs cite the principles and strategy they serve? | Pass | None |
| [ALN-NNN] | [Cn] | [Rn to Rn] | [Question] | [Pass / Partial / Fail] | [Finding] |

### 8.2 Horizontal checks (same row, different columns)

| Check ID | Row | Columns | Question | Result | Finding |
|---|---|---|---|---|---|
| ALN-010 *(Example)* | R2 | C2 and C4 | Does every process or stage have an accountable unit? | Partial | 2 stages unowned |
| ALN-011 *(Example)* | R2 | C2 and C5 | Is every business process triggered by a named event? | Fail | No event catalogue, see GAP-001 |
| ALN-012 *(Example)* | R3 | C1 and C2 | Does every application function name the data it creates or reads? | Pass | None |
| [ALN-NNN] | [Rn] | [Cn and Cn] | [Question] | [Result] | [Finding] |

## 9. Mapping to other frameworks

<!-- Guidance: Show architects who work with other frameworks where their deliverables land. Use only names of deliverables, views and diagrams; the mapping is your organisation's interpretation, not an official correspondence. -->

| Framework or method | Deliverable, view or diagram | Main cells *(organisation's interpretation)* |
|---|---|---|
| TOGAF Standard | Architecture Vision | R1 C2, R1 C6 |
| TOGAF Standard | Architecture Definition Document, business architecture part | R2 C2, R2 C4, R2 C6 |
| TOGAF Standard | Architecture Definition Document, data and application parts | R3 C1, R3 C2 |
| TOGAF Standard | Architecture Requirements Specification | R3 C6, R4 C6 |
| ISO/IEC/IEEE 42010:2022 | Architecture description views | Depends on the viewpoint; record per view |
| C4 model | System context and container diagrams | R3 C2, R3 C3 |
| C4 model | Deployment diagram | R4 C3 |
| arc42 | Context and scope; building block view | R1 C3, R3 C2 |
| arc42 | Deployment view; runtime view | R4 C3; R3 C5 |
| Architecture decision records | ADR log | R3 C6, R4 C6 |
| Business architecture | Capability map; value stream map | R2 C2; composite of R2 C2, C4, C5 |

Related templates: Architecture Requirements Specification
(`architecture/architecture-requirements-specification`), C4 Architecture
(`architecture/c4-architecture`), Architecture Decision Log
(`architecture/architecture-decision-log`).

## 10. Priorities and remediation plan

<!-- Guidance: Rank gaps by severity and by how many decisions they block. Prefer creating one owned primitive model over patching several composites. Give every action an owner and a date. -->

| Action ID | Gaps addressed | Action | Artefact to create or update | Owner | Due | Priority |
|---|---|---|---|---|---|---|
| ACT-001 *(Example)* | GAP-001 | Build a business event and cycle catalogue for payments | New primitive, R2 C5 | [@business-architect] | YYYY-MM-DD | 1 |
| ACT-002 *(Example)* | GAP-002, ALN-001 | Refresh the conceptual data model and reconcile with logical model | ART-003 update | [@data-architect] | YYYY-MM-DD | 2 |
| ACT-003 *(Example)* | GAP-003 | Add a business location and jurisdiction list | New primitive, R2 C3 | [@enterprise-architect] | YYYY-MM-DD | 2 |
| ACT-004 *(Example)* | GAP-004 | Define a logical role model reused by all payment applications | New primitive, R3 C4 | [@security-architect] | YYYY-MM-DD | 3 |
| [ACT-NNN] | [GAP IDs] | [Action] | [Artefact] | [@owner] | YYYY-MM-DD | [n] |

Acceptance criteria for closing a gap:

- the artefact exists, has an owner and a review date;
- its cell score reaches at least 2;
- the relevant alignment checks in section 8 pass or have a recorded
  exception;
- at least one composite that depends on it references it.

## 11. Ownership and governance

<!-- Guidance: Assign an owner per column or per row, not per cell, unless the enterprise is large. Owners keep their models current and answer for alignment with neighbours. -->

### 11.1 Cell ownership

| Row or column | Owner role | Named owner | Scope |
|---|---|---|---|
| R1 and R2, all columns *(Example)* | Business architecture lead | [@name] | Business-level models |
| C1 What, rows R3 to R5 *(Example)* | Data architecture lead | [@name] | Logical and physical data |
| C3 Where, rows R3 to R5 *(Example)* | Infrastructure architecture lead | [@name] | Network and deployment |
| C4 Who, rows R3 to R5 *(Example)* | Security architecture lead | [@name] | Roles and access |
| R6 pointers *(Example)* | Repository manager | [@name] | Links to systems of record |
| [Row or column] | [Role] | [@name] | [Scope] |

### 11.2 RACI

| Activity | Chief architect | Cell owners | Repository manager | Architecture board |
|---|---|---|---|---|
| Maintain reading aids (section 2) | A | C | R | I |
| Classify new artefacts | I | R | A | I |
| Re-score cells | I | R | C | A |
| Approve remediation plan | C | C | I | A, R |

### 11.3 Review cadence and triggers

- Re-classify at least once a year, and after a major transformation,
  merger or repository migration.
- Classify every new architecture artefact when it is first approved;
  add the cell to the repository metadata.
- Report the cell score matrix to the architecture board with the trend
  since the last classification.

## 12. Glossary and references

<!-- Guidance: Define terms as your organisation uses them, in your own words. Do not paste the framework's own definitions. -->

### 12.1 Glossary

| Term | Meaning in this document |
|---|---|
| Interrogative | One of the six questions (What, How, Where, Who, When, Why) used as columns |
| Perspective | The viewpoint of an audience, used as a row |
| Transformation | The change in kind from one row to the next, from identifying scope to running instances |
| Cell | The intersection of one row and one column |
| Primitive model | A model that answers one interrogative for one perspective |
| Composite model | A model that combines several primitives to support a decision |
| Coverage score | This organisation's 0 to 3 rating of how well a cell is described |
| Classification | Placing an artefact in the cell or cells it answers |

### 12.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Zachman Framework for Enterprise Architecture, Zachman International, zachman-feac.com | Version 3.0 (2011), checked YYYY-MM-DD | Row and column labels only |
| "The Zachman Framework Evolution", zachman-feac.com | Checked YYYY-MM-DD | History of label changes up to version 3.0 |
| The TOGAF Standard, 10th Edition (C220, incorporating Technical Corrigendum 1), The Open Group | 19 May 2025 (catalogue listing); check for later releases | Deliverable names in section 9 |
| ISO/IEC/IEEE 42010:2022, Architecture description | 2022 | View concept in section 9 |
| C4 model, c4model.com; arc42, arc42.org | Current versions | Diagram and section names in section 9 |
| Value Stream Map (`architecture/value-stream-map`) | [Version] | Example composite model |

## Standard and licence note

Structure aligned with the Zachman Framework for Enterprise Architecture,
version 3.0 (2011), by John A. Zachman and Zachman International: only
the six interrogatives (What, How, Where, Who, When, Why), the six
perspective row labels and the transformation names are used, together
with the general idea of primitive and composite models. The framework
graphic and its cell content are copyrighted by Zachman International
and are not reproduced; all reading aids, scales, checks and examples
are original text written for this collection. The Zachman Framework is
a trademark of Zachman International, Inc.; this template is not
affiliated with or endorsed by it. TOGAF and ArchiMate are registered
trademarks of The Open Group. This template uses only the names of
deliverables; all text is original. Check the current official framework
graphic and labels at zachman-feac.com before use. Template licence: MIT.