1. The Use of Zachman Framework Primitives for Enterprise Modeling
Gundars Osvalds
Senior Principal Member of Technical Staff
Litton/TASC
26 October 2000

2. Contents Enterprise Architecture purpose and definition
Architecture perspectives
Architecture components
The Zachman Framework
Modeling of a framework
Architecture definition process description
Uses the Unified Modeling language (UML)

3. Purpose of an Enterprise Architecture
A building plan for a system or set of systems
Set of high-level design decisions made by senior architects
Addresses important system-wide issues
Documents decisions that affect the subsequent elaboration of a system

4. Architecture-centric Process Model
<<include>>
Design the
System
Engineer
Identify a
Framework
Architect
Develop an
Architecture
<<include>>
Stakeholder
Document
Requirements
Define a
Mission
<<include>>
Developer
<<include>>
Implement
a System

5. What Is an Architecture Framework?
A definition of the information system via models
What Is an Architecture Framework?
A representation of the information system via views of models
How does this relate to an information system implementation?
The architecture model guides the implementation

6. It all begins with the framework
Conceptual Model
It all begins with the framework
Architecture Framework
Enterprise
Stakeholder
Mission 1
1..*
defines
Requirement
scopes
holds
Architecture Description
Information System
fulfills
guides
Architecture
represents
documents
implements
Model
View
specifies
describes
System Description
Artifacts
comprise
contains
This model documents the architecture-centric concepts associated with enterprise development

7. Framework Components
A logical structure for classifying and organizing the models of an enterprise
Architecture Framework
Architecture Description
Architecture
represents
documents
Model
View 1
1..*
specifies
describes
Artifacts
comprise
A formal definition of an enterprise system
Contains the views that are used to describe the architecture
One or more abstractions e.g., Planner, Owner, Designer, Builder, Subcontractor
The basic elements
Representations of the Data, Function, Network, People, Time, and Motivation

8. Why Select Zachman Framework as Benchmark
Performed industry survey on frameworks
Determined that the Zachman Framework describes architecture elements
Can be used describe any other framework using elements
Since being developed 13 years ago it has consistently proven itself
Used in whole/part by:
Federal Architecture Framework
C4ISR Architecture Framework (in “All Views”)
Tool Vendors (Ptech, Popkin)
Spewak’s Enterprise Architecture Planning

9. What is The Zachman Framework
“The Zachman Framework is a total set of descriptive representations to fully describe a complex object” John Zachman
The Zachman Framework is a framework of “elements”
Defines various Abstractions and Perspectives

10. Conceptual Description of The Zachman Framework
MOTIVATION
(Why)
TIME
(When)
PEOPLE
(Who)
NETWORK
(Where)
FUNCTION
(How)
DATA
(What)
Abstractions
Perspectives
Objective/
Scope
(Contextual)
Enterprise
Model
(Conceptual)
System
(Logical)
Technology
(Physical)
Detailed
Model (Out of
Context)
Planner
Owner
Designer
Builder
Each cell in the Zachman Framework represents the intersection of a particular focus and perspective. Each focus (the question – what, how, where, who, when, and why – being addressed) is depicted in a column and each perspective (point of view) in a row.
Because the point of view of the person asking or answering a question is what gives meaning to the answer, the perspective determines the kind of information which will be recorded in that row. Without a proper perspective, information can never become knowledge. For example, eliminate any perspective or point of view from your mind and then try to describe your network. What comes to mind? It could be any number of things: your network of friends and business associates, the locations of your business, the topology of the cables, routers, etc. that make up your LAN. You can’t describe your network in a useful way without a perspective.
The perspectives define the point of view or the level of abstraction for the information contained in the cell. If you look across all of the cells in a single perspective, you will see all of the Enterprise’s knowledge from that perspective. If the Framework is properly utilized the information and models within a single row will represent a complete description of the Enterprise from that perspective.
At the same time, each column captures all of the Enterprise’s knowledge for the particular question being asked, i.e., and the focus (sometimes called dimensions.) By isolating each question (focus) and defining the artifacts for each perspective within that column you build the total Enterprise knowledge for each focus.
Subcontractor
Functioning Enterprise

