5

Enterprise Architecture

“Architecture aims at eternity.” – Christopher Wren (1632-1723), English architect of

Saint Paul’s Cathedral.

This chapter presents the concept of enterprise architecture to support the analysis and
design of enterprise systems. An enterprise architecture is important to deal with the com-
plexity inherent in enterprise systems and to align the many subsystems so that they all
work harmoniously towards the enterprise’s goals. Enterprise architecture provides the foun-
dation on which enterprise integration is accomplished. Among the first decisions that are
made in an enterprise engineering project is what enterprise architecture to adopt.
After completing this chapter, you should be able to:
• Describe the reasons industry is increasingly turning to enterprise architectures.
• State the purpose of an enterprise architecture.
• Explain the relationship between a reference architecture and an enterprise architecture.
• Describe the components of an enterprise architecture.
• Describe the differences between reference enterprise architectures.
• Describe the views and perspectives of Zachman’s framework.
• Describe the components of TOGAF’s architecture.

5.1 Introduction
It is a rare occasion that a project involves the wholesale design of an entire enterprise.
Rather, projects are done to design a new system, to reengineer a business process, to
institute a continuous improvement program, or to complete some other project that alters
the current business operations, hopefully for the better. It is largely through the multitude
of projects conducted over a period of time that we contribute to the evolving design of a
business. After all, few of us are ever in the position where we can design an entire business
from the bottom up. These projects shape and change parts of the business contributing to
the constant evolution of the business’s overall design. Would it not be useful if all these
decisions that affect the design of an enterprise adhered to some consistent vision of how the
enterprise should operate? It is precisely this role that enterprise architecture is intended
to fulfill.
An enterprise architecture is a high-level design of the entire business. It describes the
structure of the business processes, how they are coordinated with each other, and how
technology supports them. It helps us understand the business’s complexity by showing
how all the different systems are linked together. In this definition, we say a design of

101
102 Design of Enterprise Systems: Theory, Architecture, and Methods

the entire business, yet in practice much of the discussion of enterprise architecture takes
place within the software engineering community. However, in truth, enterprise architecture
should be, and is intended to be for the entire business. The software component is only
one part of the enterprise architecture. It is for this reason that industrial engineers, among
other professionals, should be aware of and even participate in the development of enterprise
architecture. Without widespread participation, it is possible that the resulting enterprise
architecture will not address important business needs, or individual projects may even run
counter to other projects being done in other parts of the business.
An enterprise architecture provides a high-level design of the entire enterprise that will
guide all other enterprise projects. An architecture represents significant, broad design-
decisions for the enterprise, from which all other design decisions should be consistent. Ar-
chitecturally significant decisions are those that the architect (or architecture team) needs
to make in order to address the concerns of strategy, structure, and enterprise integration.
Architectural decisions include deciding how to decompose the enterprise into views, how to
decompose each view into different abstraction levels, policies on technology usage, decisions
on business culture to guide organizational design, and decisions on what modeling conven-
tions to use. These are but a few examples of what would be included in the enterprise
architecture.

An Enterprise Architecture describes the structure of an enterprise, its decomposi-

tion into subsystems, the relationships between the subsystems, the relationships with
the external environment, the terminology to use, and the guiding principles for the
design and evolution of an enterprise.

When discussing enterprise architecture, it is reasonable to draw parallels with the tradi-
tional architecture of buildings. An architect creates blueprints for the building that guide
its construction. The power of the blueprint is it aligns all the work on the building so
that as long as the carpenters, roofers, electricians, plumbers, and other workers follow the
blueprint, then they are assured their part will work together with the other parts and lead
to the envisioned building. Without the blueprint, there is no insurance the final product
will match the vision, nor will it necessarily be done in the most cost-effective manner.
Jeanne Ross, Peter Weill, and David Robertson in their book, Enterprise Architecture as
Strategy [13] describe an amusing example of what can happen when a house is built with-
out architecture as is the Winchester mansion in California. Sarah Winchester, the heiress
of the rifle manufacturer, had a mansion under constant construction from 1884 until 1922.
There were no plans for the house; construction was based on her sketches done on paper
and even her tablecloth. Some of the resulting oddities are stairs that lead into the ceiling,
a door that leads to nowhere, a blind chimney that stops short of the ceiling, and dozens
of other oddities. Moreover, because there was no master plan, old construction would be
ripped up to make way for new construction, walls would be removed and then added,
windows relocated, and so forth – greatly adding to the overall cost.
Many businesses evolve without any master plan much like Ms. Winchester’s house. To
a large extent, in the past, the enterprise was not viewed as a whole system that could
be rationally designed. More likely, parts or subsystems of the enterprise were designed in
isolation without a holistic perspective of how the parts would work in the entire system.
Enterprises would come into being and change not as a result of a conscious, purposeful
design effort, but due to ad hoc, sometimes short-term decisions made individually by many
different people. Michael Porter in his book, Competitive Advantage [12], cites a study by
Ernst and Young that found in many companies the key business processes were designed
 Enterprise Architecture 103

