A COMPARISON OF ENTERPRISE ARCHITECTURE FRAMEWORKS

Lise Urbaczewski, Eastern Michigan University, lurbacze@emich.edu

Stevan Mrdalj, Eastern Michigan University, smrdalj@emich.edu

ABSTRACT have also been made [7]. The Open Group [12] has
drawn comparisons between its architectural
An Enterprise Architecture Framework (EAF) maps framework, TOGAF, and existing frameworks. Tang
all of the software development processes within the et. al provide an analysis of frameworks at a high
enterprise and how they relate and interact to fulfill level, based on their “goals, inputs and outcomes”
the enterprise’s mission. It provides organizations [10]. The aim of this paper is to provide a direct
with the ability to understand and analyze comparison of the frameworks, based on their views
weaknesses or inconsistencies to be identified and and aspects. In order to establish a common ground
addressed. There are a number of already for the framework comparison, we studied several
established EAF in use today; some of these existing enterprise architecture frameworks. Second,
frameworks were developed for very specific areas, we created a method to compare the frameworks
whereas others have broader functionality. This study based on the perspectives of their stakeholders and
provides a comparison of several frameworks that abstractions. Third, we then compared the
can then be used for guidance in the selection of an frameworks. From this, we discuss the ways that such
EAF that meets the needed criteria. comparisons can be used in determining a best-fit of
a framework dependent on specific stakeholder needs
Keywords: Architecture Frameworks, Enterprise for a given project.
Architecture, Comparison
OVERVIEW OF EXISTING ENTERPRISE
INTRODUCTION ARCHITECTURE FRAMEWORKS

Enterprise architecture serves as the blueprint for the The following are concise descriptions of five EAFs
system and the project that develops it. An enterprise that are used in this comparison.
architecture framework can describe the underlying
infrastructure, thus providing the groundwork for the Zachman Framework for Enterprise
hardware, software, and networks to work together. Architecture: John Zachman published the Zachman
According to the Systems & Software Consortium Framework for Enterprise Architecture in 1987 [14]
[11], “An Enterprise Architecture relates and is considered to be one of the pioneers in this
organizational mission, goals, and objectives to work domain [6]. According to Zachman [15], “the
processes and to the technical or IT infrastructure increased scope of design and levels of complexity of
required to execute them.” In addition, a good information systems implementations are forcing the
architecture and its corresponding documentation use of some logical construct (or architecture).” The
allow for ease of maintenance in order that the Zachman Framework is based around the principles
system does not become obsolete before it is even of classical architecture that establish a common
built. There are a number of architectures and vocabulary and set of perspectives for describing
architectural frameworks in use today. Though they complex enterprise systems. The Zachman
may overlap or address similar views, frameworks Framework has six perspectives or views: Planner,
also have been designed to address specific needs or Owner, Designer, Builder, Subcontractor, and User.
concerns. These frameworks differ by the The second dimension of Zachman’s Framework
stakeholders they address and the issues that concern deals with the six basic questions: what, how, where,
their *world*. These issues or “building blocks” who, when and why [6]. The framework does not
represent methods, common vocabulary, standards provide guidance on sequence, process, or
[13], and tools that provide a means to implement implementation, but rather focuses on ensuring that
and integrate the building blocks. In addition, all views are well established, ensuring a complete
government, commercial, and sub-categories of each system regardless of the order in which they were
of these may require certain protocols to follow. established. The Zachman Framework has no explicit
Goethals [6] and Schekkerman [8] provide compliance rules since it is not a standard written by
comprehensive overviews of EAF in the literature. or for a professional organization. However,
Informal comparisons between specific architectures

Volume VII, No. 2, 2006 18 Issues in Information Systems

 A Comparison of Enterprise Architecture Frameworks

compliance can be assumed if it is used in its entirety that these work products align with FEAF models
and all the relationship rules are followed [9]. and DoDAF products [6].

Department of Defense Architecture Framework The Open Group Architectural Framework

