Zachman Framework

Home

The bottommost row is greyed out as it relates to

actual implementation and is not part of Architecting.
The main idea behind the Zachman framework is that the same system can be viewed by
different people in different way depending on their point of reference. For an example, the CEO
may be more interested in defining the scope of the system rather than about which java class is
implementing a particular functionality. On the other hand a component designer will be
interested in knowing what java class he should be using. Though he might know about the scope
of the system, knowing the java class will be more important for him. This does not mean that
the scope view is more important than the implementation view. This just means that different
people need different view to understand the same system depending on their need.
The Zachman Frame work defines thirty six different perspectives. It is expected that these
perspective will cover all viewpoints needed by anyone in the organisation. It includes technical
viewpoint about the architecture as well as logistic details about how and where it will be
implemented and by whom.
Each row of the framework represents a total view of the solution. Its goal (Why), its process
(How), modelling (What), organisational structure (who), Implementation location (where) and
timelines (when). The solution view at the higher level is more relevant to top management and
as we go down the rows, it becomes more relevant to the implementers.
The details at a particular level serves as an input level to the lower level to add further details
from the lower perspective. So at a particular level (row) sufficient details needs to be captured

for the lower level. Understanding the requirements and constraints necessitates communication
of knowledge and understanding from perspective to perspective. The Framework points the
vertical direction for that communication between perspectives
Let us have a look at these levels in some more details.
Contextual (Scope)
1.

(Why) Goal List primary high level organization goals. In most cases, these will be
defined elsewhere in the organisation, Such as Organisation Vision, Business goals etc.

2.

(How) Process List list of all known and proposed processes. At this level just the
identification of the processes is needed. No need to go into details of the process. Just
identify the process name and its purpose.

3.

(What) Material List list of all known organizational entities. A common and easy way
to list this is to identify thinks which can be classified as noun

4.

(Who) Organizational Unit & Role List list of all organization units, sub-units, and
identified roles.

5.

(Where) Geographical Locations List locations important to organization; can be large

and small

6.

(When) Event List list of triggers and cycles important to organization

Conceptual (Enterprise Model)

1.

(Why) Goal Relationship Model identifies hierarchy of goals that support primary goals

2.

(How) Process Model provides process descriptions, input processes, output processes

3.

(What) entity Relationship Model identifies and describes the organizational materials
and their relationships

4.

(Who) Organizational Unit & Role Relationship Model identifies enterprise roles and
units and the relationships between them

5.

(Where) Locations Model identifies enterprise locations and the relationships between
them

6.

(When) Event Model identifies and describes events and cycles related by time

Logical (System Model)

1.

(Why) Rules Diagram identifies and describes rules that apply constraints to processes
and entities without regard to physical or technical implementation

2.

(How) process Diagram identifies and describes process transitions expressed as verbnoun phrases without regard to physical or technical implementation

3.

(What) Data Model Diagram identifies and describes entities and their relationships
without regard to physical or technical implementation

4.

(Who) Role Relationship Diagram identifies and describes roles and their relations to
other roles by types of deliverables without regard to physical or technical implementation

5.

(Where) Locations Diagram identifies and describes locations used to access,

manipulate, and transfer entities and processes without regard to physical or technical
implementation

6.

(When) Event Diagram identifies and describes events related to each other in
sequence, cycles occur within and between events, without regard to physical or technical
implementation

Physical (Technology Model)

1.

(Why) Rules Specification expressed in a formal language; consists of rule name and
structured logic to specify and test rule state

2.

(How) Process Function Specification expressed in a technology specific language,

hierarchical process elements are related by process calls

3.

(What) Data Entity Specification expressed in a technology specific format; each entity
is defined by name, description, and attributes; shows relationships

4.

(Who) Role Specification expresses roles performing work and workflow components
at the work product detailed specification level

5.

(Where) Location Specification expresses the physical infrastructure components and

their connections

6.

(When) Event Specification expresses transformations of event states of interest to the

enterprise

Detailed Representation (Subcontractors View)

Eventually the cells with the detailed representation give Rules detail for (Why); Process detail
for (How); Data detail for (What); Role detail for (Who); Location detail for (Where); and Event
detail for (When).
Functioning (Actual System View)
This view is not used for enterprise architecture while the enterprise is described by rows one to six,
enterprise architecture uses only rows one to five