Comparison of the top 4 EA methodologies (R. Sessions)
The field of EA initially began to address 2 problems (ca. 20 years ago):
• System complexity – organisations are spending more and more money building IT systems;
• Poor business alignment – organisations are finding it more and more difficult to keep those
increasingly expensive IT systems aligned with business need.
Bottom line: more cost, less value. Costs and complexity of IT systems have exponentially increased,
while chances of deriving real value from those systems dramatically decreased. Today, there is even
more cost, even less value. 90% of the field uses one of these 4 methodologies for EA:
1. The Zachman Framework for EA – more of a taxonomy than a framework.
2. The Open Group Architectural Framework (TOGAF) – better defined as a process.
3. The Federal EA (FEA) – viewed as an implemented EA or as a proscriptive methodology for
creating an EA.
4. The Gartner Methodology – best described as an enterprise architectural practice.
How should a company choose from among these 4 very different approaches to EA? When examining
them, you will see that none of these approaches is complete: each has strengths in some areas and
weaknesses in others. None of them will be a complete solution for a lot of enterprises. For those
enterprises, another approach is proposed: the blended methodology. Choose bits and pieces from
each of these methodologies and modify and merge them to specific 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 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. If managing
system complexity and delivering business value are key priorities for you, you should care about EA
methodologies. If you are focused on maintaining, or rebuilding, IT’s credibility in your organisation,
or if you strive to promote the use of IT to maintain a competitive position in your industry.
As systems become more complex, they require more planning. This holds for buildings, cities, and
information systems. Building a simple, single-user system, you don’t need an architect, but while
building an enterprise-wide, mission critical, highly distributed system, you will need a database
architect, a solutions architect, a business architect and an enterprise architect.
The responsibility of the enterprise architect is developing the overall architectural vision for an
organization. This architect specializes in the broadest possible view of architecture within the
enterprise. The architect’s architect is responsible for coordinating the work of all other architects.
Having an enterprise architect doesn’t guarantee a successful EA, but merely improves the chances.
Architect One whose responsibility is the design of an architecture and the creation
of an architectural description.
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 defining 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 describing any structured approach to solving some or all the
problems related to architecture.
Architectural process A defined series of action 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 relationship 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 if the whole enterprise,
especially the business processes, technologies, and IF of the enterprise.
1. The Zachman Framework for Enterprise Architectures
The Zachman ‘Framework’ is actually a taxonomy for organizing architectural artifacts that takes into
account both who the artifact targets and what particular issue is being addressed. Zachman: “The
[EA] 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.”
The IT taxonomy organises architectural artifacts using a 2 dimensional organisation. One dimension
is the various ‘players in the game’. Every player demands complete information, but what constitutes
completeness differs for the different players. Each of the architectural representations differs from
the others in essence, not merely in level of detail. The 2nd dimension for architectural artifact
organization is the descriptive focus of the artifact: the what, how, where, who, when, and why of
the project. Zachman proposes 6 descriptive foci (data, function, network, people, time, and
motivation) and 6 player perspectives (planner, owner, designer, builder, subcontractor, and
enterprise). These can
be arranged in a grid:
All perspectives on, for
instance data, are
critical to a holistic
understanding of the
system’s architecture.
It’s not that one of
these perspectives is
better than the other
or more detailed. All
the architectures are
different, but additive
and complementary
to each other: there
are reasons for
developing each architectural representation, and risks associated with not doing so.
There are 36 intersecting cells in a Zachman grid, one for each meeting point between a player’s
perspective and a descriptive focus. Moving horizontally in the grid, you see different descriptions of
the system from the same player’s perspective, while moving vertically gives a single focus, but
changes the player from whose perspective that focus is viewed. There are 3 suggestions:
, (1) Every architectural artefact should live in only one cell. If it’s unclear in which cell a particular
artifact lives, there is most likely a problem with the artifact itself. The Zachman grid can be used
to clarify the focus of each of the artifacts.
(2) An architecture can be considered a complete architecture only when every cell is complete. A
cell is complete when it contains sufficient artifacts to fully define the system: the appropriate
artifacts, the sufficient amount of detail.
(3) Cells in columns should be related to each other. Although they are very different, there should
be a relationship between the perspectives. The database design should be driven by the business
requirements.
2. The Open Group Architecture Framework (TOGAF)
TOGAF’s view on EA is as follows:
1. Business architecture – describing the processes the
business uses to meet its goals.
2. Application architecture – describing how specific applications are designed and how they
interact with each other.
3. Data architecture – describing how the enterprise datastores are organized and accessed.
4. Technical architecture – describing the hardware and software infrastructure that supports
applications and their interactions.
TOGAF is a framework, but its most important is the Architecture Development Method (ADM), a
recipe/process for creating architecture. Given that ADM is the most visible part of TOGAF, it can also
be categorized overall as an architectural process. As an architectural process, TOGAF complements
Zachman: Zachman (taxonomy) tells you how to categorize your artifacts, TOGAF gives you a process
for creating them.
TOGAF sees the world of EA as a continuum of architectures, ranging from highly generic to highly
specific: the Enterprise Continuum. It views the process of creating a specific EA as moving from
generic to the specific. From generic to specific:
• Foundation Architectures – architectural principles that can theoretically be used by any IT
organization in the universe.
• Common System Architectures – principles that one would expect to see in many types of
enterprises, but perhaps not all.
• Industry Architectures – principles specific across many enterprises that are part of the same
domain (all pharmaceutical enterprises).
• Organizational Architectures – architectures that are specific to a given enterprise.
There are various knowledge-bases defined that live in the Foundation Architecture, such as the
Technical Reference Model (TRM) and the Standards Information Base (SIB). TRM is a suggested
description of a generic IT architecture. SIB is a collection of (pseudo-)standards to consider in building
an IT architecture. TOGAF presents both TRM and SIB as suggestions, neither is required.
TOGAF ADM consists of 8 phases that are cycled through:
