Zachman - Popkin Process - Building an Enterprise Architecture

8/11/2019 Zachman - Popkin Process - Building an Enterprise Architecture

1/45


2/45

Table of Contents

Contents

Forewordi

Introduction...ii

Integrating Technologies with Enterprise Architectures.. 1What is an Enterprise Architecture Framework?.. 2The Popkin Process... 3

Enterprise Architecture.. 4

Enterprise Architecture Framework... 5

Focus and Perspective 7 Constraints and Requirements..... 11

Models, the Language of the Framework... 12Common Modeling Methods and How They Relate to the Framework . 13Model Transformations 18

Model Hierarchy within the Framework Cells 19Guidelines for Using an Enterprise Architecture Framework. 20Summary.. 21

The Popkin Enterprise Architecture Framework 22

The Popkin Process: A Set of Pre-defined Uses of the Framework... 27

Tools for Enterprise Architecture... 31Tools for Enterprise Analysis. 34

Conclusion.. 38

Appendix A. 39

References... 41


3/45

Building an Enterprise Architecture: The Popkin Process

i

Foreword

The Information Age is unfolding just as predicted by many of the sociological prognosticators of this century.

Information issues are on everyones mind and on multitudes of lips. It is hard to pick up a newspaper or current

affairs magazine without seeing a feature on the internet, web pages, e-mail, television terminals or some other newtechnology. In fact, technology innovation is relentless and escalating and technology stocks continually drive the

stock market to high after high. There is no field of human endeavor that is exempt from the onslaught of

information technology.

At the same time, in the midst of this information frenzy, the information systems (IS) community is in a state of

disarray ... downsized, out-sourced, over-worked, package-replaced, stressed-out and decentralized. The credibility

of IS is in a steep decline. Everything we have built in the past 50 years (the "legacy"), and everything we are doing

in the present to satisfy current demand, is perceived by management to be hopelessly inadequate.

These issues of quality, timeliness and change are the conditions that are forcing us to face up to the issues of

enterprise architecture. The precedent of all the older disciplines known today establishes the concept of

architecture as central to the ability to produce quality and timely results and to manage change in complex products.

Architecture is the cornerstone for containing enterprise frustration and leveraging technology innovations to fulfill

the expectations of a viable and dynamic Information Age enterprise.If we want the luxury of satisfying immediate needs without an enormous sacrifice in downstream capabilities, we

must make an investment in infrastructure; socially, culturally, spiritually, professionally and ... architecturally.

Increasing flexibility and reducing time to market is not going to happen by accident or through one more

technology acquisition or one more package or one more application implementat ion. It will only happen because of

a responsible and intellectual investment in this case, in developing and maintaining Enterprise Architecture, to

deliver quality information, in fact, to produce a quality enterprise.

The issue of enterprise architecture is critical to the very survival of every enterprise of any substance in the

moderately near future, certainly by the early years of the 21st Century, and it is imperative that those of us in the

information profession facilitate enterprise assimilation of these monumental concepts.

My opinion is, we are on the verge of seeing architecture "come into its own" and in the 21st Century it will be the

determining factor, the factor that separates the winners from the losers, the successful and the failures, the acquiring

from the acquired, the survivors from the others. Today is not too soon to get started!

John A. Zachman


4/45


ii

Introduction

The world of business is changing rapidly. New technologies promise to save us time and money. Mergers and

acquisitions shift the balance of power in entire industries. New business fads and silver bullet products create

stratospheric expectations in users and consumers. And global competition provides a constant threat to businesssurvival.

Because of the madness of modern business, there has been an increasing need for people to understand their

enterprises in a more integrated manner. There is a need to see just what happens in our enterprises. Businessleaders are asking, How? When? Where? Why? Who does what? What tools do they need to do it? The

answers to these questions form the basis of an Enterprise Architecture.

This paper begins with a discussion of Enterprise Architectures and introduces a Zachman Enterprise Architecture

Framework. It then outlines the Popkin Enterprise Architecture Framework and the Popkin Process for using it.

The paper concludes with a description of the tools needed to take advantage of Enterprise Architecture concepts in

your organization.


5/45


1

Integrating Technologies with Enterprise ArchitecturesMuch is said and written these days about tools and technologies for understanding the modern enterprise. These

include business process modeling, object-oriented technologies, knowledge management, and data warehousing.

However, none of these individual tools or technologies adequately addresses the enterprise as a whole. Each isonly effective in dealing with its little piece of the Enterprise Architecture puzzle. To complicate matters, the pieces

do not fit together. Each of these tools or technologies, rather, addresses a discrete area of the enterprise, answering

a specific question from a specific perspective for a specific area, with little or no regard for understanding the

whole. Integrating the disparate technologies described above into a cohesive and useful description of the

enterprise is the goal of an Enterprise Architecture.


6/45


7/45


3

The Popkin ProcessThePopkin Processis a set of scenarios for using the Enterprise Architecture Framework described above. The

Popkin Enterprise Architecture Framework, a customized version of the framework, will serve as the basis for adiscussion of :

how to relate the cells in the framework,

how to use the framework to reveal the enterprise architecture,

how to choose tools and when to use them, and

how to produce the designs and deliverables necessary to achieve the goals of the business.


8/45


4

What is an Enterprise Architecture?An enterprise, as defined by Mary Johnson and Larry Whitman of the University of Texas Automation & Robotics

Institute, is a complex system of cultural, process and technology components engineered to accomplish

organizational goals.

John A. Zachman defines Enterprise Architecture as:

the set of descriptive representations (i.e., models) that are relevant fordescribing an Enterprise such that it can be produced to managementsrequirements (quality) and maintained over the period of its useful life (changed).

Notice that there is no minimum or maximum size, no requirement that the components be all within the same