long before there was information technology (IT). Even though these companies had new IT
systems, they continued to follow the paper-based business processes but with IT. What this
study and other observations indicate is that for many enterprises their current structure
does not reflect the results of a rationale design, but the result of a multitude of small
changes made over time without consideration of the overall enterprise. The result is a
hobble of systems that often do not work together very well, poor investment choices,
under-utilization of resources, and diminished operation performance.
To illustrate the result of not having an architecture, consider the example taken from
a cruise line operating out of South Florida. The company, like many others, grew rapidly
over the years including an acquisition of a smaller cruise line. Figure 5.1 shows the resulting
system architecture, or lack thereof, that included many separately developed and main-
tained systems. The overall system has much redundant data, business logic was tightly
coupled to the data layer, and the execution of business rules was inconsistent across the
systems. Problems experienced include sometimes erroneous data, errors in reporting, ex-
pensive maintenance costs, and difficulty in modifying or improving business processes. It
is the primary purpose of enterprise architectures to avoid these problems.
Figure 5.1 shows just what can happen when a company builds its systems without
an enterprise architecture. The company from the hospitality industry grew each year and
added to its systems in a haphazard way. The systems were separately developed and
maintained by different organizational units. The result was thousands of separate data files
throughout the company. Examining Figure 5.1, when an application needs to access data it
is programmed to access data from multiple different files. So, for example, if a reservation
is updated with a change in the cabin number, then the new cabin number must be changed
in multiple locations. As a result, the company had a large amount of data redundancy and
duplicated business rules across multiple systems. When data are added to the system, it
must be added to multiple locations. Because the data get populated in so many different
locations, the company experienced recurring problems of data in one location not matching
data in another location. In addition, there may have been inconsistency in the execution
of business rules among the various systems. While this approach works, it is expensive
to maintain, it is fragile (changes to the underlying data sources may easily break the
application), the number of application operations needed to accomplish a task is excessive,
and it is hard to extend the system (additions require rewriting much of the code).
Lastly, consider the system design shown in Figure 5.2. The diagram shows the systems,
databases, and information flows in a large multi-national beverage company. The resulting
system complexity is beyond what anybody would consciously design. Rather it reflects the
many individual decisions, mergers, and acquisitions over a long period of time.
If the cruise company had an enterprise architecture, then the system evolution and
development could have gone differently. An enterprise architecture would have highlighted
the needed information flow, contained principles for interoperability, and provided a holistic
plan to guide individual system-development decisions. One of the primary benefits of an
enterprise architecture is that it shows how all the system components fit together. The
benefits of having an enterprise architecture are:
• To provide a model that lets all stakeholders understand and communicate the overall
business design. Enterprises are complex so models that abstract away this complexity
are very valuable for understanding the enterprise systems. Moreover, by providing an
integrated set of models, accessible to all stakeholders, then it helps create a shared vision
of how the enterprise is designed and how the enterprise operates. Consequently, an enter-
prise architecture helps stakeholders plan, manage, and effectively utilize the enterprise’s
systems and resources.
• To provide a high-level, holistic design of the business indicating how all the subsystems
104 Design of Enterprise Systems: Theory, Architecture, and Methods

Each application consists of many

(sometimes hundreds) of applications.
The programs are usually monolithic,
External Cruise Airline Vacation
Shopping containing business logic, interface
Match Application Planner Planner
logic, data, as well as code to
simulate a relational database
because a true one does not exist.

Internal Internal
Common Application
Reservations Reservations
Modules
Individual Group

Thousands of files without referential integrity, foreign key constraints, etc.

FIGURE 5.1
Results of system evolution at a cruise line.

From SAP: Data Warehouse

currency
order DaVinci transfers
From Phoenix
inventory transfers I2 SCM
DMS I2 SCM
Order I2 SCM Sales
I2 SCM
promises Customer Order JuiceIt Acct (Latin
Processing Sales legacy America)
To DW: Acct
shipments
Marketing
receipts
From: TCP trends
inventory balances
Shipments

I2 SCM
Mexico KR
reporting
Orders System Mercury System
receipts
Xenex ledger
Sales
Actual transfers Rpt Tool From Xenex:
orders district
deliveries amortization
Weekly Ortix Trade sales
forecast Sales Deals From Frodo:
marketing
From: Phoenix Acct Coupons MarketPro
promotion
freight pymts Promotion
HP Oracle coce
Inv Master
Acct Files CRM
General Material
orders Purhasing Orders
pymts Ledger orders Sales
shipments
Rebates Paymts Broker tooling
receivables
To Ortix:
TMS Accounts Mfg From Oracle: customer order
payment Payable Control Project history
From i2: shipments
DMS forecast Tool
amortization Benefits
To: COP Fixed Project assignment From Oracle:
invoice Human salary
actual inventory
Assets Acct SAP Financials Resources
deliveries
charges
From Oracle:
From HR:
Production
employee Gen salary orders
To DW: Finan
receipts Ledger
amortization
Frodo depreciation orders
Phoenix
ShipRight Acct Acct 3rd Party
Payable Rec’able logistics
To: Phoenix
project pymts Destination
PA PCA invoices
To: i2
reimbursement inventory To HP:
Travel status
From DW:
MC CCA freight pymts
Acct PS freight rates

Amex To: HR
travel From i2:
Visa shipments
reimbursements

FIGURE 5.2
System diagram of a large, multinational beverage company.
 Enterprise Architecture 105

will interoperate and coordinate their work. Essentially, the enterprise architecture helps
us avoid sub-optimization. We shift our emphasis from developing the best subsystem
(e.g., inventory control system, order fulfillment system, etc.) and instead consider how
the subsystems work together to reach overall system goals.
• To express the architectural principles of a long-term vision of the enterprise, and the
governing principles of the enterprise to guide all other projects. The statement of these
principles promotes effective planning and decision making. It aligns all the projects to-
wards achieving the overall enterprise objectives.
• To ensure legal and regulatory compliance. In the U.S., this is especially important to
help organizations comply with the 1996 Clinger-Cohen Act in the U.S.
Collectively, these benefits should reduce the operating costs by making the business
more efficient, they should also reduce the costs of infrastructure because all new projects
are built to an overall plan, and they should improve the business processes through better
system integration and coordination.

