Copyright © 2013 Curt Hill The Zachman Framework What is it all about?

Copyright © 2013 Curt Hill

The Zachman Framework

What is it all about?

Introduction

• John A. Zachman is sometimes called the grandfather of EA

• His paper defined EA as a discipline• His idea of an architecture is a set

of documents that defines every thing needed to describe or construct a product

• His framework then defines the categories of these documents


The Matrix• Two dimensional classification

scheme for descriptive representations of an Enterprise.

• The columns are defined by questions one might ask about any endeavor– Who, what, where, when, how, why– Also called abstractions

• The row are defined by perspectives– Strategists, executives, architects,

engineers, technicians, workers


One View


Another


Yet Another


Generality• Zachman claims this is an ontology

– Also a normalized schema

• This matrix could be applied to any architecture, not just EA– Constructing cars, constructing buildings,

constructing enterprises

• There is no methodology associated with this framework– Methodologies might change in each

different context

• An implementation or instantiation is the finished product


Claims

• An ontology represents knowledge as a set of concepts within a domain, and the relationships between pairs of concepts– The framework is an analytic tool

• The normalized schema has one meta-fact in each grid location– The rows and columns are in their

correct order and are complete


Another Representation


Data What

Function How

Network Where

People Who

Time When

Motivation Why

Scope (Contextual)

Planner’s View

Things important to the Business

Process Performed

Business Locations

Important Organizations

Events Significant to the Business

Business Goals &

Strategies

Business Model (Conceptual) Owner’s View

Semantic Model

Business Process Model

Business Logistics System

Work Flow Model

Master Schedule

Business Plan

System Model (Logical)

Designer’s View Logical Data

Model Application Architecture

Distributed system

Architecture

Human Interface

Architecture (i.e., Roles)

Processing Structure

Business Rule Model

Technology Model

(Physical) Builder’s View

Physical Data Model

System Design

Technology Architecture

Presentation Architecture

Control Structure

Rule Design

Detailed Representations

Integrator or Subcontractor

View

Data Definition

Program Network

Architecture Security

Architecture Timing

Definition Rule Design

Functioning Enterprise

User’s View Data Function Network Organization Schedule Strategy

More Detail

• We have not enough to go on just yet

• We need a more thorough description of the various rows and column descriptions

• First the columns• Next the rows


What

• The material abstraction• What is it made out of

– What components are used

• The bill of materials • Semantic structures• Process models• This is about structure


How

• The functional abstraction• How it works

– How do the pieces work together

• Functional specifications of the transformations

• This is about process


Where

• The geometry abstraction• Drawings• The spatial or relational or

process network of interconnection

• This is about locations


Who

• Who does what work?• Workflow modeling• Operating instructions• What roles perform what

actions• This is about people and roles


When

• When do thing happen in relation to other things

• Timing diagrams• Dynamic or time models• This is about the dynamics or

timing of events


Why

• Design objectives• Motivation models• This is about strategies


Scoping boundaries

• Strategist’s perspective– The grand view of everything

• Context that establishes the inner and outer limits

• The list of relevant constituents that must be accounted for in the descriptive representations


Requirements

• Conceptual view• The nature of the business• A model of the business• The owners perspective• The recipient (customer, user)

of the end product• What are we going to do with

the end productCopyright © 2013 Curt Hill

Logical

• Designer’s perspective– Engineering descriptions

• Model of the systems• Logical representation of the

enterprise• Interface between what is

desirable and possible• How is data transformed within the

organization


Builder’s Perspective

• Blueprints and schematics• Manufacturing engineers

description• Technology model

– Technologist determines what is possible

– What technologies are available to solve business problems


Tooling configuration

• Implementer's perspective• Detailed representations

– How does a department work?

• How do we convert from models and specification into the real item

• Specific applications and their detailed instructions


Implementation

• This is the real thing, not an architecture

• The operator’s perspective


Mappings

• The Zachman framework maps onto many methodologies

• OMG’s Model Driven Architecture contains– Computation Independent Model– Platform Independent Model– Platform Specific Model

• These three are three different rows in framework


Column cells

• Lets zero in on the people or who column and look at the individual cells

• Objective or scoping row– Which organizational units will be

considered?– Is this a department within a larger

organization?– Do we need to look at groups outside,

eg. Suppliers consumers?


Owner intersect people

• The owner is a very high level view• The organization chart is the key

document• It is annotated with upper level

titles and duties• Typically a department is

represented only by its manager– Thus not every person is shown


Architect intersect people

• This is the logical view of what people do

• The interactions they have with:– Employees– External people– Information technology

• What roles exist?


Technology Designer

• Human computer interface– Type of data in the interface

• General specifications of the programs– Security considerations should be

included here

• System architecture


Builder

• Actual screen layout– Input from person– Outputs to the person

• Program architecture• User guides


Note• The programs in the system need

input from several cells of the framework

• The who column, builder row documents user interface

• The what column of the same row discusses the data to be used

• The how column looks at the internal structure of the program to be produced

• The programmer needs all of these


Discussion

• Let’s consider the handout of the chart

• What does each cell represent?• What sort of documentation should

exist to cover the cell?• Are you ready to gather some of

this kind of data?


Documents

Copyright © 2013 Curt Hill The Zachman Framework What is it all about?