EFG-Zachman-Enterprise-Framework2-An-Overview.pdf

7/30/2019 EFG-Zachman-Enterprise-Framework2-An-Overview.pdf

1/4Copyright 1998-2010 The Enterprise Framework Group Page 1

by Thomas A. Hokel

The Zachman Enterprise Framework2 was initially created by

John A. Zachman and published in 1987. The Framework

organizes and categorizes architectural representations in a way

that provides a context for understanding the relationship between

and among separate sets of architectures. These architectures are

the glue that holds together the design artifacts (business strategy

models, organization charts, data models, process models, network

models, workflow models, business rules, application structure

charts, program/module specifications, etc.) of the enterprise or

any other complex product that can be engineered. The Framework

organizes the architectures of these descriptive representations to

provide understanding of their relationship to each other. This is

important in order to create, develop, maintain and change the

enterprise.

The Framework serves as an analytical, organization and

classification tool by providing specific, normalized reference

points (cells) that are be used to hold the architecture products

(i.e., primitive models) and may also be used to hold a myriad of

other relevant support artifacts (i.e., composites, standards, roles,

methods, techniques, tools, training, glossaries, and references) of

development efforts.

Zachman Framework for ArchitectureThe concepts incorporated in the Zachman Framework for

Architecture were derived from classical architecture and aircraft

manufacturing analogs, both of which have a proven track record

of producing complex constructs requiring an engineered approach

to development and modification. John A. Zachman initially

formalized these concepts in his landmark, and now legendary,

article A Framework for Information Systems Architecture that

appeared in the 1987 IBM Systems Journal, Volume 26, Number3.

Developing, changing and maintaining the enterprise requires

different kinds of architectural representations or descriptions, for

example, contextual scoping models, conceptual business models,

logical design models, physical technology models, detailed

component specifications, et cetera, that are defined and used by

different participants for different purposes and, hence, have

different points of view and different constraints. These enterprise

architectural representations, although they are integrated, are

inherently delineated by six transformations defined as: Scope,

Business, System, Technology, Component, and Operations. These

Reification Transformations1 are reflected in the Framework as

rows. Each row is then further classified into the following sixprimitive interrogatives: What, How, Where, Who, When, and

Why. These Communication Interrogatives are reflected in the

Framework as columns. The thirty-six (6 X 6) frames at the core of

the integrated Framework are referred to as cells.

[1. Reification literally means "to make into a thing" the turning of something

abstract into a concrete thing or object. Informally, reification is often referred to as

"making something a first-class citizen" within the scope of a particular system.Reification is a process through which something that was previously implicit and

unexpressed is explicitly formulated and made available to conceptual, logical, ortechnical manipulation. Reification can be applied as a stepwise refinement and is

one of the most frequently used techniques of conceptual analysis and knowledgerepresentation.]

The Zachman Enterprise Framework2

Different TransformationsWhen an individual (executives) requires a new building, th

acquire the services of an architect(s). The executives provide t

architect with a concept definition of their requirements;

example, their motivation for needing the building, the function

would serve, where the building would be located, who wou

occupy and utilize it, and perhaps material preferences a

operating schedules. The architects prepare drawings of t

building with those requirements and constraints in mind. The

drawings enable the executives and the architects to reach

common ground of understanding and a level of confidence

each other.

Once the drawings have been approved, they can be used

prepare the architects plans. When the plans are complete a

have been approved, the executives acquire the services of

engineering team. The engineers are constrained by the laws

physics and available technology. Working from the architec

plans, the engineers prepare detailed specifications (contracto

plans) for the building. Working from the contractors plans, t

contractors and subcontractors, aided by vendors and supplie

construct the building. The executives receive a certificate

occupancy and should be quite pleased with the end results.

The concepts of reification transformation from definition

representation to specification also apply to industrial produc

The Work Breakdown Structure is analogous to the Architec

Drawings, the Engineering Design is analogous to the ArchitecPlans, and the Manufacturers Engineering Design is analogous

the Contractors Plans.

These proven classical architecture and industrial product concep

used to engineer complex structures and products can be applied

engineering the enterprise itself. The primary transformations a