5.2 Enterprise Architecture Frameworks

Given the value of having an enterprise architecture the question is, how to develop one?
Every enterprise could develop its own architecture as it sees fit. The problem with this
approach is that developing an enterprise architecture is an enormous undertaking fraught
with the risk of omitting crucial elements, creating inconsistent interfaces between the views,
and not finishing the project in a reasonable time period. An alternative approach is, instead
of developing an enterprise architecture from scratch, an enterprise can start with a reference
enterprise architecture. A reference enterprise architecture (or simply reference architecture)
is a generic architecture that can be used as the starting point to derive an enterprise’s
architecture.1 A reference architecture is a meta-model, in that it is a model of how you
should model enterprises. It describes a structured set of models that collectively represent
the building blocks of an enterprise system. Reference architectures embody the knowledge
gathered, on a large scale, from a multitude of enterprise engineering projects. The idea is
that an enterprise by using a reference architecture is more likely to include all relevant
views in their architecture, will adopt best practices into their architecture, and will be able
to create the architecture much more rapidly than if they did it from scratch. Additionally,
the use of a reference architecture provides some insurance that the resulting architecture
will be useful and completed on schedule.
A reference architecture must be generic enough to be useful for a wide range of enter-
prises while at the same time it must be detailed enough that the commonalities are not
superficial. This is more or less the quandary faced by all modelers. Figure 5.3 shows how
a reference architecture could be used by many different companies to derive enterprise-
specific architectures. The three enterprise architectures will all be different (but similar)
even though they were all derived from the same reference enterprise architecture.
1 Terminology is not consistent in the literature. Zachman and a few others call it a framework; in this

book, take reference architecture to be equivalent to what they term a framework. Second, some authors
differentiate between two types of reference architectures. Williams [18] defines Type I architectures that
represent the structure of the enterprise system at a particular point in time, and Type II architectures that
represent the structure of a methodology to analyze and design an enterprise system. In this book, we shall
only refer to Type I architectures as reference architectures, and Type II architectures will be referred to
as methodologies.
106 Design of Enterprise Systems: Theory, Architecture, and Methods

Enterprise
Architecture
for Mega Ltd

Enterprise Reference Enterprise

Architectural Enterprise Architecture
Framework Architecture for Acme Mfg

Enterprise
Architecture
for Diamond
Corporation

FIGURE 5.3
Using a reference architecture.

A reference architecture prescribes a decomposition that allows engineers to develop so-

lutions to the subsystems relatively independently while ensuring the solutions will integrate
well with the other subsystem solutions so that an integrative, effective system solution is
obtained. The selection of the appropriate abstraction level, if left entirely to the modeler’s
discretion, would likely be inconsistent from one model to the next. The reference architec-
ture helps the enterprise modeler by defining appropriate abstraction levels. Moreover, the
relationships between the abstraction levels are explicitly defined in the model using the
modeling constructions and notation.
The reference architecture:

• Provides a unified, unambiguous definition of terminology.

• Establishes a common means to organize, interpret, and analyze architectural descriptions.

• Identifies architectural concerns, generic stakeholders, viewpoints, and abstraction levels.

• Facilitates communication of enterprise design.

• Helps stakeholders make decisions about enterprise design and operation.

• Is applicable to a wide range of enterprise systems and scenarios.

• Is developed in such a way that it encourages reuse.

• Provides users with some confidence that use of the reference architecture will be successful
in the current project.

The idea of having an enterprise architecture has gained wide acceptance. This has led to the
proliferation of many different reference architectures. In academia, reference models have
been created in Europe (CIMOSA [9] and ARIS [14]), and in the U.S. (PERA). In industry,
reference models have been created by IBM (Zachman’s Framework) and by industry groups
such as The Open Group’s TOGAF architecture. Moreover, many large enterprise system
vendors provide reference architectures to describe their software and how it will work in
the enterprise. For example, SAP has developed over 1000 reference models for business
processes in various industries such as automotive, finance, and insurance.
Governments have reference architectures. In the U.S., largely due to the 1996 Clinger-
Cohen Act, government agencies are developing enterprise architectures. The Clinger-Cohen
Act says each federal agency must have a Chief Information Officer (CIO) who is responsible
for developing, maintaining, and implementing sound and integrated information technology
 Enterprise Architecture 107