(DoDAF): The Department of Defense Architecture (TOGAF): The Open Group Architectural
Framework (DoDAF) [2] builds on three sets of Framework (TOGAF) was first developed in 1995
“views”: Operational, System, and Technical and was based on the Department of Defense’s
Standards. A fourth view, ‘All View,’ augments the Technical Architecture Framework for Information
other views by providing the linkage between the Management [12]. TOGAF focuses on mission-
views by means of a dictionary to define terms and critical business applications that use open systems
by providing context, summary, or overview-level building blocks. “A key element of TOGAF is
information [3]. This framework provides Architecture Development Method (ADM) that
descriptions of final products as well as guidance and specifies a process for developing enterprise
rules for consistency. This ensures a “common architecture” [10]. TOGAF explains rules for
denominator for comparing, and integrating Families developing good principles, rather than providing a
of Systems, Systems of Systems, and interoperating set of architecture principles. The three levels of
and interacting architectures” [2]. principles support decision making across the entire
enterprise; provide guidance of IT resources; and
Federal Enterprise Architecture Framework support architecture principles for development and
(FEAF): The Federal Enterprise Architecture implementation.
Framework was developed and published by the US
Federal Chief Information Officers (CIO) Council A PROPOSED METHOD
[5]. Government was following the industry trend of FOR COMPARISON OF EAFs
defining architectural frameworks to guide in the
development of large, complex systems development. To compare the existing frameworks, we must first
FEAF was in response to the Clinger-Cohen Act, define what an ‘enterprise architecture framework’ is
1996 [1], which required Federal Agency CIOs to for the sake of our comparison. The definition
develop, maintain, and facilitate integrated systems utilized for this study, as stated earlier, is: A tool that
architectures. The overriding goal of FEAF is to can be used for developing a broad range of
organize and promote sharing of Federal information architectures for capturing the needed information in
for the entire Federal Government [6]. The an enterprise. The framework also provides a vehicle
architectural segments are developed individually, for accessing, organizing, and displaying that
within structured guidelines, with each segment information. We also define two key elements of
considered to be its own enterprise within the Federal enterprise architecture as
Enterprise. We include the Federal Enterprise
Architecture (FEA) - Practical Guide [4] within our
A definition of the deliverables that the
discussion on FEAF because it provides the guidance architecting activity should produce;
to U.S. federal agencies for frameworks. FEA allows
A description of the method by which this is
for flexibility in the use of methods, work products, done.
and tools to be used by the individual federal
agencies. There are many challenges in comparing EAFs. We
will list several of them. Some of the frameworks
Treasury Enterprise Architecture Framework have a very specific scope and therefore are
(TEAF): The Department of the Treasury published applicable to those applications. There are
the Treasury Enterprise Architecture Framework frameworks that apply to a specific application or
(TEAF) in July 2000. The Department of the development methodology, for example object
Treasury is comprised of a number of offices that oriented development or distributed systems. Some
function as individual enterprises. Therefore, its frameworks are truly enterprise oriented and some
enterprise architecture needs to map the are specific to the development of the IT system only.
interrelationships among the organizations in order to In order to overcome above challenges, we decided to
manage IT resources. The TEAF aims at facilitating compare the frameworks based upon their views,
“integration, information sharing, and exploitation of their abstractions, and their coverage of the Systems
common requirements across the department” [6]. Development Life Cycle.
Similar to DoDAF, TEAF includes descriptions of
work products for documenting and modeling
enterprise architectures. TEAF also explicitly states

Volume VII, No. 2, 2006 19 Issues in Information Systems

A Comparison of Enterprise Architecture Frameworks

Comparison by Views and Abstractions including materials needed. This represents the plan
that will be committed to construction. The fourth
Our study performed both the views and abstractions view, or that of the ‘builder,’ represents the view in
comparisons, with the views comparison being more which the architect’s final plans are modified to
quantifiable. We found the Zachman’s views to be reflect how construction will proceed. The
the most comprehensive and therefore other EAFs subcontractor view represents drawings of parts or
stakeholder perspectives could be represented using subsections of the plans. They are considered “an
the Zachman terminology (Table 1). The planner ‘out-of-context’ specification of what actually will be
view includes the concepts for the final product and fabricated or assembled. The last view represents the
may encompass items such as the relative size, shape, final product, building, or project. It is the physical
and basic intent of the final structure. The second result. From the standpoint of an information system,
view is that of the owner which may represent an this would reflect the users’ view and therefore, the
architect’s drawings in which the owner agrees that functional enterprise. Though the terminology may
the architect has captured what he has in mind. The differ somewhat amongst frameworks, the views can
designer view is the architect’s final product, be represented in this manner.
whereby he has detailed and described the plans

Table 1. Comparison by Views/Perspectives

Framework Planner Owner Designer Builder Subcontractor User

Zachman Scope Business System Technology Detailed Functioning
Model Model Model Representations System
DoDAF All View Operational Systems Technical
View View View
FEAF Objectives/Scope Enterprise Information Technology Detailed
Planner’s View Model Systems Model Specifications
Owner’s Model Builder’s Subcontractor’s
View Designer’s View View
View
TEAF Planner Owner Designer Builder
TOGAF Business Technical Architecture
Architecture Views
View

