Zachman Framework

About the Zachman Framework for Enterprise Architecture

This page briefly discusses the Zachman Framework and how one could use it. And ... the original article is available for download at the bottom of the page.

The Zachman Framework is a diagram with two axes. It was created by J.A. Zachman in 1987 and was first named 'Information Systems Architecture'.

Axis 1 - The What, How, When, Who, Where, and Why

This axis is about the first words in 'open'-questions: What, How, When, Who, Where, and Why.

Axis 2 - Engineering Phases

This axis is about engineering phases where an idea is transformed into a thing: Identification, Definition, Representation, Specification, Configuration, and Instantiation.

A fundamental structure

The Zachman Institute claims the following: 'There is substantial evidence to establish that our framework is the fundamental structure for Enterprise Architecture. It thus yields the total set of descriptive representations relevant for describing an Enterprise.'

Historical Versions

1984

1987

1992

Definitions of Enterprise Architecture Terms by Zachman

Zachman appears to define Architecture as a set of primitive models. Zachman: 'If you are not building (storing, managing, and changing) primitive models, you are not doing Architecture. You are doing implementations.'

A 6 x 6 matrix

Everyone knows the shape of the Zachman Framework as a 6 x 6 matrix, and every cell contains a set of well-known diagrams. You can use the matrix as a reporting schema to visualize or report what type of information is available and unavailable, or what type of situations are known and unknown in a certain enterprise.

	Data (What)	Function (How)	Network (Where)	People (Who)	Time (When)	Motivation (Why)
Objectives / Scope	List of things important to the enterprise	List of processes the enterprise performs	List of locations where the enterprise operates	List of organizational units	List of business events / cycles	List of business goals / strategies
Business Model	Entity relationship diagram (including m:m, n-ary, attributed relationships)	Business process model (physical data flow diagram)	Logistics network (nodes and links)	Organization chart, with roles; skill sets; security issues.	Business master schedule	Business plan
Information System Model	Data model (converged entities, fully normalized)	Essential Data flow diagram; application architecture	Distributed system architecture	Human interface architecture (roles, data, access)	Dependency diagram, entity life history (process structure)	Business rule model
Technology Model	Data architecture (tables and columns); map to legacy data	System design: structure chart, pseudo-code	System architecture (hardware, software types)	User interface (How the system will behave); security design	"Control flow" diagram (control structure)	Business rule design
Detailed Representation	Data design (denormalized), physical storage design	Detailed Program Design	Network architecture	Screens, security architecture (who can see what?)	Timing definitions	Rule specification in program logic
Function System	Converted data	Executable programs	Communications facilities	Trained people	Business events	Enforced rules

Rules of the Framework

Zachman defines seven rules for using his framework:

Rule 1: Do Not Add Rows or Columns to the Framework
Rule 2: Each Column Has a Simple Generic Model
Rule 3: Each Cell Model Specializes Its Column’s Generic Model
Rule 4: No Meta Concept Can Be Classified Into More than One Cell
Rule 5: Do not Create Diagonal Relationships Between Cells
Rule 6: Do Not Change the Names of the Rows or Columns
Rule 7: The Logic is Generic, Recursive

Zachman vs TOGAF

TOGAF, as an approach to realize TOGAF-type architecture, and Zachman, as a framework to get ideas for what models and diagrams to make or look for, are a good fit. There is often insufficient time to create all the Zachman models and diagrams. Your people select the most important ones.

Zachman vs Dragon1

Zachman sees enterprise architecture as a set of (written-down) primitive models. The Dragon1 Framework sees enterprise architecture as a total concept of an enterprise. And that total concept consists of coherent concepts. These concepts consist of elements (at a logical level), components (at a physical level, and technical products (at an implementation level).

Dragon1 Framework recognizes all the (logical and physical) models and diagrams of the Zachman Framework, and adds additional (conceptual and meta) models and diagrams.

A big difference, or maybe the main difference, between the Zachman model and Dragon1 is that Zachman makes the elements like a process 'mandatory' to use by an architect, whereas Dragon1 states that if you, as an architect, use business concepts that contain the element 'process', only then will processes become part of the architecture of your enterprise.

So, you might as well have an enterprise architecture without any elements that Zachman defines as mandatory. This means that from a Dragon1 perspective, Zachman is not a framework for enterprise architecture but a reference enterprise architecture for common process-oriented enterprises and organizations.

In other words, Zachman limits the enterprise architectures that can be designed by an enterprise architect using the Zachman framework. Dragon1 open EA Method does not limit the enterprise architectures an enterprise architect can design. There are no mandatory concepts or elements to use.

When working with the Zachman framework example is still a valuable guideline for discovering primitives in your organization.