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

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)

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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"

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

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