systems to achieve the agency’s strategic goals. This act has largely been interpreted as
requiring U.S. federal agencies to have enterprise architectures.
The U.S. Department of Defense has the DoDAF (Department of Defense Architec-
tural Framework). The CIO Council, formed by the CIOs of major government agencies,
developed the Federal Enterprise Architecture Framework (FEAF) [2] for the U.S. federal
government. Later the Office of Management and Budget (OMB) assumed responsibility
for enterprise architecture and published the Federal Enterprise Architecture (FEA) [3].
National and International standards bodies have published or are working on several
different enterprise architectures. IEEE 1471 [4] describes the recommended practices for ar-
chitectural descriptions of software-intensive systems, and in 2008, it became the ISO 42010.
There is an international standard titled Generalized Enterprise Reference Architecture and
Methodology (GERAM) to specify what should be part of reference enterprise architectures
[1]. GERAM is not per se a reference architecture but a meta-reference architecture.
Surveys of enterprise architectural framework usage show that Zachman’s Framework
has the largest market share followed by TOGAF [5, 10, 15]. The results may be skewed be-
cause most respondents are from the U.S. In addition to the general architecture frameworks,
many enterprises use industry-specific frameworks. For example, in one survey [5] eTOM
was mentioned, which is the Enhanced Telecom Operations Map. The surveys also suggest
that many companies still use proprietary architectures. In the following subsections, we
describe the two most commonly used reference architectures: Zachman’s Framework and
TOGAF. These are reference enterprise architectures – as a reference architecture, you “re-
fer” to the reference enterprise architecture to specify what to model, how to model, and
why to model. Understanding Zachman’s Framework is important because it strongly influ-
enced many of the U.S. government’s reference architectures, so to understand of Zachman’s
provides prerequisite knowledge to understand FEAF and FEA.

5.2.1 Zachman’s Framework

Zachman was an employee of IBM who first published in 1987 a framework [19] that has
since evolved into the Zachman Framework for Enterprise Architecture, draws upon the
discipline of classical architecture/construction and engineering/manufacturing to establish
a common vocabulary and set of perspectives for defining and describing enterprise systems.2
Zachman’s framework is a logical structure for classifying and organizing those elements
of an enterprise that are significant to both the management of the enterprise and the
development of its information systems. Zachman’s Framework is among the most widely
used reference architectures; it has also strongly influenced the federal government’s FEAF.
The Zachman Framework describes an enterprise architecture along two dimensions of
the stakeholders and the perspectives of the enterprise. The framework is a classification
scheme that Zachman claims is complete, in that it contains all the cells that exist. There
are 36 cells in the framework. In the current form of the architecture, shown in Figure 5.4,
the rows represent the various stakeholders. The stakeholders are from top to bottom:

1. The first row, SCOPE, establishes the context for any enterprise system project.

2 To quote from Zachman, “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 Enterprise’s systems. It was derived
from analogous structures that are found in the older disciplines of Architecture/Construction and Engi-
neering/Manufacturing that classify and organize the design artifacts created over the process of designing
and producing complex physical products (e.g., buildings or airplanes).” - Zachman, J. The Framework for
Enterprise Architecture: Background, Description and Utility, from www.zifa.com, accessed on April 10,
2009.
108 Design of Enterprise Systems: Theory, Architecture, and Methods

The scope is frequently defined in a Statement of Work (SOW) or other similar

document. It defines the enterprise goals, strategy, boundaries, and purpose.
2. The second row, ENTERPRISE MODEL, presents the business owner’s view
that defines, in business terms, the nature of the business, including its structure,
functions, organization, and so forth. This row involves the first formal modeling
effort. The SOW provides the starting point for model creation. The integrity of
the rules developed for this row must be maintained throughout the remaining
rows.
3. The third row, SYSTEM MODEL, presents the designer’s view that defines the
business similar to the owner’s view, but in a more rigorous detailed form. This
row is sometimes called the conceptual or logical view. For example, row two
would define the business functions from the owner’s perspective in terms of
what activities need to be done. Row three would define it in terms of data
transformations, input/output relationships, constraints on the activities, who
can do each activity, and so forth.
4. The fourth row, TECHNOLOGY MODEL, presents the builder’s view, a techno-
logical view that describes how the system functions, information, organization,
and so forth are implemented. This row is sometimes called the physical view,
and prepares the model for implementation. The person performing this activity
is proficient in technology. The models associated with this row directly support
the future implementation.
5. The fifth row, COMPONENTS, presents the code that implements the applica-
tion. The person performing this function is the implementer. The implementer
is accountable for implementing the provided design.
The columns represent different viewpoints of the enterprise. When it focused on the in-
formation system, Zachman’s original framework had three views of data, process, and
interface. The current version of Zachman’s framework re-did the views in terms of the pre-
rogatives: what, how, where, who, when, and why?3 These map to the columns as follows:
1. The first column, DATA, is the “What” things that are involved in the subject
area. The data consist of a list of things. The Entity is a major data item that
stands for a class of a business thing. Entities are connected via relationships.
2. The second column, FUNCTION, is the “How” things are done. This consists of
a list of processes that are performed.
3. The third column, NETWORK, is the “Where” things are done. This could be a
list of locations or network nodes that need to be supported to allow the knowledge
to be captured and used within the subject area. The design team should under-
stand if the available network supports that current application. The additional
knowledge that is captured to support this conclusion should be documented.
4. The fourth column, PEOPLE, is the “Who” that are part of the enterprise.
It contains models about the people and organizations within the business. It
describes the rules dealing with who is responsible for a piece of knowledge, who
participates in a process, and other work policies.
5. The fifth column, TIME, is the “When” something is done. This could be a
fixed time that triggers a process, the time of an event that triggers another
process, or a time sequencing that says this process must be performed before a
3 “ I keep six honest serving men (they taught me all I knew): their names are What and Why and When

And How and Where and Who” from The Elephant’s Child by Rudyard Kipling [8].
 Enterprise Architecture 109

Data Function Network People Time Motivation

(What?) (How?) (Where?) (Who?) (When?) (Why?)

Scope List of
List of List of List of major List of major List of
locations for
(Planner’s business business organization- business enterprise
business
Perspective) data functions al units events goals
operations