organization or that the enterprise be an entire organization. In fact, the first challenge of Enterprise Architecture is

to establish the boundaries of the enterprise, a concept dealt with in more depth later.

The use of the word architectureis significant. Thoughts and theories about Enterprise Architecture do have theirroots in traditional architecture and manufacturing disciplines. Plus, the correlation between complex business

systems (enterprises) and complex physical systems (buildings, aircraft, etc) cannot be ignored.

To illustrate this, let us use a building analogy. In general, a building will have more than one type of user and be

expected to satisfy its various users requirements. Likewise, a business enterprise must interact with people coming

from various perspectives and meet their diverse expectations. Moreover, a building is composed of more than one

type of material and the material used will depend upon a number of environmental, structural, financial, and

aesthetic factors. The choice of materials will help to determine the final performance and cost of the building,

which must be taken into account as the building is planned. Similarly, a business is made up of many different

materials, including physical resources, financial means, location, personnel, and type of market. These

materials, too, must be taken into account when designing the business.

In order to construct a building to meet the needs of those who wanted it built, its users, the local construction codes,

and the like, the buildings planners must take a number of different perspectives into account. They must make

sure theses perspectives relate to and understand how they constrain one another.

The best way to understand what the building will look like and how to build it is to examine its architecture, which

includes not only the architects plans, but the builders plans, the work plans, the building owners requirements,

and the bill of materials. When you are working with plans, you also have the freedom to make changes without

destroying the building (knocking out a support column to build a new conference room, for instance.)

The correlation between a buildings architecture and an Enterprise Architecture is clear. An Enterprise

Architecture, taking all of the various points of view into consideration, makes it easy to see what your Enterprise

will be like and how you will create it. It also makes it possible to see when an enterprise is no longer capable of

meeting the demands placed on it, so that, as with a building that has exceeded its useful life, it can be razed. Plus,

an Enterprise Architecture allows you to make significant changes to a business without running the risk of

destroying it.

A well-defined Enterprise Architecture will include techniques such as: knowledge management, business

(re)engineering, data warehousing, and alignment of business and IT strategy all techniques crucial to the success

of an e-commerce venture. It is easy to see that an Enterprise Architecture can contain a great deal of information.

How do you make sense of all of it and decide how much of it to use and how? That is the role of an Enterprise

Architecture Framework.


9/45


5

Enterprise Architecture Framework

John A. Zachman, creator of the Zachman Framework, in his paper available at www.zifa.com, states:

The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive

representations of an Enterprise that are significant to the management of the Enterprise as well as to the

development of the Enterprises systems. It was derived from analogous structures that are found in the older

disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design

artifacts created over the process of designing and producing complex physical products (e.g. buildings or

airplanes.)

An Enterprise Architecture Framework is a generic classification scheme for design artifacts. It is intended to

enable the user to focus on selected aspects of the Enterprise without losing a sense of the contextual perspective. A

Framework divides the enormous amount of detail of an enterprise into manageable chunks.

It also helps to prevent the isolation of a single problem area from the other areas its change or elimination might

affect. Most business people can identify some event or business decision we have witnessed which served one area

of the enterprise well while causing untold havoc in another like Hercules lopping off one head of the Hydra only

to have two more heads sprout elsewhere. Since it is unlikely the decision-maker intended to do harm to the otherarea, it seems he or she made the decision either out of context or without knowledge of how the two areas were

interrelated. Using an Enterprise Architecture Framework helps to prevent these types of mistakes.

So just what is an Enterprise Architecture Framework? What goes into it? How do you use it? Take a look at the

graphic below from www.zifa.com. It provides a representation of the Zachman Framework, as defined by John A.

Zachman.


10/45

6

Figure 1 The Zachman Enterprise Architecture Framework


11/45


7

Focus and PerspectiveEach cell in the Zachman Enterprise Architecture Framework represents the intersection of a particular focus and a

perspective. Each focus (the question what, how, where, who, when, and why) is depicted in a column and each

perspective (point of view) in a row.

When you ask or answer a question, your point of view determines the kind of information contained in the answer.

It is the same with the perspectives in the Zachman Enterprise Architecture Framework. The perspective determines

the kind of information that will be recorded in a row and/or cell. 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 cant describe your network in a useful way without a perspective.1

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 Enterprises 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 Enterprises knowledge for the particular question being asked,

i.e., the focus. You build the total Enterprise knowledge for each focus by isolating each focus and defining the

artifacts for each perspective within it.

1Perspective is a term used in art. If you were asked to draw a mountain, would you draw it from the perspective or

point of view of a person looking up from below, down from above, or from somewhere on the mountain? Many

artists could draw the same mountain. However, each drawing would be the product of each artists perspective on

the subject.

Likewise, if asked to describe the mountain, an artist would likely give a different description than a mountain

climber or geologist. These differences result from the describers perspective. The describers field of expertise

and use of the mountain play a large part in how he or she would describe it.


12/45


8

Figure 2 View of the Enterprise from one Perspective


13/45


9

Figure 3 View of the Enterprise from One F ocus


14/45


10

As mentioned previously, the framework as defined by John Zachman is generic. In a later section we will revisit

the definitions of the rows and columns of the framework, as well as the content of the individual cells, from the

standpoint of their use in System Architect.


15/45


1111

Constraints and Requirements

By definition, the perspectives in the Framework act as constraints upon one another. These constraints tend to flow

from the top down. That is, within any given focus in the framework, the constraints (requirements) on an enterprise

accumulate from top to bottom. For example, the CEOs requirements constrain what the companys managers can

do. The managers requirements, in turn, constrain the line workers, and the line workers knowledge, skills and

abilities constrain what the Enterprise can produce.

Constraints can flow from the bottom up as well, though these tend to be less restrictive than those flowing from the