their descriptive representations relative to each discipline a

shown in the following table.



Classical

Architecture

Industrial

Products

Enterprise

Architecture

Executives

(Definition)

Architects

Drawings

Work Break-

down Structure

Business

Model

Architects

(Representation)

Architects

Plans

Engineering

Design

System

Model

Engineers

(Specification)

Contractors

Plans

Manufacturers

Engineering

Design

Technology

Model

Different Transformations

Each discipline (Executives, Architects, Engineers) must take into

account the requirements and constraints of the other disciplines.

For example, the architects must design a building for the purpose

that the executives intend for the building. Moreover, the

architects must design the building given the executives

conceptual constraints, but not distort it so that it is not

recognizable by the executives. And the engineers must specify the

physical building given the architects logical constraints, but not

distort it so that it is not recognizable by the architects. It is this

formal, well-disciplined transformation that results in producing a

product that is desirable.Understanding the requirements and constraints necessitates

communication from discipline to discipline so that the

transformation from concept to reality can take place. The

Framework points the vertical direction (i.e., alignment) for

understanding and communication between transformations.

Different InterrogativesInherent in each transformation are six primitive interrogatives that

are used for communication. Each interrogative addresses a

fundamental question: Whatis it made of? How does it function?

Where are things located? Who is involved? When do events

happen? Why are things done? The manner in which the answers to

these questions are described, of course, depend upon thediscipline answering (concretizing) these questions.

To quote John A. Zachman, By abstracting out one of these six

variables and holding the other five constant, but not losing sight

of them, attention can be intently focused on only one variable.

For example, the What interrogative for Classical Architecture

concerns itself with Material; for Industrial Products, a Bill of

Materials; and for Enterprise Architecture, an Inventory. The

following chart roughly depicts the analogous concepts of the

What, How and Where communication interrogatives.

What How Where

Classical

Architecture

Material Function Location

Industrial

Products

Bill of

Materials

Functional

Specs

Drawings

Enterprise

Architecture

Inventory Process Network

Different Interrogatives

The Framework for a ProductA depiction of the Framework classification can be formed

treating the transformations as rows and the interrogatives

columns. Each discipline defines, completely and holistically,

integrated view of the product from that transformation ro

Within a transformation, it is also convenient and natural to foc

or concentrate on a selected aspect or topic of the product.

aligning the transformations with the closed set of interrogatives

framework can be formed.

The Framework provides a classification schema or period

table of elements. As Zachman observes, All formal disciplinhave some means by which to organize and classify its discover

and products, whether the field of knowledge is chemist

biology, mathematics, physics, or information.

The Framework helps facilitate the communication of ideas duri

the architecture of complex products, whether they are building

industrial products or enterprises. Literally, it provides a frame

reference. Although the Framework describes the same thing, it

convenient and natural to view the product from t

transformations of the different disciplines involved in

development.

As a communications device and facilitator of change, t

Framework provides an elegant tool of cognition. It is a natur

simple, straight-forward, and powerful approach to addressicomplex ideas, complex concepts, complex systems, compl

technologies and complex products.

The complete, extended Framework for a product is depicted in t

following matrix schema. The Strategists discipline channels t

ensuing architectural development activities by defining what is

and what is out of scope of the product. It defines the context

the bounds of the Framework for planning purposes and represe

the identification transformation. The Technicians discipli

contains the detailed configuration of sub-assemblies a

represents the component transformation. The last transformati

is not a descriptive representationper se it is the realized produ

itself.

What How Where Who When Wh

Strategists

Executives

Architects

Engineers

Technicians

Product

The Framework for a Product

The transformations integrate the cells horizontally. T

interrogatives align and integrate the cells vertically. Therefore,

of the cells formed by the formal matrix schema are cohesive

bound horizontally and vertically. They are integrated because th

describe the same, whole thing. As a classification schema, t

Framework is generic and can be used for describing almo

anything! One of the attractions to the Framework is its simplic

as a tool of cognition. The Framework has wholeness a

rightness to it.



The Zachman Enterprise FrameworkThe concepts of enterprise architecture are an abstraction of the