11. Zachman Framework for Enterprise Architecture
John A. Zachman, Zachman International
DATA
Implementation
What
FUNCTION
How
NETWORK
Where
e.g. Data Definition
Entity = Field
Rel. = Address
e.g., Physical Data Model
Entity = Tables/Segments/etc.
Rel. = Key/Pointer/etc.
e.g., Logical Data Model
Entity = Data Entity
Rel. = Data Relationship
e.g., Semantic Model
Entity = Business Entity
Rel. = Business Relationship
List of Things -
Important to the Business
Entity = Class of
Business Thing
List of Processes -
the Business Performs
Function = Class of
Business Process
e.g., Application Architecture
Process.= Application Function
I/O = User Views
e.g., System Design
Process= Computer Function
I/O =Data Elements/Sets
e.g. Program
Process= Language Statement
I/O = Control Block
e.g., Business Process Model
Process = Business Process
I/O = Business Resources
List of Locations -
in which the Business Operates
Node = Major Business
Location
e.g., Logistics Network
Node = Business Location
Link = Business Linkage
e.g., Distributed System
Architecture
Node = IS Function
Link = Line Characteristics
e.g., Technical Architecture
Node = Hardware/System
Software
Link = Line Specifications
e.g. Network Architecture
Node = Addresses
Link = Protocols
MOTIVATION
Why
TIME
When
PEOPLE
Who
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g., Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural Assertion
Means =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals and Strategies
Ends/Means=Major Business
Goal/Critical Success Factor
List of Events -
Significant to the Business
Time = Major Business Event
e.g., Processing Structure
Time = System Event
Cycle = Processing Cycle
e.g., Control Structure
Time = Execute
Cycle = Component Cycle
e.g. Timing Definition
Time = Interrupt
Cycle = Machine Cycle
SCHEDULE
e.g., Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations -
People = Class of People and
Major Organizations
e.g., Work Flow Model
People = Organization Unit
Work = Work Product
e.g., Human Interface
People = Role
Work = Deliverable
e.g., Presentation Architecture
People = User
Work = Screen/Device Format
e.g. Security Architecture
People = Identity
Work = Job
ORGANIZATION
STRATEGY
e.g., Business Plan
SCOPE
Planner
SYSTEM
MODEL
Designer
TECHNOLOGY
CONSTRAINED
Builder
DETAILED
REPRESEN-
TATIONS
Subcontractor
ENTERPRISE
Owner
contextual
conceptual
logical
physical
out-of-context
FUNCTIONING
perspectives
abstractions
© Copyright 2000 TASC, Inc. All Rights Reserved

12. Relationship of Models to the Zachman Framework
How does Zachman define primitives, single-variable models?
How are the single-variable models in to describe the perspectives?
How does the Zachman framework define the perspective views?

13. Each cell contains a single variable model
Zachman Framework Single Variable Examples
John A. Zachman, Zachman International
DATA
Implementation
What
FUNCTION
How
NETWORK
Where
e.g. Data Definition
Entity = Field
Rel. = Address
e.g., Physical Data Model
Entity = Tables/Segments/etc.
Rel. = Key/Pointer/etc.
e.g., Logical Data Model
Entity = Data Entity
Rel. = Data Relationship
e.g., Semantic Model
Entity = Business Entity
Rel. = Business Relationship
List of Things -
Important to the Business
Entity = Class of
Business Thing
List of Processes -
the Business Performs
Function = Class of
Business Process
e.g., Application Architecture
Process.= Application Function
I/O = User Views
e.g., System Design
Process= Computer Function
I/O =Data Elements/Sets
e.g. Program
Process= Language Statement
I/O = Control Block
e.g., Business Process Model
Process = Business Process
I/O = Business Resources
List of Locations -
in which the Business Operates
Node = Major Business
Location
e.g., Logistics Network
Node = Business Location
Link = Business Linkage
e.g., Distributed System
Architecture
Node = IS Function
Link = Line Characteristics
e.g., Technical Architecture
Node = Hardware/System
Software
Link = Line Specifications
e.g. Network Architecture
Node = Addresses
Link = Protocols
MOTIVATION
Why
TIME
When
PEOPLE
Who
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g., Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural Assertion
Means =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals and Strategies
Ends/Means=Major Business
Goal/Critical Success Factor
List of Events -
Significant to the Business
Time = Major Business Event
e.g., Processing Structure
Time = System Event
Cycle = Processing Cycle
e.g., Control Structure
Time = Execute
Cycle = Component Cycle
e.g. Timing Definition
Time = Interrupt
Cycle = Machine Cycle
SCHEDULE
e.g., Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations -
People = Class of People and
Major Organizations
e.g., Work Flow Model
People = Organization Unit
Work = Work Product
e.g., Human Interface
People = Role
Work = Deliverable
e.g., Presentation Architecture
People = User
Work = Screen/Device Format
e.g. Security Architecture
People = Identity
Work = Job
ORGANIZATION
STRATEGY
e.g., Business Plan
SCOPE
Planner
SYSTEM
MODEL
Designer
TECHNOLOGY
CONSTRAINED
Builder
DETAILED
REPRESEN-
TATIONS
Subcontractor
ENTERPRISE
Owner
contextual
conceptual
logical
physical
out-of-context
FUNCTIONING
perspectives
abstractions
Each cell contains a single variable model
© Copyright 2000 TASC, Inc. All Rights Reserved