top down. The most likely source of a bottom-up constraint is technology. For example, in the What/Data focus a

relational database, which does not have the desired functionality, can constrain all of the perspectives above it.

Most business people can think of at least one example in which a software system has constrained an enterprise,

regardless of the business rules. Fortunately, newer and better technologies usually remove such constraints. For

instance, by making previously distributed or hard-to-find data readily available, data warehouses and data marts

have reduced the numbers of bottom-up constraints on enterprises.

To put it simply: each perspective places constraints on the Enterprise. These constraints are cumulative and

dependent on one another. Therefore, it is vital to make them explicit with an Enterprise Architecture.

Figure 4 Constraint Flow of the Framework


16/45


1212

Models, the Language of the Framework

Models are the language of the Framework. They provide an unambiguous way of representing enterprise

knowledge so that technical and non-technical people can understand and use it. The Framework provides a means

for organizing the models into useful categories.

Models are contained within the Framework Cells. How do we know if what we place in the cell is a model?

A model is a representation of concepts which:

can be validated,

can be checked for rigor & robustness,

captures and communicates ideas,

can be changed,

can provide scenarios (what if and where do I fit in?), and

has a defined set ofsyntaxandsemantics.

Conversely, a model is not:

merely a collection of drawings and documents anything that cant reflect the business changes

anything that cant derive the impact of change

anything that cant be navigated

The Imp ortance of Mo del ing Enterpr ises

Modeling is an expression of concepts which allows each part of an organization to understand and contribute to its

own evolution. Models only become meaningful to the Enterprise when they cause action and provoke thought, and

that only happens when all parts of an organization work together to create something rich enough for all to use.

Models also promote understanding across different business groups in an organization. A good model can

communicate much of a company's purpose to stakeholders in the business, whether they are employees,

shareholders, or customers. Modeling can (and, as we will see, should) be applied to all stages of business and

systems development.

Although there are many types of models, those with which we are primarily concerned are graphical languages

used to communicate concepts. To be useful and generally understood, these languages should be formalized and

standardized by bodies such as the International Standards Organization (ISO), by industry use and practice, or byvendors.

There are multitudes of modeling methods available. Most of these methods are designed to serve a specific

purpose (modeling Object Oriented Systems, for instance) and are ill suited to perform outside their intended role

(e.g., modeling business processes). An Enterprise Model is composed of multiple modeling methods integrated in

a way that is sufficient to describe the Enterprise.

This brings us back to John A. Zachmans definition of an Enterprise Architecture, a set of descriptive

representations (e.g., models) which are relevant for describing an Enterprise such that it can be produced tomanagements requirements (quality) and maintained over the period of its useful life (changed). Enterprise

Modeling is the act of providing that set of descriptions.

In other words, the termsEnterprise ArchitectureandEnterprise Modelingwork together:

Enterprise Modeling is the act of building an Enterprise Architecture!


17/45


1313

Common Modeling Methods and how they Relate to the

FrameworkOf the plethora of modeling conventions and techniques, the popular methods generally employ several different

diagrams to fully explain the problem domain. Modeling methods tend to fall into one of four categories: Business

Process Models, Data Models, Object-Oriented Models, and Structured Models. This section will explore how each

of these maps into the Framework.

Bus iness Process Mode ls

Business Process Models have been around for some time. However, they have suffered from insufficient

standardization. The standards that have existed were largely formed before there were tools adequate to support

their dictates for diagramming, data storage, data retrieval and reporting. As a result, business process models wonthe reputation for being hard to use or time-consuming to produce.

Hammer and Champys book,Reengineering the Corporation,started a wave of interest in understanding and

fundamentally changing business processes. Business process models enjoyed a surge in use and popularity during

the hey days of Business Process Reengineering (BPR). Although those days are now over, business process models

still enjoy wide use and, fortunately, wider standardization and more robust tool support.

How Business Process Models fit into the FrameworkStrictly speaking, if one takes the term at face value, business process models really do not cover much of the

Framework at all. This is true whether the methods chosen are formalized and rigorous or not. However, this strict

interpretation of the term business process models has very little utility: it takes an overly narrow and isolated

view of a business process.

Figure 5 Literal View of Business Process Models

How should the termBusiness Processbe viewed then? It is, unfortunately, an overloaded term. Business Process

certainly applies to the Enterprise/Howcell of the Framework but it describes concepts at a much higher level of

abstraction, as well. For the sake of this discussion, we will call these higher-level concepts, Core Business


18/45


1414

Processes. An example of a Core Business Process is Select Product or Services. Core Business Processes exist

one level higher on the Framework (at the Scope level.)

As indicated above, to get a complete picture of the Enterprise from a single perspective requires the use of all cells

within that row (perspective.) That being the case, both rows one and two (the Scope and Enterprise perspectives)

of the framework should be utilized to build a complete architecture of the business processes (and all related

information.)

Figure 6 Complete Business Process Model Architecture

One of the more prevalent uses of the methods categorized as Business Process Models is for business

engineering. Business engineering describes a process of designing and building ones business and, as the name

implies, uses engineering principles. Engineering disciplines employ design rules and design artifacts to promote a

systematic approach to the design process. (One does not just add a room to a skyscraper without first consulting

the blueprints, wiring the room for power, having a use for the room, etc.) Similarly, business engineering takes asystematic approach to building the business. Because of this approach, the information (set of artifacts) to be used

is much broader than the term business processwould imply.


19/45


1515

Data Models

Data Modeling is the most widely used and most generally understood of the modeling techniques. Because of the

wealth of documentation available on Data Modeling and its uses, we are not going to go into any detail about it

here. Data Models fit into the Framework entirely within the What Column. One important point is that the datamodels within the framework have a hierarchy of abstraction as follows (from bottom to top): List of Candidate