Business
Enterprise Model Business Strategic
Semantic hierarchy Organization Business
(Owner’s Process Plan &
Data Model mapped to Chart Plan
Perspective) Model Timeline
location

System Model Distributed Business

Logical ER Activity Level Job roles & Business
(Designer’s System Rules and
Model Model responsibility Schedule
Perspective) Architecture Policies

Technology Model Information Reward

Physical ER Data Flow People Control
(Builder’s Technology System &
Model Diagram (Who?) Structure
Perspective) Architecture Mgmt Control

Detailed Supplier
Process Timing and
Representation Data Network People Contracts &
Specification Sequencing
(Subcontractor’s Dictionary Infrastructure (Who?) Performance
& Code Definitions
Perspective) Criteria

FIGURE 5.4
Zachman’s framework.

follow-on process. The successful implementation of an application requires this

information. The formal requirement that this be addressed within a design will
improve the resulting quality of the design. It is generally used in relationship to
the Data and Function columns.
6. The sixth column, MOTIVATION, is the “Why” things are done. Business goals
and strategies are listed here. These goals and strategies can be expressed as
natural language sentences. In many cases, the sentences that measure these goals
and strategies will have derivation rules for determining the performance of the
company or organization. The derived fact instances are compared with stated
goals that are called out in a business objective.
Zachman’s framework distinguishes each stakeholder’s perspective of the enterprise and
shows how to incorporate all the stakeholders’ perspectives into the understanding of an
enterprise. The idea that different stakeholders can have different perspectives of the same
enterprise is illuminating to many analysts, designers, and engineers. In this way, Zachman’s
framework serves the important need of a reference architecture – to facilitate communica-
tion. It helps users of the framework understand how other stakeholders view the system
and thus can work better together in the design of an enterprise system. When every cell is
populated with appropriate artifacts, there is a sufficient amount of detail to fully describe
the system from the perspective of every stakeholder looking at the system from every
possible angle (descriptive focus).
Describing the different stakeholder perspectives is not sufficient in itself, but the frame-
work also explains how they fit together. It is similar to the Indian parable of seven blind
men each feeling a different part of the elephant, but none can put it together to define the
elephant as a whole.4 Well, Zachman’s framework shows how these different perspectives
come together; it shows how the different views correspond to each other and, it shows how
models are linked to the technology that implements the model concepts.
4 Parable of The Blind Men and the Elephant by John Godfrey Saxe (1816-1887).
110 Design of Enterprise Systems: Theory, Architecture, and Methods

A criticism of Zachman’s framework is that ideally the viewpoints should be orthogonal.

In other words, two different viewpoints should show different views of the enterprise without
overlapping. In Zachman’s framework, the time column seems to be confounded with the
data and function column. It is difficult to see how this column could be modeled separately
from other views – a violation of the orthogonality principle. A second criticism is that
Zachman does not specify what type of models to populate each cell. So, the DATA view
could be populated with entity-relationship models, object-oriented models, or any other
model. Critics also say that the 36 cells are too many, and few organizations would ever
populate every cell. There is nothing in Zachman’s framework that prevents an organization
from adapting it to its needs. Lastly, some critics are disappointed that the framework has
no associated methodology. It is strictly a taxonomy for the models. Every other reference
architecture that is reviewed in this book includes a methodology. What an enterprise
contemplating using Zachman’s framework would have to do is determine what methodology
would integrate with the framework.
What the Zachman framework contributes to the enterprise design problem is clarity
of thought. It provides confidence to the design team that if they address all stakeholder
levels (planner, owner, designer, developer, translator, and worker), satisfy the basic six
interrogative questions about the system (what, how, where, who, when, and why), and
have traceability between the stakeholders and across the questions, then the design team
created a good enterprise architecture.
Over the years the Zachman’s framework has been widely adopted by the architecture
community and it is incorporated into and influence of it can be found from many other
enterprise architecture frameworks [16], e.g., Federal Enterprise Architecture Framework
(FEAF) [2], Treasury Enterprise Architecture Framework (TEAF), and The Open Group
Architecture Framework (TOGAF) [17].

5.2.2 TOGAF
TOGAF is the acronym for The Open Group Architecture Framework that is developed by
The Open Group. TOGAF Version 8.1 Enterprise Edition is an industry standard architec-
ture framework that can be freely used by any enterprise developing enterprise architecture
for its own use [17]. TOGAF evolved from earlier work by the U.S. Department of Defense
on the Technical Architecture Framework for Information Management (TAFIM).
TOGAF describes four architectural views:
1. Business architecture – Describes the processes the business uses to meet its goals.
It links strategy formulation to strategy implementation.
2. Application architecture – Describes how specific applications are designed and
how they interact with each other.
3. Data architecture – Describes the enterprise’s logical and physical data resources
and how the data are managed.
4. Technical architecture – Describes the hardware and software infrastructure that
supports the business processes, applications, and their interactions.
In addition to these views, TOGAF allows for the definition of other views, but it does not
say what these views should be in the same way that Zachman’s Framework does.
TOGAF consists of three main parts: the Architecture Development Methodology
(ADM), the Enterprise Continuum, and the Resource Base. The ADM is a method for de-
veloping an enterprise architecture to meet the business and information technology needs
of an enterprise (see Figure 5.5). According to the TOGAF specification, each iteration of
the ADM must include decisions regarding: (1) the breadth of coverage of the enterprise
 Enterprise Architecture 111

Preliminary
Framework
and principles