14. Work Product Generation
The Zachman Framework defines primitive elements
Each cell then presents an example of a single-variable model
We define composite models to use several primitives in the same model
The composite model creates work products

15. Primitives to Work Products
The cells contain
primitives
Node = Business Location
Link = Business Linkage
e.g., Logistics Network
Artifacts contain
model data
NETWORK Artifact
(Where)
Described as
Single-variable
Model
LOGICAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
Logical Components
Logical Packages
Logical
Interactions
Logical Scenarios
Composite Models
are the
Work Products
Designer’s View

16. Zachman Framework Artifacts
DATA
Implementation
FUNCTION
NETWORK
SCHEDULE
ORGANIZATION
STRATEGY
FUNCTIONING
ENTERPRISE
Artifact
PEOPLE
TIME
MOTIVATION
CONTEXTUAL
ARTIFACTS
CONCEPTUAL
PHYSICAL
OUT-OF-
CONTEXT
LOGICAL
MODEL ARTIFACTS
Artifacts contains model data

17. Create Views and Composite Models
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
OUT-OF-
CONTEXT
ARTIFACTS
FUNCTIONING
ENTERPRISE
CONTEXTUAL
CONCEPTUAL
LOGICAL
PHYSICAL
DATA
Implementation
FUNCTION
SCHEDULE
ORGANIZATION
STRATEGY
DATA Artifact
FUNCTION Artifact
NETWORK
NETWORK Artifact
Create View with Models using transformations between abstraction artifacts
Transformation is the key to bridging the perspectives
© Copyright 2000 TASC, Inc. All Rights Reserved

18. External Inputs to the Zachman Framework
Concept of
Operations
Requirements
Business
Plan
CONTEXTUAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
PEOPLE Artifact
TIME Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
NETWORK Artifact
MOTIVATION Artifact
© Copyright 2000 TASC, Inc. All Rights Reserved

19. Contextual Risks/Benefits Contextual Organization
Bridging the Zachman Framework Perspectives - Planner’s View
CONTEXTUAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
PEOPLE Artifact
TIME Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
NETWORK Artifact
MOTIVATION Artifact
Contextual Resources
Contextual Process
Contextual Information
Contextual Risks/Benefits
Contextual Organization
Contextual
Concepts
Contextual Goals
Planner’s View
CONCEPTUAL
ARTIFACTS
DATA Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
FUNCTION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
© Copyright 2000 TASC, Inc. All Rights Reserved

20. Conceptual Resource Interactions Conceptual Process States
Bridging the Zachman Framework Perspectives - Owner’s View
CONCEPTUAL
ARTIFACTS
DATA Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
FUNCTION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
Conceptual
Process
Conceptual Resource Interactions
Conceptual Process States
Owner’s View
LOGICAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
© Copyright 2000 TASC, Inc. All Rights Reserved

21. Bridging the Zachman Framework Perspectives - Designer’s View
LOGICAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
Logical Components
Logical Packages
Logical
Interactions
Logical Scenarios
Designer’s View
PHYSICAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
© Copyright 2000 TASC, Inc. All Rights Reserved

22. Physical Interactions
Bridging the Zachman Framework Perspectives - Builder’s View
PHYSICAL
ARTIFACTS
(How)
(What)
(Where)
(Who)
(When)
(Why)
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
Physical
Behaviors
Activities
Physical Elements
Physical Interactions
Physical Deployment
Builder’s View
FUNCTIONING
ENTERPRISE
DATA
Implementation
FUNCTION
NETWORK
SCHEDULE
ORGANIZATION
STRATEGY
DATA Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
FUNCTION Artifact
(How)
(What)
(Where)
(Who)
(When)
(Why)
OUT-OF-
CONTEXT
ARTIFACTS
© Copyright 2000 TASC, Inc. All Rights Reserved

23. Process Documentation
The process develops the models that represent the architectural views
Developed a method for documenting work product models
Used UML Use Case diagrams to document the process
Used Use Case descriptions to document the recommended steps

24. Defining the Enterprise Architecture
Define
Designer View
Planner View
Gather
Mission
Guidelines
Builder View
Owner View
Frame
Architecture
Owner
(Stakeholder)
Mission Guidelines
(Vision)
Planner
(Architect)
Designer
(System Engineer)
Builder
Subcontractor
Note: Line color
indicates who
uses the artifact
<<uses>>
Out-of-Context Artifacts
Logical Artifacts
Conceptual Artifacts
Contextual Artifacts
guides
reviews
Physical Artifacts
builds
defines
gathers
This Use Case shows the high-level representation of the process that produces the artifacts associated with defining the enterprise architecture

25. Document the Framework Process
Developed top-level description using UML Use Case diagrams
Defined the identified objects (models) using UML diagrams
Goal is to use simple UML diagrams so that the process can be easily communicated
Added icons to the UML Activity Model to incorporate objects previously defined
Entered descriptions of each step of the architecture modeling process

