Table of Contents

Contents
Forewordi
Introduction...ii
Integrating Technologies with Enterprise Architectures .. 1
What is an Enterprise Architecture Framework?.. 2
The Popkin Process... 3
Enterprise Architecture.. 4
Enterprise Architecture Framework... 5
Focus and Perspective 7
Constraints and Requirements ..... 11
Models, the Language of the Framework ... 12
Common Modeling Methods and How They Relate to the Framework . 13
Model Transformations 18
Model Hierarchy within the Framework Cells 19
Guidelines for Using an Enterprise Architecture Framework . 20
Summary.. 21
The Popkin Enterprise Architecture Framework 22
The Popkin Process: A Set of Pre-defined Uses of the Framework ... 27
Tools for Enterprise Architecture ... 31
Tools for Enterprise Analysis . 34
Conclusion.. 38
Appendix A. 39
References... 41
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 new
technology. 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 implementation. 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
Building an Enterprise Architecture: The Popkin Process
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 business
survival.
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. Business
leaders 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.
Building an Enterprise Architecture: The Popkin Process
1
Integrating Technologies with Enterprise Architectures
Much 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 is
only 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.
Building an Enterprise Architecture: The Popkin Process
2
An Enterprise Architecture Framework
The role of an Enterprise Architecture Framework, on the other hand, is to provide a logical structure for classifying
and organizing the descriptive representations of an enterprise. The Popkin Enterprise Architecture Framework is
based upon the Zachman Enterprise Architecture Framework but uses the diagrams and definitions of Popkin
Softwares Enterprise Modeling tool, System Architect. Combining Business, Object, Process, and Data
Modeling capabilities into a single product with a single repository, System Architect is the modeling tool for
the entire enterprise.
Building an Enterprise Architecture: The Popkin Process
3
The Popkin Process
The Popkin Process is 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 a
discussion 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.
Building an Enterprise Architecture: The Popkin Process
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 for
describing an Enterprise such that it can be produced to managements
requirements (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 architecture is significant. Thoughts and theories about Enterprise Architecture do have their
roots 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.
Building an Enterprise Architecture: The Popkin Process
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 other
area, 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.
6
Figure 1 The Zachman Enterprise Architecture Framework
Building an Enterprise Architecture: The Popkin Process
7
Focus and Perspective
Each 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.

1
Perspective 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.
Building an Enterprise Architecture: The Popkin Process
8
Figure 2 View of the Enterprise from one Perspective
Building an Enterprise Architecture: The Popkin Process
9
Figure 3 View of the Enterprise from One Focus
Building an Enterprise Architecture: The Popkin Process
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.
Building an Enterprise Architecture: The Popkin Process
11 11
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
Building an Enterprise Architecture: The Popkin Process
12 12
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 of syntax and semantics.
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 Importance of Modeling Enterprises
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 by
vendors.
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 to
managements 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 terms Enterprise Architecture and Enterprise Modeling work together:
Enterprise Modeling is the act of building an Enterprise Architecture!
Building an Enterprise Architecture: The Popkin Process
13 13
Common Modeling Methods and how they Relate to the
Framework
Of 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.
Business Process Models
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 won
the 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 Framework
Strictly 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 term Business Process be viewed then? It is, unfortunately, an overloaded term. Business Process
certainly applies to the Enterprise/How cell 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
Building an Enterprise Architecture: The Popkin Process
14 14
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 a
systematic approach to building the business. Because of this approach, the information (set of artifacts) to be used
is much broader than the term business process would imply.
Building an Enterprise Architecture: The Popkin Process
15 15
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 data
models 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
Building an Enterprise Architecture: The Popkin Process
16 16
Structured Modeling
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 Framework
2
.
Figure 8 Coverage of the Framework Using Structured Methods

2
The 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 What focus, those cells are left blank in the diagram.
Building an Enterprise Architecture: The Popkin Process
17
Object-Oriented Modeling
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 data and 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 business
engineering 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
Building an Enterprise Architecture: The Popkin Process
18
Model Transformations
If 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 to
code 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 cell 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 not make 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 to
turn 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
Panel 1: Transformation of cell information is possible between adjacent cells in the same focus.
Panel 2: Skipping a cell in the transformation requires magic and guess work to get it right.
Panel 3: Transformations are similar to alchemy.
Figure 10 Invalid Transformations
Building an Enterprise Architecture: The Popkin Process
19
Model Hierarchy within the Framework Cells
The 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 resulting Popkin
Enterprise Architecture Framework. The scenarios of use of the Popkin Enterprise Architecture Framework (how
to apply the framework to specific problems or projects) are what will collectively be called the Popkin Process.
Figure 11 Cell Models Divided into Levels of Abstraction
Building an Enterprise Architecture: The Popkin Process
20
Guidelines for Using an Enterprise Architecture Framework
The 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 Architecture
Framework.
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 otherwise
implies 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 them
implicit.
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 risk
3
. 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 management
4
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.

3
Risk Management using the framework will be addressed in a later release of this paper.
4
Knowledge 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.
Building an Enterprise Architecture: The Popkin Process
21
Summary of the Zachman Framework
The 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 for
designing 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 a
vacuum. 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 any
methodology 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.
Building an Enterprise Architecture: The Popkin Process
22
The Popkin Enterprise Architecture Framework
So, 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.
Building an Enterprise Architecture: The Popkin Process
23
Figure 12 System Architects Support for Enterprise Architecture
Building an Enterprise Architecture: The Popkin Process
24 24
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 are
excluded, 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 a
diagram that could adequately answer the questions posed by more than one focus within a row.
Building an Enterprise Architecture: The Popkin Process
25 25
Figure 13 Popkin Enterprise Architecture Framework
Building an Enterprise Architecture: The Popkin Process
26 26
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 System
Architect,
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 Enterprise
Architecture Section), and
d) What tools can be used and products produced (using the tools and deliverables sheet in the Tools for Enterprise
Architecture Section).
Building an Enterprise Architecture: The Popkin Process
27 27
The Popkin Process: A Set of Pre-defined Uses of the
Framework
An 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 of
deliverables 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. The Popkin Process is 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 one another
5
.
Scenario 1: Business Process Driven OO Development
Context
When you need to model an existing process with the intent of building a software system to support it, you work
with 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.
Purpose
You 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 becomes
probable, forcing you to adjust your original expectations. This is a much more acceptable (and less expensive) form
of scope creep than having it occur when the development project is already underway or in its final stages.
6
Pre-Conditions
You 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-Conditions
Application supporting the defined business process.
Models of the business process and application design.