A
Architecture
Vision
H
Architecture B
Change Business
Management Architecture

G C
Implement- Information
Requirements
ation and System
Governance Architecture

D
F
Technology
Migration
Architecture
Planning

E
Opportunities
and Solutions

FIGURE 5.5
TOGAF architecture development method.

to be specified, (2) the depth of details to be specified, (3) the extent of the time horizon
aimed at, and (4) the architectural assets to be leveraged in the organization’s Enterprise
Continuum.
The Enterprise Continuum may be viewed as a “virtual repository” of all the architecture
assets available to an organization. The term “assets” refers to architectural models, archi-
tectural patterns, architecture descriptions, and other artifacts. These artifacts may exist
within the enterprise and also in the IT industry at large. The ADM promotes the idea of
reuse, and suggests throughout the methodology when the architectural development team
should look for assets both within and outside of the firm. Additionally, TOGAF includes
two reference models that may be used:

1. TOGAF Foundation Architecture, which describes an architecture of generic ser-

vices and functions to build specific enterprise architectures. The two components
of the foundation architecture are:
(a) TOGAF Technical Reference Model (TRM) is a model and taxonomy of
generic platform services.
(b) TOGAF Standards Information Base (SIB) is a database of open industry
standards to define the services and other IT components of the architecture.
2. The Integrated Information Infrastructure Reference Model is designed to help
the enterprise design boundary-less information flow.
The Resource Base is a set of tools (guidelines, templates, etc.) that are available to help
the enterprise architect in the use of the ADM.
112 Design of Enterprise Systems: Theory, Architecture, and Methods

TOGAF is primarily an IT architecture that looks to align the IT view with the business
view. The views confirm this assessment in that three of the four views are all technical in
nature (the application, data, and technical views). Unlike Zachman’s Framework, TOGAF
does not define different abstraction levels corresponding to the stakeholders’ views. It
does not forbid a company from building these models, but neither does it promote the
practice. Since the decomposition of the enterprise into views to deal with complexity is
one of the main motivators for enterprise architecture, it is useful to discuss how well
the architectures accomplish this. TOGAF could be criticized because the views are not
orthogonal: they overlap significantly. The business and data views correspond to columns
in Zachman’s Framework but the application and technical views correspond to rows. The
application view describes the software systems that support the business processes. So, it
is a somewhat more technical view of the business process. Moreover, the technical view
describes the infrastructure that should be integrating the data view, application view, and
business view. This overlapping of views can confuse design teams and other users of the
architecture if they are not conversant with TOGAF.
TOGAF’s strength is its ADM methodology that describes a detailed approach to gener-
ate enterprise architectures. Given the large scope and complexity of building an enterprise
architecture, this is a worthwhile contribution to make the architecture design process easier
and smoother.

5.2.3 Other Enterprise Architectures

The Computer Integrated Manufacturing Open System Architecture (CIMOSA) is a ref-

erence architecture developed by a research consortium in Europe, named AMICE, to de-
scribe, as its name implies, manufacturing systems. CIMOSA defines three dimensions of
life-cycle phases, views, and implementation stages. The four views it provides of the en-
terprise are the information, function, resource, and organization views. CIMOSA is still
active (see www.cimosa.de), but the architecture is probably not widely used anymore. The
CIMOSA Association is focused on enterprise integration and standardization efforts. Many
of the CIMOSA researchers contributed to the development of the Generalized Enterprise
Reference Architecture and Methodology (GERAM).
The Architecture of Integrated Information Systems (ARIS) was developed by A. Scheer
in Germany [14], and has been adapted by SAP, a large vendor of enterprise resource
planning (ERP) systems. ARIS defines the House of Business Process Management that
describes the enterprise by four inter-related views of data, function, organization, and
control. The core of the ARIS architecture is the control view, which integrates the other
three views of data, function, and organization. The control view is modeled with Event
Process Chains (EPCs) that allow the modeling of the business processes. ARIS is well
developed commercially; there is a toolset available to implement ARIS and as mentioned
it is used by SAP to describe their ERP system.
GERAM was developed by the IFIP-IFAC Task Force on Architectures for Enterprise
Integration [1]. GERAM is not a reference architecture like the others, instead GERAM is
meant to assess reference architectures for completeness. GERAM cannot be implemented
directly like the other reference architectures because it has no symbols or methodology
of its own. GERAM was specified by evaluating three existing enterprise architectures of
CIMOSA, GRAI, and PERA; taking the best characteristics of each; and then combining
them into GERAM. The GERAM life-cycle phases are identification, concept, requirements,
preliminary design, design, detailed design, implementation, operation, and decommission
[11].
 Enterprise Architecture 113

5.2.4 Summary Enterprise Reference Architectures

An enterprise reference architecture embodies all the knowledge gained from a history of en-
terprise engineering projects. There are several different enterprise architectures that have
gained acceptance; in this chapter, we reviewed the more prominent reference architec-
tures which are Zachman’s Framework and TOGAF. A brief mention was made of ARIS,
CIMOSA, and GERAM, which have contributed to the development of enterprise architec-
tural ideas. A commonality of these architectures is the idea of representing different views
of the enterprise. The data, function, and organization view appear in all of them. The
architectures differ in whether they include a resource view and in the representation of
process. Some, such as Zachman make no distinction between function and process. Others,
such as ARIS model function separately from process, which is the control view of that
architecture. Regardless of the views, the concept is that the reference architecture provides
a holistic view of the enterprise, through the integration of multiple, orthogonal views.
One of the main benefits of the enterprise architectures is they organize our knowl-
edge about enterprises, they standardize terminology, and they describe proven methods to
model, analyze, and design enterprises. Consequently, an enterprise reference architecture
helps the members of an enterprise engineering project team to organize integrated mod-
els of the enterprise. It helps ensure interoperability of the enterprise designs, and it helps
control the costs of the enterprise project. As a result, enterprise reference architectures
support design by helping us manage complexity.