Entities, Conceptual Data Model, Logical Data Model, Physical Data Model, DDL, and, finally, the actual database.

Figure 7 Data Modeling is Used for the What Focus


20/45


1616

Struc tu red Mod e ling

Largely used in conjunction with Data Models, structured methods employ techniques that show how data flows

through and is manipulated by a system. Some structured methods also detail some real-time behavior of a system,

as well. Below is diagram showing how Structured Methods cover the Framework2.

Figure 8 Coverage of the Framework Using Structured Methods

2The author recognizes that Data Modeling is a part of any modern Structured Analysis and Design Method.

However, since structured methods employ the use of data models rather than introducing a new model for

specifying the artifacts in the Whatfocus, those cells are left blank in the diagram.


21/45


17

Object-Or iented Mo del ing

Quite a bit could be said here about Object-Oriented (OO) modeling, its history, its future, its successes and its

failures, but there are plenty of books available which do just that. For the purposes of this discussion, it is

important to focus on what OO is and what it is not from the standpoint of Enterprise Architecture and the

Framework.

For most of the history of OO, there have been many methods competing to be the singular way to model objects.

As a result, the OO community has been fractured into various factions, each supporting its favorite modeling

language. Now with the introduction of the Unified Modeling Language (UML), OO practitioners and purveyors of

OO tools and technology have been united behind a single language, if not a single methodology.

What is accomplished by the OO paradigm is that the dataand how to manipulate the data are combined

(encapsulated) into a single representation (an Object or Class). Additionally, UML defines diagrams that deal with

the distribution and timing of the system. By combining multiple, related, diagram types, UML does address many

aspects of a system. The key words here are many (not all) and system (not business or enterprise.) The

diagram below shows how the UML, the language we will deal with when referring to OO in the remainder of the

text, covers the Framework UML.

A few things to note about the diagram below:

UML covers a lot of cells in what can be the software system part of the framework (rows 3, 4, and 5).

UML (without extensions) does not address any of the row 1 and 2 cells. It simply is not useful for businessengineering it is a systems-focused method.

The three dark-shaded cells indicate areas where UML has defined extensions to address these areas (Business

Process Modeling and Data Modeling.) The System/Data cell is left explicit since UML does a fine job of

modeling logical data.

Figure 9 Coverage of the Framework by the UML


22/45


18

Model TransformationsIf models are the language used to build an Enterprise Architecture, then it would be helpful to have some

systematic ways to transform the information in one cell into the next cell in the same column. At a minimum, we

would like to have a starting point for the next cell as we move downward in the Framework. The old concept tocode idea is an embodiment of this process. But, for it to work correctly, you have to have a defined and controlled

set of transformations. This is where the Framework becomes invaluable.

Using the Framework, it is possible to assign the information about an enterprise (the models) into a cel l and then

define transformations that make logical sense. What do we mean by logical sense? It would make logical sense

to transform the logical data model of the System/What cell into the preliminary Physical Data Model of the

Technology Model/What cell, but it would notmake logical sense to transform business objectives into business

locations. That would be like expecting the explanation of why someone does something to include how he or she

does it. The basic questions of what, how, where, who, when, and why are discrete.

If the models of the enterprise have been built using a repository-based modeling tool such as System Architect,

then the information is already stored in a single location. Transformation routines or utilities are needed toturn it from one thing into another.

Transformations of information occur between cells in the same focus when you move across perspectives. That is,information about the enterprise may be transformed from one perspective to another as long as it remains in the

same focus. You cannot transform information diagonally in the Framework from, say, the Scope/What cell, to the

Enterprise Model/How Cell. To understand this better, think about the cell content as answering the basic

questions of the focus, Who, What, Why, When, Where and How. The answer to a question of how something is

done does not transform into the answer of who does it. Naturally, there are instances where one of these may lead

the knowledgeable listener to infer the other but such resource dependency in an enterprise is risky, a risk an

Enterprise Architecture helps to identify.

Transformations between cells must also occur between adjacent cells. This means that magic such as the

conversion of a business process flow diagram into a running system does not occur without the work involved in

the other rows and columns necessary to construct a running system. Someone has to do the work. Either you have

to do it or you have to buy someone elses work.

The following transformation guidelines will be used later when describing the processes for using the Popkin

Enterprise Architecture Framework.

Panel 1 Panel 2 Panel 3

Panel1: Transformation of cell information is possible between adjacent cells in the same focus.

Panel2: Skipping a cell in the transformation requires magic and guess work to get it right.Panel3: Transformations are similar to alchemy.

Figure 10 Invalid Transformations


23/45


19

Model Hierarchy within the Framework CellsThe Information (models) in a specific cell of the Framework may be related to one another in a hierarchy while

remaining completely within the cell. For instance, in the Enterprise Model Perspective and How Cell are what are

commonly referred to as business process models. Business process models, however, come in a variety of flavors

(e.g., Function Models, Process Flows, Functional Hierarchy, etc.). These models may be related to one another in a

way where one adds value and information to the other, while still fitting the criteria that has them living as a part of

the same cell. In theory, each cell may contain an Enterprise Architecture Framework. This nesting of Frameworks

within cells may be infinite. This discussion is beyond the scope of this text. We will, however, make use of the

concept shown in the diagram below as we map the capabilities of System Architect into the Zachman

Framework in the following section and then describe a process (or scenario) of use of the resultingPopkin

Enterprise Architecture Framework. The scenarios of use of thePopkin Enterprise Architecture Framework(howto apply the framework to specific problems or projects) are what will collectively be called thePopkin Process.

Figure 11 Cell Models Divided into Levels of Abstraction


24/45


20

