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.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Framework structure used
3. Classification method
4. Artefact inventory
5. Cell inventory
6. Primitive and composite models
7. Coverage and gap analysis
8. Cross-row and cross-column alignment
9. Mapping to other frameworks
10. Priorities and remediation plan
11. Ownership and governance
12. Glossary and references

1. Purpose and scope

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

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

2. Framework structure used

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.

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.

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

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

4. Artefact inventory

5. Cell inventory

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.

5.2 Coverage score per cell

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

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

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

6.3 Composite usage register

7. Coverage and gap analysis

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

8.1 Vertical checks (same column, adjacent rows)

8.2 Horizontal checks (same row, different columns)

9. Mapping to other frameworks

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

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

11.1 Cell ownership

11.2 RACI

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

12.1 Glossary

12.2 References

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.