5
For information about the syntax of a Process Chart diagram see Appendix A.
6
An 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
Building an Enterprise Architecture: The Popkin Process
28 28
Explicit Cells
Shown in diagram below.
Implicit Cells and Focus:
What Represents the existing application and/or database in a format which can be read by SA. The
database contains the business information on which the application will operate. Identification of What at
Scope and Enterprise level 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/What cell represent a
scenario variation path.
Building an Enterprise Architecture: The Popkin Process
29 29
Figure 14 Framework showing the Process Flow of a Small OO project.
Building an Enterprise Architecture: The Popkin Process
30 30
Figure 15 Diagram showing the Process Flow of a Small OO Project.
Building an Enterprise Architecture: The Popkin Process
31 31
Tools for Enterprise Architecture
System Architect Tools for Building and Delivering an Enterprise Architecture
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 and
deliverables 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 and
publication, 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.
Building an Enterprise Architecture: The Popkin Process
32 32
Figure 16 Popkin Enterprise Framework Tools and Deliverables
Building an Enterprise Architecture: The Popkin Process
33
Figure 17 Popkin Enterprise Framework Focus Cross Reference
Building an Enterprise Architecture: The Popkin Process
34 34
Tools for Enterprise Analysis
There are two basic tools available for analyzing your enterprise in System Architect: Activity Based Costing
and Simulation.
Activity Based Costing
Traditional 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 are
assigned 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.
Building an Enterprise Architecture: The Popkin Process
35 35
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 is
available and how much time, energy, and expense you can incur to perform the ABC analysis.
Tracing
Tracing 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 Tracing
Benefits Drawbacks
More accurate than allocation
More costly than allocation
Directly links cause and effect More time consuming than allocation
Well suited for deterministic processes Requires existence or acquisition of detailed cost
data
Well suited for process optimization, especially
low 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.
Allocation
Allocation 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 the
activities 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.1
Cost 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.
Building an Enterprise Architecture: The Popkin Process
36 36
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 of
occurrences.
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 tracing
Less 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 small
Well 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 is
laid 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.
Simulation
Process Simulation is the technique which allows representation of processes, people, and technology in a dynamic
computer 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 cost
information 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).
Building an Enterprise Architecture: The Popkin Process
37 37
Procedure for Business Process Modeling and Analysis
Step #1. Create A Process Model
To 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 Process
Before 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 Alternatives
The 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 aid
of Design of Experiments, one can also compare the performance measures from Current State with measures from
Future State alternatives.
System Architect and Simulation
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.
Building an Enterprise Architecture: The Popkin Process
38 38
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 at
an excruciating level of detail.
Building an Enterprise Architecture: The Popkin Process
39 39
Appendix A
The Process Chart Diagram was chosen to depict the process flows in the Popkin Process scenarios. 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.
Building an Enterprise Architecture: The Popkin Process
40 40
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 are
met.
Iteration: Represents a do-until condition in the process.
Swim Lane: The Horizontal Lanes (shown shaded) represent the Perspective responsible for the tasks shown within
that Lane.
Building an Enterprise Architecture: The Popkin Process
41 41
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 Architectures New 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 School
Press, 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 Journal 31, (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, 4
th
Ed. (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 Journal 26 (No. 3,
1987) [IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.]