Guidelines for Using an Enterprise Architecture FrameworkThe preceding sections have covered what an Enterprise Architecture Framework is, how it works, and how the

various types of modeling come into play within a Framework. Before discussing the Popkin Enterprise Architecture

Framework, it is useful to take a look at some general guidelines for working with an Enterprise ArchitectureFramework.

An Enterprise Architecture Framework may be used in whole or in part, observing the following rules:

The focuses may be in any order.

You may use any subset of the focus questions, as suit the needs of your project.

You may use a subset of the perspectives as long as the set chosen is immediately adjacent; to do otherwiseimplies a truly magical transformation of information. Most software users have experienced or heard about the

magic that has to occur to deliver a software system by doing nothing more than listening to a verbal description

of the desired system and then having a finished product. Works well right?

All rows, columns and cells are always present in the framework, though the architect may have left themimplicit.

If you are going to make a cell of the framework explicit, have good reasons for doing so: there is work

involved in properly documenting the necessary material to fulfill the promise of the cell in the architecture. If you are going to leave a cell implicit, have a very good reason for doing so. Not building the models for a

cell means making the decision to take a certain amount of risk3. Not filling in the cell means that you assume

the information is not relevant (it is), not known (educational in itself to realize what is unknown in your

enterprise isnt it?), or not understood. An Enterprise Architecture Framework is an invaluable tool for

knowledge management4 assuming the knowledge is captured. Leaving a cell implicit means that information

about that part of the Enterprise is not integrated into the Enterprise Knowledge Architecture.

3Risk Management using the framework will be addressed in a later release of this paper.

4Knowledge Management as a discipline and how it relates to the Framework is written about in several of John

Zachmans papers and will be handled here in later releases of this paper.


25/45


21

Summary of the Zachman FrameworkThe Framework is a mechanism for relating enterprise knowledge in a useful and relevant way. It helps to ensure

the creation of a more robust enterprise. From the perspective of IT and IS, the framework is a tool which makes

sure the technology solutions delivered to the business are relevant. It also is a tool that provides a means fordesigning the solutions by integrating the technical design with the stated business requirements.

For the business manager, the Framework is a tool that helps him to understand the workings and interrelations of all

aspects of the business (information, communication, processes, people, motivation, etc.) It also helps him align IT

strategies with business strategies.

All the cells in the total framework represent the total knowledge base of the Enterprise. Zachman summarizes the

Framework as:

a. SIMPLE: It is easy to understand ... not technical, purely logical.b. COMPREHENSIVE: It addresses the Enterprise in its entirety. Any issues can be mapped against it to

understand where they fit within the context of the Enterprise as a whole.c. A LANGUAGE: It helps you think about complex concepts and communicate them precisely with

few, non-technical words.

d. A PLANNING TOOL: It improves your decision making, as you are never making choices in avacuum. You can position issues in the context of the Enterprise and see a total range of alternatives.

e. A PROBLEM-SOLVING TOOL: It enables you to work with abstractions, to simplify, and to isolate

simple variables without losing sense of the complexity of the Enterprise as a whole.

f. NEUTRAL: It is defined totally independently of tools or methodologies and therefore any tool or anymethodology can be mapped against it to understand its implicit trade-offs ... That is, what they are

doing, and what they are NOT doing.

The Framework for Enterprise Architecture is not "the answer." It is a tool ... a tool for thinking. If it is employed

with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the

complexities and dynamics of the Information Age Enterprise.


26/45


22

The Popkin Enterprise Architecture FrameworkSo, what does all the previous discussion about Architecture, Frameworks, and models have to do with System

Architect?

System Architect (SA) is a modeling tool. Whats more, SA is a very robust, repository-based

modeling tool which supports Business Modeling, Data Modeling, Structured Modeling, and Object-Oriented

Modeling. SA combines support for the various types of modeling with additional functionality for

transformation of information between cells. It also enables you to add definitions to the repository in order to

collect information relating to the Motivation column. With this functionality, SA is a natural tool for

Enterprise Architecture.


27/45


23

Figure 12 System Architects Support for Enterprise Architecture


28/45


2424

The table below maps the appropriate diagrams and definitions from System Architect into the Zachman

Framework. This mapping can be used as a sort of pick-list when deciding what tools to use from System Architect

in order to achieve the desired outcome of a particular project.

The following conventions apply to the mapping:

1. Row 1 contains definitions. These definitions are not an exhaustive list. They are meant to be indicative of the

types of definitions within System Architect, which would apply in the cell. .

2. Rows 2, 3, and 4 contain diagrams. Not all diagrams are represented. All non-UML OO diagrams areexcluded, as are SSADM diagrams. All other diagrams are included.

3. Row 5 contains code or other products generated by System Architect for that cell.4. Row 6 represents a running enterprise, database, program, etc.5. Data Flow means all Data Flow diagrams except Ward & Mellor, which is handled specifically.

6. Names in italics indicate diagrams that are present in more than one cell within a row. This would indicate adiagram that could adequately answer the questions posed by more than one focus within a row.


29/45


2525

Figure 13 Popkin Enterprise Architecture Framework


30/45


2626

Framework Uses

Note that the framework can be used to determine:

a) How big or small the project is or should be and, therefore, what artifacts need to be created using SystemArchitect,

b) Based on (a), what information is necessary for a complete model,

c) What information can be cross-referenced (See the Focus Cross-Reference sheet in the Tools for EnterpriseArchitecture Section), and

d) What tools can be used and products produced (using the tools and deliverables sheet in the Tools for EnterpriseArchitecture Section).


31/45


2727

The Popkin Process: A Set of Pre-defined Uses of theFrameworkAn organization can take on a wide variety of projects and the Enterprise Architecture Framework is very

comprehensive. So, it is useful to define projects or project types to address with the framework. By doing so you