concepts of the older, successful classifications found in classical

architecture and industrial products that are applied to the

enterprise. The Executives transformation corresponds to the

conceptual business definition of the enterprise. The Architects

transformation corresponds to the logical system representation.

The Engineers transformation corresponds to the physically

constrained technology specification whether they are automated

or manual.

What How Where Who When Why

Scope

Business

System

Technology

Component

Operations

The Zachman Enterprise Framework

Each column addresses one aspect of the architectural descriptionfor each transformation. The answer to What always relates to

some type of entity but each transformation will describe the

answer to that question differently. An entity might be a person,

place, thing or event. Depending on the transformation, it might be

a conceptual business entity, a logical system entity or a physical

technology entity.

In the Scope identification row, an entity would be something in

the business world and expressed in natural semantic language as a

bounding list of types of things, e.g., a taxonomy of business

resources. For example, Customers would be a high level

aggregation of some things of interest for potential inclusion in the

ensuing modeling activities.

In the Business definitions row, the conceptual entities from the

Scope row would be modeled to define the business relationships

between them. For the System transformation, Customers would

be viewed in logical representation terms as a surrogate

Customer data entity and could be expressed in logical data

model form. For the Technology transformation, Customer

would be considered in technical specification terms and modeled

as a physical data entity, for example, a database table. The

Component row would contain re-usable technology items, such as

data elements, data classes, data formats, and data types, that could

be configured for Customer. Finally, for the Operations

transformation, which is an actual instantiation of the enterprise

and not an architectural description, Customer data would be

inventoried in an operational database table row/record.

To answer the question How, one must describe business

functions and processes within the natural world in natural

language for the Scope and Business transformations; logical

system processes for the System transformation; technical

application processes for the Technology transformation; and

program/module processes for the Component transformation.

Each of the other columns operates similarly as each provides part

of the complete architectural description. See the Framework at the

end of this overview for examples of the primitive models in other

cells.

ArchitecturesBy providing a formal means for understanding a compl

product, any complex product including enterprises, t

Framework enables communication, understanding, integrati

and alignment among the various disciplines involved

architecting or changing the product. Architecture is the glu

that holds the product together. The Framework defines sets

architectures that contain the architectural representations of t

product.

Architectures depict the structures contextual, conceptual, logic

physical and out-of-context fundamental (primitive) elements. Tdepiction promotes integration of the relationships within, betwe

and among the sets of architectures. If a piece of the architectu

set is not made explicit, it is implicit and subject to erroneo

assumptions, which introduce risk into all aspects of developme

maintenance and change.

There is no single architecture, no one way of depicting

transformation. Since there are multiple transformations, there a

multiple architectures. Additionally, because each discipli

describes the structure from each of the communicati

interrogatives, there are multiple and varied architectures.

Architectures are also additive and complementary. T

architecture for a given transformation carries the constraints a

requirements of the architectures from which it is transformed. the same time, the architectures in the row below it are align

with and complement the architectures in the row above it

depicting information not found in the above architectures.

The Framework is comprised of many different sets

architectures. It neither prescribes nor proscribes particu

architectures. Nor does the Framework prescribe or proscri

different approaches, standards, methods, tools or techniques us

by the disciplines defining those architectures. It is neutral, a

says nothing, with respect to development methodologies since

does not specify tasks, dependencies, resources, contro

deliverables, et cetera. The Framework is a STRUCTURE ... no

process (methodology). Of course, the Framework can help y

evaluate and define your chosen standards, roles, methodologiand tools.

Architectural DescriptionsThe cells constitute the core matrix of the Framework. While t

transformations differ from row to row, each column manifests

single abstraction, expressed as an interrogative. Additional

architectural descriptions of the content of the cells adhere to

fundamental generic meta-model. For example, the meta-model

the cells formed by the What column involves entities and th

relationships between one another. The entity/relationship (thin

to-thing) meta-model characterizes each of the What cells. S

the Zachman Framework at the end of this overview for the oth

generic column meta-models.

Each cell is different from the others. Each requires or impli

certain content in the others. And each constrains the content of t

others. Of course, there is a cost for spending time providing t

