A Comparison of the Top Four
Summary: Twenty years ago, a new field was born that soon came to be known as enterprise architecture.
This paper covers a broad introduction to the field of enterprise architecture. Although the history of the
field goes back 20 years, the field is still evolving—and rapidly so. (36 printed pages)
A Brief History of Enterprise Architecture
The Zachman Framework for Enterprise Architectures
The Open Group Architecture Framework (TOGAF)
Federal Enterprise Architecture (FEA)
Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field
initially began to address two problems:
System complexity—Organizations were spending more and more money building IT systems;
Poor business alignment—Organizations were finding it more and more difficult to keep those
increasingly expensive IT systems aligned with business need.
The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached
a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of
deriving real value from those systems have dramatically decreased.
Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore
these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today
seems powerfully prophetic.
Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point,
perhaps 90 percent of the field use one of these four methodologies:
The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is
actually more accurately defined as a taxonomy
The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually
more accurately defined as a process
The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise
architecture or a proscriptive methodology for creating an enterprise architecture
The Gartner Methodology—Can be best described as an enterprise architectural practice
This white paper discusses these four approaches to enterprise architecture. It does so within the context
of a fictional company that is facing some very nonfictional operations problems. These problems include:
IT systems that have become unmanageably complex and increasingly costly to maintain.
IT systems that are hindering the organization's ability to respond to current, and future, market
conditions in a timely and cost-effective manner.
Mission-critical information that is consistently out-of-date and/or just plain wrong.
A culture of distrust between the business and technology sides of the organization.
How should this company choose from among these four very different approaches to enterprise
architecture? This white paper traces the journey the company is likely to face in using any one of these
When examining each of these methodologies in depth, one is struck by the fact that none of these
approaches is really complete. Each has strengths in some areas and weaknesses in others.
For many enterprises, none of these methodologies will therefore be a complete solution. For such
organizations, this white paper proposes another approach, one that might be called a blended
methodology. Choose bits and pieces from each of these methodologies, and modify and merge them
according to the specific needs of your organization. This white paper gives an approach to creating such
a blended methodology that is a best fit for your organization's needs.
But even a blended methodology will only be as good as an organization's commitment to making
changes. This commitment must be driven by the highest level of the organization. The good news is that,
with a real commitment to change and a tailored methodology for guiding that change, the 20-year-old
promise of enterprise architecture is within reach.
That promise hasn't changed: reducing IT cost and complexity, while increasing business value and
effectiveness—or, to put it even more simply, improving your competitiveness in an increasingly
The year 2007 marks the 20-year anniversary of enterprise architecture. In that time, a number of
enterprise-architectural methodologies have come and gone. Today, four dominate the field: the
Zachman Framework for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the
Federal Enterprise Architecture (FEA), and Gartner (formerly, the Meta Framework).
Should you care about a field that is 20 years old? It depends. This field was inaugurated to address two
major problems in information technology (IT) that were then already becoming apparent. The first
problem was managing the increasing complexity of information-technology systems. The second
problem was the increasing difficulty in delivering real business value with those systems.
As you can imagine, these problems are related. The more complex a system, the less likely it is that it will
deliver maximum business value. As you better manage complexity, you improve your chances of
delivering real business value.
So, should you care about this field? It depends on how you feel about positively affecting your
organization's bottom line. If managing system complexity and delivering business value are key priorities
for you, you should care about enterprise-architecture methodologies. If you are focused on maintaining,
or rebuilding, IT's credibility in your organization, or if you strive to promote the use of IT to maintain a
competitive position in your industry, you should continue reading this white paper. If these issues don't
concern you, these methodologies have little to offer.
As systems become more complex, they generally require more planning. It is easy to see this in buildings.
When Henry David Thoreau built his little cabin on Walden Pond (shown in Figure 1), he embraced
simplicity and needed no architects. If you are building New York City (shown in Figure 2), simplicity is out
of the question, and you will need many architects.
Figure 1. Thoreau's cabin at Walden Pond, as drawn by Thoreau's sister, Sophia Thoreau
Figure 2. New York City
The relationship between complexity and planning for buildings and cities is similar for information
systems. If you are building a simple, single-user, nondistributed system, you might need no architects at
all. If you are building an enterprise-wide, mission critical, highly distributed system, you might need a
database architect, a solutions architect, an infrastructure architect, a business architect, and an enterprise
This paper is about the methodologies needed to develop the overall architectural vision for an
organization. This is the responsibility of the enterprise architect. This is the architect who specializes in the
broadest possible view of architecture within the enterprise. This is the architect's architect, the architect
who is responsible for coordinating the work of all of the other architects. Do you need such an architect?
It all depends on what you are building: Thoreau's cabin or New York City.
Building a large, complex, enterprise-wide information system without an enterprise architect is like trying
to build a city without a city planner. Can you build a city without a city planner? Probably. Would you
want to live in such a city? Probably not.
Of course, hiring a city planner does not guarantee a livable city; it merely improves your chances.
Similarly, having an enterprise architect does not guarantee a successful enterprise architecture. There are
many examples of failed enterprise architectures in the world today, and all of them had enterprise
architects (probably dozens!). Architectural methodologies can help, but they go only so far. I'll discuss
some of the reasons for these failures, and how to avoid them, also in this paper.
Before I get too far into comparing the methodologies that make up the enterprise architect's toolkit, I
need to define some terms. This is especially important in an article that is comparing methodologies,
because the different methodologies sometimes use similar terms to mean different things.
For example, we have two methodologies that describe themselves as enterprise-architectural
frameworks: the Zachman Framework for Enterprise Architectures and The Open Group Architectural
Framework (TOGAF). Yet these two methodologies share little in common other than the
words enterprise, architecture, and framework.
So, I will start by defining the terms as I will use them in this white paper. Those definitions marked with
an asterisk (*) are taken mostly from IEEE-1471-2000 , whose definitions I use where they exist and
architect—One whose responsibility is the design of an architecture and the creation of an architectural
architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to
an architectural description
architectural description*—A collection of products (artifacts) to document an architecture
architectural framework—A skeletal structure that defines suggested architectural artifacts, describes
how those artifacts are related to each other, and provides generic definitions for what those artifacts
might look like
architectural methodology—A generic term that can describe any structured approach to solving some
or all of the problems related to architecture
architectural process—A defined series of actions directed to the goal of producing either an
architecture or an architectural description
architectural taxonomy—A methodology for organizing and categorizing architectural artifacts
architecture*—The fundamental organization of a system embodied in its components, their
relationships to each other, and to the environment, and the principles guiding its design and evolution
enterprise architecture—An architecture in which the system in question is the whole enterprise,
especially the business processes, technologies, and information systems of the enterprise
Now that we have a common understanding of these key terms, I can take you through the history of
enterprise-architecture methodologies, discuss the problems these methodologies are trying to solve, and
compare the top four methodologies in terms of their approach and their relationship to each other.
A Brief History of Enterprise Architecture
The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems
Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman. In that
paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide
the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed
systems. As Zachman said:
The cost involved and the success of the business depending increasingly on its information systems
require a disciplined approach to the management of those systems. 
Zachman's vision was that business value and agility could best be realized by a holistic approach to
systems architecture that explicitly looked at every important issue from every important perspective. His
multiperspective approach to architecting systems is what Zachman originally described as an information
systems architectural framework and soon renamed to be an enterprise-architecture framework.
Zachman was a major influence on one of the earliest attempts by a branch of the U.S. Government, the
Department of Defense, to create an enterprise architecture. This attempt was known as the Technical
Architecture Framework for Information Management (TAFIM)  and was introduced in 1994.
The promise of enterprise architectures, such as TAFIM, to better align technical projects with business
need was noticed by no less a body than the U.S. Congress. Most likely influenced by the promised
benefits of TAFIM, Congress in 1996 passed a bill known as the Clinger-Cohen Act of 1996 , also
known as the Information Technology Management Reform Act, which mandated that all federal agencies
take steps to improve the effectiveness of their IT investments. A CIO Council, consisting of CIOs from all
major governmental bodies, was created to oversee this effort.
In April 1998, the CIO Council began work on its first major project, the Federal Enterprise Architecture
Framework (FEAF). Version 1.1  of this framework was released in September of 1999. This document
contained some innovate ideas, such as "segmented architectures"—that is, architectural focus on
segmented subsets of the larger enterprise.
Over time, responsibility for federal enterprise architecture moved from the CIO Council to the Office of
Management and Budget (OMB). In 2002, the OMB evolved and renamed the FEAF methodology as the
Federal Enterprise Architecture (FEA). I will describe FEA in greater detail, in the section dedicated to it.
Despite the very significant enterprise-architectural activity in the Federal Government (one could argue
that no organization has spent more money attempting to develop an enterprise architecture than the
U.S. Government), progress has been slow and success stories are overshadowed by higher-profile
failures. In 2004, a full eight years after the Clinger-Cohen Act mandated the use of effective IT planning
processes, the General Accounting Office (GAO) reported the following:
Only 20 of 96 agencies examined had established at least the foundation for effective architecture
management. Further, while 22 agencies increased in maturity since 2001, 24 agencies decreased in
maturity and 47 agencies remained the same. 
Since January of 2005, the General Accounting Office (GAO, not to be confused with the OMB) has
severely chastised a number of U.S. agencies for failures in their adoption or use of enterprise
architecture. A few examples include the FBI , the Department of Defense , the Department of
Homeland Security , and NASA .
In 1998, four years after TAFIM (remember TAFIM?) was introduced and two years after it became codified
as Clinger-Cohen, TAFIM was officially retired by the Department of Defense.
The work done on TAFIM was turned over to The Open Group. They morphed it into a new standard that
is today known as The Open Group Architectural Framework—better known by its acronym, TOGAF. I will
discuss the TOGAF work in the section dedicated to that topic.
In 2005, about the same time that OMB was becoming the dominant EA force in the public sector,
another organization was taking steps to become a dominant force in the private sector. This group was
By 2005, Gartner was already one of the most influential organizations specializing in CIO-level consulting.
However, in the specific area of enterprise architecture, the best known IT research and advisory group
was not Gartner, but Meta Group.
Gartner had struggled to build an enterprise-architecture practice, but never achieved the status of the
Meta Group. In 2005, Gartner decided that if they couldn't compete with Meta Group, they would do the
next best thing: They would buy it.
Following the purchase of Meta Group, Gartner/Meta spent a year looking at what each company brought
to the table as far as enterprise-architecture experience and methodologies. The two companies discussed
how best to reconcile their often quite different approaches.
In the end, a fairly simple algorithm was applied: If Meta Group liked it, it was in; if Meta Group didn't like
it, it was out. Gartner liked architectural frameworks. The Meta Group liked architectural process. So,
frameworks were out; processes were in. I'll discuss this Gartner/Meta process in detail, in the section
devoted to Gartner.
Figure 3 summarizes this history with an enterprise-architecture timeline. This brings us up to date in the
history of enterprise architecture. Now, let's look more closely at today's main methodologies and
introduce a case study that will be used in this white paper.
Figure 3. Enterprise-architecture timeline
So that we can compare and contrast the four major approaches to enterprise architectures, I am going to
illustrate how each would approach a similar scenario. This fictitious scenario is a composite of several
enterprises with which I have worked over the past several years. So, while it is fictitious, it is very realistic.
I'll first describe the scenario.
MedAMore is a chain of drug stores. It started as a regional chain in 1960. In 1995, it developed an
innovative software system that enabled it to run drug stores very efficiently. It called this system
MedAManage, or MAM. MAM incorporated some innovate business ideas, such as patient-relationship
management, inventory management, automated insurance billing, and even utility optimization.
MAM consisted of three programs: MAM/Store, which ran on a small computer at a drug store;
MAM/Warehouse, which ran on a server in a regional warehouse; and MAM/Home, which ran on a large
server at the home office.
These three programs communicated through files that were transferred from one location (for example,
a store) to another (for example, a regional warehouse). When reliable communications lines existed, file
transfers could occur through FTP. The system was also flexible enough to accommodate transfers
through courier, where necessary.
By 2000, MedAMore was doing quite well—in part, because of the cost-cutting moves enabled by the
MAM system. MedAMore decided to begin expansion. To do this, it purchased three regional chains. With
these purchases, MedAMore extended its reach through the southeast quadrant of the U.S.
By 2002, it was clear that the same software systems that had initially fueled MedAMore's success were
now hampering its future. Some of the problems MedAMore was running into were the following:
MAM/Store required regional specializations. For example, different insurance plans needed to be
supported in different regions, and these all required changes to the MAM/Store module.
The regional warehouses that had been acquired through acquisition each had different ways of
receiving orders from the retail stores and different procedures from ordering supplies from the
wholesalers. Each of these differences required changes to the MAM/Warehouse module.
The file-transfer approach to information sharing that had worked so well when MedAMore
consisted of 30 drugstores, one regional warehouse, and one home office were turning out to be
difficult to coordinate among 200 drugstores, four regional warehouses, two geographic offices,
and one home office. Files were often delivered late, sometimes not at all, and occasionally
multiple times. This made it difficult for the home office to access reliable, up-to-date financial
information, especially in the areas of sales and inventory.
It was clear to MedAMore management that the MAM system needed many enhancements. However,
upgrading this system was difficult. Each of the three modules (store, warehouse, and home office) was
huge, inefficient, and cumbersome, and each included functionality for everything that each entity might
The modules had grown to over 1 million lines of code each. It was difficult to change one function
without affecting others. All of the functions accessed a single database, and changes to one record
definition could ripple through the system in an unpredictable fashion. Changing even a single line of
code required a rebuild of the entire multimillion-line module.
MedAManage had become MedANightmare. Debugging was difficult. So ...
Purchase answer to see full