will define subsets of the Framework which are relevant for those projects. You will also be defining a set ofdeliverables and a process for producing them.

The role of the process, and the Popkin Process in particular, is to define the appropriate subsets for a given project

or problem domain and to determine how to apply the tools and techniques contained in the cell to meet a specific

need. ThePopkin Processis actually a set of pre-defined uses (or scenarios) of an Enterprise Architecture

Framework to accomplish specific goals. These scenarios are presented along with the corresponding sub-set of the

Framework and the appropriate models to use within each cell. There is also a Process Chart diagram showing how

the models are built and their relation to oneanother5.

Scenar io 1: Bu siness Process Dr iven OO Development

ContextWhen you need to model an existing process with the intent of building a software system to support it, you workwith this scenario. You do not attempt to reengineer or improve processes at this point. You simply focus on

documenting business processes and identifying business requirements. Based on the understanding of the business

process, you can design an application to support it. The business process and, therefore, the resulting application

are assumed to be small scale (fitting wholly within one department or organizational unit). You should use a

different scenario if you need a larger scale application requiring the interaction of several departments or

organizational units.

PurposeYou use the Scope and Enterprise Level to understand the business needs and requirements of the application. The

Scope and Enterprise Level assumes a development effort at a certain level.

Between the time when you start the effort and when you finish modeling the business process and requirements, the

scope can change. You should understand and allow for this. At some point such a change in scope even becomesprobable, forcing you to adjust your original expectations. This is a much more acceptable (and less expensive) form

ofscope creep than having it occur when the development project is already underway or in its final stages.6

Pre-ConditionsYou have identified a need for a new system to support an existing business process. Someone in your organization

has decided to take an Object Oriented approach to developing the application, and, after some investigation into

available methods, has designated UML as the analysis and design method.

Post-ConditionsApplication supporting the defined business process.Models of the business process and application design.

5For information about the syntax of a Process Chart diagram see Appendix A.

6An additional reason to model the business level information is to get a clear understanding of the environment in

which the application will be used and to get a clear set of system requirements before starting the development

effort. For this reason it is the position of this paper that there is no justifiable scenario resulting in the development

of a software system that will not include information in some form in the How and Why column


32/45


2828

Explicit CellsShown in diagram below.

Implicit Cells and Focus:

What Represents the existing application and/or database in a format which can be read by SA. Thedatabase contains the business information on which the application will operate. Identification of Whatat

Scope and Enterpriselevel is unnecessary since scope of application is not intended to change

Where- is known and fixed. It is implicit within this context

Who- is known and fixed at all levels. However, it is useful to model from an application standpoint.

When dynamic behavior of system is not sufficiently complex as to warrant modeling.

How is the high level focus. Map existing process to gain an understanding of the context (business process)within which the application will be used and how it will be used.

Below is a Framework and Diagram showing the Process Flow of a small project for building a business process-

driven Object Oriented system. In other words, the system is driven by business needs and those business needs,

processes and requirements are documented and used to drive the design and development of the resulting system.

Note: Diagrams in Italics are optional. The arrows and the diagrams in the System Model/Whatcell represent a

scenario variation path.


33/45


2929

Figure 14 Framework showing the Process Flow of a Small OO project.


34/45


3030

Figure 15 Diagram showing the Process Flow of a Small OO Project.


35/45


3131

Tools for Enterprise Architecture

System Archi tect Tools for Bui ld ing and Del iver ing an Enterpr ise Arch i tecture

The Popkin Enterprise Architecture Tools and Deliverables table shows the tools to use in and deliverables produced

from System Architec to aid in the production of the models for an Enterprise Architecture. The tools anddeliverables are assigned to the proper perspective (Framework Row) in which they would be used or produced.

The tools are divided into various types based on how they would be used: analysis and verification, reporting andpublication, export and implementation, and Import.

The Popkin Framework - Focus Cross Reference table indicates where matrices exist, out of the box, within System

Architect to allow the assignment and viewing of relationships between cell definitions.


36/45

u ng an nterprse rc tec ture: e op n roc

Figure 16 Popkin Enterprise Framework Tools and Deliverables


37/45


33

Figure 17 Popkin Enterprise Framework Focus Cross Reference


38/45


3434

Tools for Enterprise Analysis

There are two basic tools available for analyzing your enterprise in System Architect: Activity Based Costing

and Simulation.

Act iv i ty Based Cost ingTraditional accounting approaches collect and report costs by assigning the costs of resources to products. The main

premise behind traditional approaches is that products cause costs. Under this assumption direct resource costs areassigned and allocated directly to products. This approach may or may not reflect actual resource usage because the

focus is more on what was achieved rather than how it was achieved.

Activity Based Costing (ABC) introduces activities as an intermediary for assigning costs to products. ABC is

based on the premise that activities cause costs through the consumption of resources and that the demands for

products cause these activities to be performed. This approach gives insight into how effectively and efficiently

resources are used and how activities in the enterprise contribute to the cost of the business.

For the purposes of Activity Based Costing, and, in fact , of general usefulness when analyzing business Processes,

activities in the Enterprise will be modeled using a hierarchy. Activities are identified and related into ever

decreasing levels of abstraction.

To illustrate, the following diagram shows a portion of an activity model for a widget manufacturing Enterprise.The top-most activity is the most abstract. It, in turn, breaks down into more (less abstract) detail and the activities

in the first breakdown themselves down or decompose into smaller, less abstract activities. Eventually all known (or

cared about) levels of activities are depicted. The lowest-level activities are referred to as leaf level activities. The

leaf-level activities are where you can collect and assign the most accurate cost information. Total activity cost (at

each level in the hierarchy) can be determined by summing the costs of the child activities. In this way the total cost

for Manufacture Widgets can be determined from an analysis of the lowest level activities in the hierarchy.