26. Define Planner View
Identify
Contextual
Risks and
Benefits
Organization
Resources
Define
Process
Information
Concepts
Goals
Planner
(Architect)
UML Model
Owner
(Stakeholder)
UML Class
UML Activity
w/Objects
This Use Case shows the models used to define the Planner’s View

27. Business Concepts Example Diagram
<<entity>>
Project
+ Name : char
+ Organization : char
+ Description : char
persistent
Architectural Description
Customer
Business Unit
Company
Section
UML Class Diagram
Beta:Project
Name = <unspecified>
Organization = <unspecified>
Description = <unspecified>
Alpha:Project
Systems Engineering:"Business Unit"
TASC:"Architectural Description"
Enterprise Architecture:Section
Acme Business:Customer
TASC:Company

28. Sample Use Case Step Documentation
Use Case: Identify Business Concepts
Communicates With Case Worker: Owner (Stakeholder)
Communicates With Actor: UML Models
Communicates With Case Worker: Planner (Architect)
Child Diagram(s): Example: Identify Business Concepts [UML Class]
Description: Build a Conceptual Model. Define the important concepts used in the business. Use the following Scope Artifacts: Data, Function, Network, People, and Motivation. Output will fill in the Enterprise Model Artifact: Data with list of business objects.
Use Case Steps
Step Text 1.
"Create objects from Scope artifacts"
Use a UML Class diagram to represent important concepts used in the enterprise. Document each concept with a few sentences in the description fields. 2.
"Define interactions between objects"
Document the relationships between the business concept objects using information from the Scope Artifacts.
Preconditions: "Defined Scope Artifacts“
Postconditions: "Defined Enterprise Model Artifacts"

29. Architecture-Centric
Enterprise Architecture Process Development
Enterprise Organization that uses Information Technology to perform its mission
Architecture "Blueprint" of the Enterprise that provides guidance to the Systems Engineers
Process Procedures that are used by the Architect to develop the Architecture
Views Abstractions of the Enterprise that use Models to represent the Architecture
Models Conceptual representations of the Enterprise
Architecture-Centric
Conceptual Model `
Architecture Framework
Enterprise 1
scopes
1..*
Information System
guides
Information System Architecture
represents
implements
Model
View
describes
System Description
documents
Artifacts
comprise
Architecture Description
defines
Mission
Stakeholder
holds
Requirement
fulfills
specifies
Transformations
ARTIFACTS
CONTEXT
OUT-OF-
ENTERPRISE
FUNCTIONING
NETWORK Artifact
PEOPLE Artifact
MOTIVATION Artifact
FUNCTION Artifact
CONTEXTUAL
DATA Artifact
TIME Artifact
CONCEPTUAL
LOGICAL
PHYICAL
Create View with Models using transformations between abstraction artifacts
Implementation
DATA
FUNCTION
NETWORK
SCHEDULE
ORGANIZATION
STRATEGY `
Model Bridge
(How)
(What)
(Where)
(Who)
(When)
(Why)
CONCEPTUAL
ARTIFACTS
DATA Artifact
FUNCTION Artifact
NETWORK Artifact
PEOPLE Artifact
TIME Artifact
MOTIVATION Artifact
Business Concepts
Contextual
Contextual Process
Contextual Information
Contextual Resources
Contextual Risks/Benefits
Contextual Goals
Contextual Organization
CONTEXTUAL
Planner’s View
Process
Define
Designer View
Planner View
Gather
Mission
Guidelines
Builder View
Owner View
Frame
Architecture
Owner
(Stakeholder)
Mission Guidelines
(Vision)
Planner
(Architect)
Designer
(System Engineer)
Builder
Subcontractor
<<uses>>
Out-of-Context Artifacts
Logical Artifacts
Conceptual Artifacts
Contextual Artifacts
guides
reviews
Physical Artifacts
builds
defines
gathers
<<entity>>
Project
+ Name : char
+ Organization : char
+ Description : char
persistent
Architectural Description
Customer
Business Unit
+ Description :
Company
Section
Beta:Project
Name = <unspecified>
Organization = <unspecified>
Description = <unspecified>
Alpha:Project
Cryptologic Engineering:"Business Unit"
TASC:"Architectural Description"
Enterprise Architecture:Section
Acme Corp:Customer
TASC:Company
Model
© Copyright 2000 TASC, Inc. All Rights Reserved

30. Summary
Used the Zachman Framework to define the basic artifacts that the modeling process uses
Documented the transformation bridge that provides traceability from the Zachman Framework to the models representing the system implementation
Identified the basic models (OO) needed to model an Enterprise Architecture
Documented the Enterprise Architecture views in a repeatable framework process