5.3 Developing the Enterprise Architecture

To develop an enterprise architecture is a project that requires a cross-functional team led
by a facilitator. The facilitator is a person knowledgeable in enterprise architectures. The
facilitator convenes a group of stakeholders to discuss the business vision and how it can
be realized by the enterprise architecture. One of the first decisions is whether to use a
reference architecture, and if so, which reference architecture to use. It is recommended to
use a reference architecture because: it will provide a comprehensive view of the enterprise,
minimizing the risk of leaving out important enterprise views and/or components; it will
minimize the time and cost necessary to build an enterprise architecture; and lastly, it
embodies the knowledge gained from many other enterprise architectures that can be reused
in the current project.
The decision to adopt a reference architecture as a starting point does not mean it
needs to be used verbatim. The reference architecture can be adapted to suit the particular
needs of the enterprise. Reference architectures define the main concerns that should be
included in the model, but a particular concern may be of low priority for your enterprise.
For example, Zachman’s framework might be selected, but the enterprise might decide to
collapse two views into a single view, or ignore a view completely because it is of lower
priority than the other views.
The team decides what to include and what not to include in the enterprise architecture.
Only those decisions that are system-wide, high priority, and important to the business are
included in the enterprise architecture. Table 5.1 shows a decision matrix to categorize
whether decisions should be included in the enterprise architecture or not. Only those
decisions that are system-wide and high impact are included in the architecture. Decisions
that are local should in general not be included. However, the enterprise architecture might
articulate guidelines, principles, or policies to guide those decisions.
114 Design of Enterprise Systems: Theory, Architecture, and Methods
TABLE 5.1
Architectural Decisions Are Both System-wide and Have
High Impact on the Enterprise
Low Impact High Impact
System-wide Not an architec- Architectural
tural decision decisions

Local Not an architec- Not an architectural

tural decision decisions (but might
set guidelines and
policies to direct
decisions)

While developing the architecture, the architectural design team articulates and debates
architectural principles. A good enterprise architecture provides a flexible, scalable structure
that can be modified over time as needs change. An enterprise architecture describes guiding,
architectural principles. Example statements of architectural principles are:
• “The enterprise will provide access to information to authorized users to perform their
jobs independent of physical location.”
• “New systems shall be able to interoperate with the existing ERP financial’s module. They
shall be tested to determine they can import and export data to the financial’s module.”
• “New system development projects shall provide an end-to-end process model, and all
organizational units involved in the process shall sign off on the project.”
It is easy to see how the architectural principle will guide later projects. Whenever a
project is initiated, the project team will have to ensure information availability regardless
of physical location. Including this principle in the architecture ensures an enterprise-wide
conformance.
Once the views and architectural principles are established, the team focuses on develop-
ing baseline models of the current enterprise situation. A strategy to develop the enterprise
architecture is to evolve it top-down from the more abstract model levels to more detailed
levels. This strategy has several advantages. First, it is difficult to develop an entire en-
terprise architecture in a short period of time. The team then defines how it wants the
enterprise architecture to look.
Once the team completes the to-be models, it then develops an overall plan on how to
close the gaps between the as-is model and the to-be model. In many cases, the enterprise
architecture is nothing more than a conceptual architecture that gradually emerges as the
result of implementing many individual projects [7].
An enterprise architecture includes the components specified in Table 5.2 (adopted from
[6]). The enterprise architecture is widely distributed in the organization for feedback, com-
ments, and to help buy-in by the entire organization.

5.4 Enterprise Reference Architecture

This book uses the enterprise reference architecture shown in Figure 5.6. The architecture
maps the enterprise design methodology, represented by rows, and the three enterprise views,
 Enterprise Architecture 115
TABLE 5.2
The Components that Are Included in the Enterprise Architecture
Documents and Their Description
Component Description

Strategy Strategy map, goals, corporate mission and vision,

business philosophy, corporate culture and values.

Name Architecture name, description, version, and

overview information, date of issue, change his-
tory, scope, context, and glossary.

Stakeholders Identification and description of enterprise stake-

holders and their architectural-related concerns.

Views The enterprise architecture should model multiple

views of the enterprise. Moreover, it is possible
to model these views at multiple levels as recom-
mended by Zachman.
The definition of each architectural viewpoint, its
boundaries, and its rationale.
The views should be consistent, so that an infor-
mation object in one view matches the information
input shown in the function view.

Models The models to populate one or more architectural

viewpoints.

Principles Architectural principles and rationale for all archi-

tectural choices and decisions that should guide all
enterprise projects.

Conventions Policies and rules.

represented by columns. The three enterprise views are: information, process, and organi-
zation. The three enterprise views were selected based on obtaining a complete perspective
of the enterprise with a minimum set of views. Additionally, the architecture identifies the
main stakeholders corresponding to each methodology phase. Similar to Zachman’s frame-
work, each cell is populated with models and other documentation. Collectively, when filled
it presents a holistic view of the enterprise project: why the project was done, how it was
done, and what was accomplished.