As noted, the abstractions comparison is less DoDAF: The Operations View is the ‘business’
quantifiable (see Table 2). Most of the EAFs studied, being undertaken by the military. This depicts
provide recommendations for what each of the activities performed as parts of DoD missions, i.e.,
abstractions represent, but do not provide methods, the exchanges among organizations or personnel, and
procedures, or deliverables that are required. All of reveals the requirements for interoperability and
the EAFs in our study included information in what capabilities. The Systems View describes the actual
data was needed and the functionality of the data and existing and future systems that support the DoD and
system. The frameworks started to differ when how they are physically interconnected. The
comparing the technology and physical aspects of the Technical View or Technical Standards View adds
system, with some providing detailed architectures detail to the Systems View by providing information
whereas others were not as specific. In the people on standard system parts or components that are
abstraction, the frameworks provide the currently available off the shelf, either commercially
organizational relationships related to or government, and also provides technical detail and
implementation of the system. Timelines and forecasts of standard technology evolution that may
justification for the system, as can be represented in apply to the architecture. The DoDAF defines 26
the Time/When and Motivation/Why abstractions different architecture products that are organized into
respectively, were only found in Zachman’s the four views [3].
Framework.

Volume VII, No. 2, 2006 20 Issues in Information Systems

 A Comparison of Enterprise Architecture Frameworks

Table 2. Comparison by Abstractions

Framework What How Where Who When Why

Zachman Data Function Network People Time Motivation
DoDAF Data (mission) Function / Physical Organizational
Logical Data Traceability connectivity plus Relationships
Model Functional availability of off-
effectiveness the-shelf solutions
FEAF Data Applications Technology
Architecture Architecture Architecture
(entities=what) (activities = how) (locations = where)
TEAF Information Functional View Infrastructure View Organizational
View View

TOGAF Decision-making IT resource

guidance guidance

FEAF: Currently, the FEAF corresponds to the first architecture principles. The framework is gauged
three columns of the Zachman Framework and the towards open systems development.
Spewak Enterprise Architecture Planning (EAP)
methodology. The FEAF contains guidance and is Comparison with the Systems Development Life
oriented toward enterprise architectures as opposed to Cycle
IT architectures. The rows of the FEAF matrix
correspond to the Zachman Framework, but they do It is very important to address whether or not the
not prescribe the approach for developing the framework encompasses the entire Systems
products for each of the cells. Development Life Cycle (SDLC). The frameworks
presented can be compared to the 5 phases commonly
TEAF: TEAF can be described in terms relative to used in SDLC models: Planning, Analysis, Design,
the Zachman Framework, i.e., ‘perspectives’ and Implementation, and Maintenance (see Table 3).
‘views.’ The four perspectives are the same as in the Overall, the frameworks do not specify HOW the
Zachman Framework and FEAF matrix with the system is to be developed, i.e., tools and work
exception that TEAF combines the ‘Builder’ and products, and in general are weighted towards
‘Subcontractor’ into one, named ‘Builder.’ Also, the planning and analysis, ensuring that all views are
TEAF Information view corresponds to the FEAF addressed. The frameworks provide the guidance that
Data Architecture; the TEAF Functional view is then implemented in the SDLC.
corresponds to the FEAF Applications Architecture;
and the TEAF Infrastructure view corresponds to the One might question how the scope/planner and the
FEAF Technology Architecture. FEAF does not subcontractor views are incorporated into the SDLC?
currently reflect the TEAF Organizational view. This Those aspects of the framework assist the enterprise
view shows the types of workers and the in minimizing those risks as outlined earlier, when
organizational structures. TEAF allows the flexibility one may not view the enterprise in its entirety, i.e.,
to define additional views and perspectives that focus designing a system that doesn’t meet the underlying
uniquely on areas important to specific stakeholders. objective. The ‘view’ will determine the requirements
TOGAF: Strong on the Business Architecture and necessary in order to be deemed successful. As
Technical Architecture aspects. It does not provide as discussed previously, the frameworks tend to be
much detail from the planning and maintenance heavy on the planning, since their objective is more
aspects. TOGAF is one of the most comprehensive to provide guidance. It was found that most if not all
with regards to the actual process involved. This frameworks were weak in addressing the
framework provides guidance towards principles for maintenance of an information system.
decision making, guidance of IT resources, and

Volume VII, No. 2, 2006 21 Issues in Information Systems

A Comparison of Enterprise Architecture Frameworks

Table 3. Comparison by SDLC Phases

