About the Zachman Framework for Enterprise Architecture
This page briefly discusses the Zachman Framework and how one could use it. And ... we have the original article for you as a 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 first was 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. In practice there is often not enough time available to create all the Zachman models and diagrams, your people make selections of the most important ones.
Zachman vs Dragon1
Zachman sees enterprise architecture as a set of (written down) primitive models. The Dragon1 open EA Method 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 implementational level). The Dragon1 EA Framework recognizes all the (logical and physical) models and diagrams of Zachman but adds other (conceptual and meta) models and diagrams to that.
A big difference, or even maybe the main difference between the Zachman model and Dragon1 open EA Method, is that Zachman makes the elements like a process 'mandatory' to use by an architect, whereas Dragon1 open EA Method states that if you as an architect use business concepts that contain the element 'process', only then processes will become part of the architecture of your enterprise.
So you might as well have an enterprise architecture without any elements Zachman defines as mandatory. This means that from a Dragon1 open EA Method 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. The 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 Dragon1 open EA Method, the Zachman framework example still is a valuable guideline for discovering primitives in your organization.
Free Trial Account
Experience the benefits of our Enterprise Architecture Software for your customers. Do you know that you can sign up for a Trial Account? Or first, you can, as a consultant or architect, try the Demo: Enterprise Architecture Framework
Read Also