detail of the contents of each cell for establishing architectures

for making cells explicit. On the other hand, there are ris

involved for not providing details of the contents of each cell f

not establishing architectures for leaving cells implicit or

insufficient levels of detail. These risks can also be measured

time and/or dollars, for example, when project work has to

redone or scrapped because wrong assumptions were mad

resulting in poor decisions, resulting in unproductive work.



Framework ValuesArchitecture is an asset-based long-term strategy not an expense.

Enterprise Architecture is an investment you make to enable you

to do the things you are otherwise unable to do, John A.

Zachman.

A value that the Framework provides is a more orderly and

coordinated approach to all aspects of development and safely

changing products that maintain their relevance in a dynamic

marketplace. The Framework partitions any complex thing into

communication interrogatives, which provide formalisms for each

disciplines reification transformation. Negotiation andcompromise are not eliminated, but they are usually minimized to

adjacent transformations. Additionally, the results of one

successful architectural effort, even if it is for just one cell, can be

leveraged and serve as the basis or pattern for other architectural

efforts, thereby shortening the lead time required for producing

new implementations (i.e., reduced cycle times).

The Framework encompasses the transformations of all

disciplines, business problem approaches, enterprise engineering

development methodologies, quality manufacturing approaches

(TQM), architectural thinking, construction processes, et cetera.

The Framework not only betters the understanding of o

discipline or transformation with another, but also serves as

conduit through which disparate disciplines can begin

communicate, understand and reuse the approaches, standar

roles, methods, techniques and tools of other disciplines bringi

new ways to handle new architecture efforts and implementation

Furthermore, the value of the Framework expands exponentia

when one considers change to an enterprise. The end-st

vision, submits John A. Zachman, should be the accumulation

all models such that every cell is explicitly defined, enterpris

wide, horizontally and vertically integrated, at an excruciatilevel of detail in order to approach change in a surgical fashion.

Most enterprises are in critical condition and struggling for th

lives in the age of the concepts revolution. If they cannot tap t

talent and resources within themselves and leverage the talent a

resources outside themselves, they will never survive long enou

to reach the end-state vision. The Framework provides t

architectural concepts for tapping that talent and those resources.

ZACHMANENTERPRISE

FRAMEWORK2

WHATEntity/

Relationship

HOWTransform/

Input

WHERELocation/

Connection

WHORole/

Work

WHENCycle/

Moment

WHYEnd/

Means

SCOPEIdentification

Strategists

Business

Resource

Types

Taxonomy

Business

Process

Types

Taxonomy

Business

Network

Types

Taxonomy

Business

Organization

Types

Taxonomy

Business

Event

Types

Taxonomy

Business

Motivation

Types

Taxonomy

BUSINESSDefinition

Executive Leaders

Business

Resource

Model

Business

Process

Model

Business

Network

Model

Business

Workflow

Model

Business

Cycle

Model

Business

Strategy

Model

SYSTEMRepresentation

Architects

Logical

Data

Model

Logical

Process

Model

Network

Schematic

Model

Workflow &

Interface

Design

Logical

Dynamics

Model

Business

Rules

Model

TECHNOLOGYSpecification

Engineers

Physical

Data

Model

Application

Process

Specification

Technology

Network

Specification

Workflow &

Interface

Specification

Execution

Timing

Specification

Business Rules

Enforcement

Specification

COMPONENTConfiguration

Technicians

Database

Component

Configuration

Program

Component

Configuration

Network

Component

Configuration

Workflow &

Interface

Component

Configuration

Execution

Control

Component

Configuration

Business Rule

Enforcement

Component

Configuration

OPERATIONS

InstantiationWorkers

OperationalDatabases

OperationalApplications

OperationalNetwork

OperationalWorkflows

OperationalEvents

OperationalRules

Inventory Process Network Organization Timing Motivation

The Zachman Enterprise Framework2

with TEFG example Primitive Model names

The Enterprise Framework Group Web site: www.tefg.com

Email: [email protected] Phone: 1.970.453.7293

Documents

EFG-Zachman-Enterprise-Framework2-An-Overview.pdf