SDLC Phase/ Planning Analysis Design Implementation Maintenance

Framework
Zachman Yes Yes Yes Yes No
DoDAF Yes Yes Yes Describes final products No
FEAF Yes Yes Yes Yes Detailed
Subcontractor’s View
TEAF Yes Owner’s Yes Yes No
Analysis
TOGAF principles that support decision making across enterprise;
provide guidance of IT resources; support architecture
principles for design and implementation

CONCLUSIONS Available: www.defenselink.mil/nii/

doc/DoDAF_v1_Volume_I.pdf
Many of the enterprise architecture frameworks differ 3. DoDAF (2005). DoDAF. Systems & Software
in terms of their approach and level of detail. Some Consortium. Available:
are proposed guidelines, whereas others have specific www.software.org/pub/architecture/dodaf.asp
methodologies and aspects to follow. The majority of 4. FEA (2001). Federal Enterprise Architecture –
the frameworks are abstract in that due to their Practical Guide, version 1.0, February 2001.
generality of terms, one might then question the Available:
validity or the ability to work accurately within that https://secure.cio.noaa.gov/hpcc/docita/files/a_p
framework. The Zachman framework appears to be ractical_guide_to_federal_
the most comprehensive framework of those studied. enterprise_architecture.pdf
It uses a number of viewpoints related to the different 5. FEAF (1999). Federal Enterprise Architecture
aspects. Most frameworks only represent a small Framework, Version 1.1, September 1999.
number of viewpoints and aspects. In this paper we Available: https://secure.cio.noaa.gov/
report of an effort to compare EAFs based on their hpcc/docita/files/federal_enterprise_arch_frame
coverage of different viewpoints and aspects. Some work.pdf
of the frameworks do not clearly ‘map’ to the idea of 6. Goethals, F. (2003). An Overview of Enterprise
‘viewpoints’ and “aspects” e.g., the rows and Architecture Framework Deliverables. May
columns of the Zachman framework, therefore 2003. Available:
making the comparison of the frameworks difficult. www.econ.kuleuven.ac.be/leerstoel/sap/Frames
The major contribution of this study is a possibility to Page.htm
use it as guidelines in selecting an EAF and 7. Iyer, B. & Gottlieb, R. (2004). The Four-
determining a best-fit of a framework dependent on Domain Architecture: An approach to support
specific stakeholder needs for a given project. This is enterprise architecture design. IBM Systems
important to minimize risk or failure of an Journal, 43(3), 587-97.
information system development process. Our plan is 8. Schekkerman, J. (2003). How to Survive in the
to expand this research to include more quantifiable Jungle of Enterprise Architecture Frameworks:
measures as well as additional frameworks to better Creating or Choosing an Enterprise
assist in the determination of a framework to meet Architecture Framework. 2nd edition, ISBN 1-
specific organization needs. 4120-1607-x, 2003, Oxford: Trafford
Publishing.
REFERENCES 9. Sowa, J. & Zachman, J. (1992). Extending and
Formalizing the Framework for Information
1. Clinger-Cohen Act of 1996 (1996). Available: Systems Architecture, IBM Systems Journal,
www.tricare.osd.mil/imtr/ 31(3), 590-616.
ppm/documents/clingercohen.pdf 10. Tang, A., Han, J., Chen, P. (2004). A
2. DoD Architecture Framework (2004). Version Comparative Analysis of Architecture
1.0. Volume 1: Definitions and Guidelines. Frameworks, School of Information
Technology, Centre for Component Software &

Volume VII, No. 2, 2006 22 Issues in Information Systems

 A Comparison of Enterprise Architecture Frameworks

Enterprise Systems, Swinburne University of 13. Van den Hoven, J. (2004). Data Architecture
Technology, Technical Report: SUTIT- Standards for the Effective Enterprise.
TR2004.01, CeCSES Centre Report: Information Systems Management, 21(3), 61-4.
SUT.CeCSES-TR001, August 25, 2004. 14. Zachman, J. (1987). A Framework for
11. TEAF (2005). TEAF. Systems & Software Information Systems Architecture,IBM Systems
Consortium. Available: Journal, 26(3), IBM Publication G321-5298.
www.software.org/pub/architecture/teaf.asp 15. Zachman, J. (1999). A Framework for
12. The Open Group Architectural Framework Information Systems Architecture. IBM Systems
(2005). Welcome to TOGAF. Available: www. Journal, 38(2-3), 454-70.
opengroup. org /architecture/togaf7-doc/arch/

Volume VII, No. 2, 2006 23 Issues in Information Systems