5.5 Summary
This chapter argued and demonstrated that companies need enterprise architecture to avoid
problems with enterprise integration. An enterprise architecture was defined as the high-level
design of the enterprise. A best practice is to use an architectural framework as the starting
point to develop a specific enterprise’s architecture. The chapter reviewed two architectural
116 Design of Enterprise Systems: Theory, Architecture, and Methods

Information Process Organization

Project Define business case for project, identify needed Enterprise

Initiation resources, initial scope, schedule, and budget Owners

Define Define Define

Project information functions organization Enterprise
Planning
objects in and their units in Owners
scope boundaries scope

Analyze Analyze Analyze

information organizational Enterprise
Analysis process
problems & problems & problems & Participants
requirements requirements requirements

Generate Rationale for Rationale for Rationale for Enterprise

& Evaluate information process organization Owners &
Alternatives design design design Designers
decisions decisions decisions

Design Design Design

Design model of Enterprise
model of model of
organization Designers
information process

Technology Technology Technology

Enterprise
Construction model of model of model of
Developers
information process organization

Change management plan for implemented Change

Implementation
enterprise design Manager

FIGURE 5.6
Enterprise reference architecture.
 Enterprise Architecture 117

frameworks: Zachman’s and TOGAF. These architecture frameworks showcase the variety
of approaches to architecture. Many of these architectures came out of the IT industry and
were later extended for coverage of all enterprise aspects. The field of enterprise architecture
is ongoing and new standards and developments are underway.
An enterprise architecture accomplishes two goals beneficial to the enterprise engineer-
ing project: first, it creates a holistic view of the enterprise showing how all the various
perspectives join together to form the enterprise; second, it establishes design standards
and answers long-term decisions that all future projects conform with. The enterprise ar-
chitecture should underpin every project the enterprise embarks on.

Review Questions
1. Describe three common views in an enterprise architecture.
2. Describe the relationship between a reference architecture and an enterprise ar-
chitecture.
3. Describe four benefits derived from having an enterprise architecture.
4. List the components that make up an enterprise architecture.
5. Compare and contrast the architectural approaches taken by Zachman and TO-
GAF.
6. Describe characteristics of the types of decisions that should be included in en-
terprise architectures.
7. Explain why many enterprise architectures divide the enterprise into separate
views.
8. List some architecturally significant decisions and some decisions that are not
architecturally significant.

Bibliography
[1] P. Bernus and L. Nemes. Requirements of the generic enterprise reference architecture
and methodology. Annual Review in Control, 21:125–136, 1997.

[2] The Chief Information Officers Council. Federal enterprise architecture framework,
version 1.1. Technical report, www.cio.gov/documents/fedarch1.pdf, 1999.

[3] FEA. FEA consolidated reference model document version 2.1. Technical report, the
Federal Enterprise Architecture Program Management Office, Office of Management
of Budget, 2006.

[4] IEEE. IEEE standard 1471-2000: IEEE recommended practice for architectural de-
scription of software-intensive systems. Technical report, 2000.

[5] Infosys. Win in the flat world: Infosys enterprise architecture survey 2005. technical
report, InfoSys, 2005.
118 Design of Enterprise Systems: Theory, Architecture, and Methods

[6] ISO. ISO 42010 - systems and software engineering - architectural description of
software-intensive systems. Technical report, 2008.
[7] B. Iyer and R. Gottlieb. The four-domain architecture: An approach to support enter-
prise architecture design. IBM Systems Journal, 43(3):587–598, 2004.
[8] R. Kipling. Just So Stories, chapter The Elephant’s Child. 1902.
[9] K. Kosanke, F. Vernadat, and M. Zelm. Cimosa: Enterprise engineering and integration.
Computers in Industry, 40:83–97, 1999.
[10] D. Minoli. Enterprise Architecture A to Z: Frameworks, Business Process Modeling,
SOA, and Infrastructure Technology. CRC Press, Boca Raton, FL, 2008.
[11] O. Noran. An analysis of the zachman framework for enterprise architecture from the
GERAM perspective. Annual Reviews in Control, 27(2):163–183, 2003.
[12] M. E. Porter. Competitive Advantage: Creating and Sustaining Superior Performance.
The Free Press, New York, NY, 1985.
[13] J.W. Ross, P. Weill, and D.C. Robertson. Enterprise Architecture As Strategy: Creating
a Foundation for Business Execution. Harvard Business School Press, Cambridge, MA,
2006.
[14] A.W. Scheer. Architecture of Integrated Information Systems: Principles of Enterprise
Modeling. Springer-Verlag, Berlin, Germany, 1992.
[15] J. Schekkerman. Trends in enterprise architecture 2005: How are organizations pro-
gressing? Technical report, Institute for Enterprise Architecture Developments, 2005.
[16] A. Tang, J. Han, and P. Chen. A comparative analysis of architecture frameworks. In
Proceedings of the 11th Asia-Pacific Software Engineering Conference, pages 640–647,
2004.
[17] TOGAF. The open group architectural framework enterprise edition, version 8.1 2003.
Technical report, http://www.opengroup.org/architecture/togaf/, 2003.
[18] T.J. Williams. Handbook of Life Cycle Engineering, chapter The Purdue enterprise
reference architecture (PERA), pages 289–330. Springer, New York, NY, 1998.
[19] J.A. Zachman. A framework for information systems architecture. IBM Systems Jour-
nal, 26(3):276–292, 1987.