39/45


3535

There are two methods of assigning costs to an activity, tracing and allocation. Both are valid devices for

determining activity costs. However, your choice of which to use must be determined by what cost information isavailable and how much time, energy, and expense you can incur to perform the ABC analysis.

TracingTracing involves the assignment of specific, detailed resource costs directly to an activity each time it occurs.

Tracing assumes that detailed cost information for an activity is available or accessible or can be collected in a cost-effective way. Tracing is by nature more time- and resource-intensive and more costly. If you plan to use tracing as

the method of assigning costs for Activity Based Costing you should be certain the additional costs of doing so are

warranted. Also, Tracing is more naturally suited for deterministic processes such as manufacturing or document

flow. Many high-level business processes do not lend themselves to tracing. To summarize the benefits and

drawbacks to tracing:

Assigning Costs Through TracingBenefits DrawbacksMore accurate than allocation More costly than allocationDirectly links cause and effect More time consuming than allocation

Well suited for deterministic processes Requires existence or acquisition of detailed costdataWell suited for process optimization, especiallylow margin processes.

Tracing requires a great deal of detail and deals with each activity as a discrete event to which resources and,

therefore, costs can be allocated. Because of the intensely detailed nature of this method of cost assignment for

ABC the best tools for this type of analysis are simulation tools. System Architect supports tracing by

bridging into Simprocess from CACI Product Company. Simprocess is a discrete-event- simulation system

specifically built to simulate business processes. It has Activity Based Costing analysis built-in.

AllocationAllocation is a method of cost assignment that is more subjective and more flexible than tracing. You can allocate

costs, i.e., collect them into cost centers (usually organizational units), when you do not have or cannot determine in

a cost-effective way a direct allocation of cost. Once you have collected them in cost centers, you can use cost

drivers to pull costs from the cost centers (in the form of estimated amounts or percentages) and assign them to theactivities needing that cost centers services and/or resources. The following table explains:

Cost Center Activity 1 Activity 2 Activity 3

Cost Center 1 Driver 1.1 Driver 2.1Cost Center 2 Driver 2.2

Cost Center 3 Driver 1.3 Driver 3.3

Drivers often are themselves activities (such as setup or rework), but of a sufficiently detailed nature as to be

uninteresting to depict in the activity model. If the activity model has been built to the most detailed level, drivers

may simply have placeholder names such as those above.


40/45


3636

Drivers contain information about:

The cost to be pulled from the cost center,

The cost center from which it is pulled, and

The frequency at which it is pulled at each occurrence of the activity or only once during a defined set ofoccurrences.

Driver detail is determined via interviews and/or observation.

In System Architect, this information is collected into the Cost Driver Definition and appears as follows:

Drivers are assembled into cost pools which are little more than a list of the drivers for an activity and are

represented above as the information in a column below an activity.

Assigning Costs Through Tracing

Benefits Drawbacks

Easy to learn and use Less accurate than tracingLess costly to implement than tracing Not detailed enough to simulate

Does not require detailed information or extremely

detailed models

Not suited for detailed processes where the amount

of money or the margin is very smallWell suited for process (re) engineering

System Architect supports allocation as the means of associating costs to activities. ABC capability is built-in

and is utilized by two different diagram types: IDEF0 and Process Chart.

IDEF0: This diagram type utilizes decreasing levels of abstraction (as in the diagram above) to facilitate the activity

modeling process. Activities are identified and decomposed into lower and lower levels. Costs are assigned (per the

above) when sufficiently low-level (or leaf level) activities are discovered. . Once they are assigned to these leaf-

level activities, the costs are summed up for each activity. Then, the sums are totaled and rolled up level by level to

the top activity. If the driver is set to be variable, System Architect uses activity frequency as a multiplier for

the cost of the driver.

Process Chart: This diagram type does not require the use of abstraction for activity analysis. Rather, the activity islaid out as an end-to-end process flow which may all exist on a single level of abstraction. Costs for an activity

(Elementary Business Process in terms of that method) are summed up and displayed. The frequency multiplier is

used as described above.

Simula t ion

Process Simulation is the technique which allows representation of processes, people, and technology in a dynamiccomputer model. A model, when simulated, mimics the operations of the business. This is accomplished by

stepping through the events in compressed time while displaying an animated picture of the flow. Because

simulation software keeps track of statistics about model elements, performance metrics can be evaluated by

analyzing the model output data. Like Activity Based Costing, process simulation embodies the concept that a

business is a series of inter-related processes, and that these processes consist of activities which convert inputs to

outputs. The process simulation approach manifests this concept and builds on it by organizing and analyzing costinformation on an activity basis.

Re-engineering gurus, Michael Hammer and James Champy, note in their book that only about 30 percent of the re-

engineering projects they have seen were successful. One of the primary reasons for this low success rate is that

more often than not the analyses behind performance estimates of re-engineered processes have been prepared with

flowcharts and spreadsheets, modeling media which cannot capture the complexity and dynamism of business

processes.

The reliance on flowcharts and spreadsheets has resulted in the overly optimistic predictions of performance

benefits, promised by Business Process Reengineering (such as cost savings and throughput and service level

increases).


41/45


3737

Procedure fo r Bus iness Process Mode l ing and An a lys is

Step #1. Create A Process ModelTo create a process model, you start with mapping the business processes. Then, you drill-down into the processes

where sub-processes are defined. Describing the objects that flow through the processes and linking the processes

using connectors facilitates the workflow definition. Finally, you define the resources and assign them to the

activities where they are used.

Step #2. Simulate The ProcessBefore simulating a model, you need to select the performance measures of interest. Most simulation tools

automatically generate cycle time, entity count, resource utilization and cost reports. More sophisticated tools allow

you to generate custom reports for tracking service levels or in-process inventory. For example, you may be

interested in throughput and cycle time reports for entities, activity costs for processes, and utilization report

resources. When you run a simulation, the process simulation tool automatically verifies your model and begins

advancing the simulation clock. During the simulation, you see an animated picture of the flow that helps you

visualize the process in motion. You can also have process simulation generate real-time graphs, letting you view

key performance measures, during the simulation.

Step #3. Analyze the Results

When the simulation is over, you can bring up the model results and analyze the performance measures of interest.To draw useful and correct conclusions from simulation results requires statistical input and output data analysis.Knowing which distribution to use for representing activity times or how many data points to collect is important in

developing a statistically valid model. And, knowing how long to simulate a process or how many replications to

run becomes significant for producing valid and accurate results.

Step #4. Evaluate AlternativesThe strength of process simulation is in its ability to incorporate stochastic (i.e. conjectural) situations in the model.

It cannot offer an optimum solution. In order to find the best solution, one has to determine various scenarios and

simulate them. This is where Design of Experiments can aid in searching and finding the best solution. With the aidof Design of Experiments, one can also compare the performance measures from Current State with measures from

Future State alternatives.

System Arc hi tect and Simulat ion

System Architect's Simulation engine enables you to simulate two different diagram types, the

Process Chart and the IDEF3 Process Flow diagram. Either of these diagrams is used to depict a

chronological sequence of events and decision logic for a business process or work flow. The information

represented in these diagrams can be simulated to find potential bottlenecks. Before running simulation, you

fill out certain simulation information properties within the definitions of the model objects and flow lines.

You may also specify properties of the simulation itself, such as how many hours are in a typical work day,

how many times the simulation itself should iterate, and what graphs to produce.


42/45


3838

Conclusion

John Zachman provides a comment on the Framework and the models within the Framework that is worth

mentioning here:

Someday you are going to wish you had all those models, Enterprise wide, horizontally and vertically integrated atan excruciating level of detail.


43/45


3939

Appendix A

The Process Chart Diagram was chosen to depict the process flows in thePopkin Processscenarios. A Process

Chart makes explicit the initiating conditions of the scenario, the tasks to be done and in what perspective, the order

of the tasks, and the expected results. Below is a description of the Process Chart diagram.

Process Chart Diagram

The Process Chart diagram expresses a process in terms of initiating events or triggers, a set of tasks performed in a

defined sequence, in what perspective each task is done, and one or more results. This is done through the use of the

symbols defined below.

Definition of Process Chart Symbols

Event: Right pointing arrows represent the initiating events or triggers which set the process in motion

Elementary Business Process: Boxes represent units of work. These may be decomposed (broken down) into

smaller units on another Process Chart diagram. The Child Diagram will be attached to the box it decomposes.

Result: Left Pointing Arrows represent results of the work performed.


44/45


4040

Mandatory Sequence: Lines with solid arrowheads represent mandatory sequences, or a mandatory path for the

process flow

Optional Sequence: Lines with open arrowheads represent optional paths.

Optional Variation: This line is not a part of the official definition of a process chart but is used in the scenario

diagrams to show a variation in the process (Scenario Variation) which can be taken if the indicated conditions aremet.

Iteration: Represents a do-until condition in the process.

Swim Lane: The Horizontal Lanes (shown shaded) represent thePerspective responsible for the tasks shown withinthat Lane.


45/45


References

1. Appleton, Daniel S. Principles of Business Engineering. Talon Press, 1994. [ISBN 0-9642954-0-7]

2. Bahrami, Ali. Object Oriented Systems Development. New York: McGraw-Hill 1999. [ISBN 0-256-25348-X]3. Brimson,James A. Activity Accounting. New York: John Wiley & Sons, 1991. [ISBN 0-471-53985-6]4. Cook, Melissa A. Building Enterprise Information ArchitecturesNew York: Prentice Hall, 1996. [ISBN 0-13-

440256-1]

5. Davenport, Tomas H and Laurence Prusak. Working Knowledge., Cambridge: Harvard Business School Press,1998. [ISBN 0-87584-655-6]

6. Hammer, Michael and James Champy. Reengineering the Corporation. New York: HarperCollins Publishers,Inc., 1993. [ISBN 0-88730-640-3]

7. Johnson, Mary and Larry Whitman. Enterprise Engineering: A Discipline for Integrating People, Processes

and Technologies in the knowledge Era.,Business Process and Knowledge Management Conference, 1998.

8. Kaplan, Robert S. and David P. Norton. The Balanced Scorecard. Cambridge: Harvard Business SchoolPress, 1996.[ ISBN 0-87584-651-3]

9. Rummler, Geary A. and Alan P. Brache. Improving Performance. San Francisco: Jossey-Bass Publishers,1995. [ISBN 0-7879-0090-7]

10. Sowa, J.F and J. A. Zachman. Extending and Formalizing the Framework for Information Systems

Architecture.IBM Systems Journal31, (No. 3, 1992)11. Spewak, Steven H. with Steven C. Hill. Enterprise Architecture Planning. New York: John Wiley & Sons.

[ISBN 0-471-599859]

12. Whitten, Jeffery L. and Lonnie D. Bentley. Systems Analysis and Design Methods, 4thEd. (Instructors Edition)New York: McGraw-Hill, 1998. [ISBN 0-256-19906-X (student edition), ISBN 0-256-23826-X]

13. Womack, James P. and Daniel T. Jones. Lean Thinking. New York: Simon & Schuster, 1996. [ISBN 0-684-

81035-2]

14. Zachman, John A. A Framework for Information Systems Architecture. IBM Systems Journal26 (No. 3,1987) [IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.]

Documents

Zachman - Popkin Process - Building an Enterprise Architecture