How 10 5U roitofo in Iht junglt

of Enltrprist Archittdurt F"ltnnrorb

How to survive in the jungle of

Enterprise Architecture Frameworks

Creating or choosing an
Enterprise Architecture Framework

Jaap Schekkerman

Second Edition

IRAAORD
2004
Th.1. .

-3-

On e

How to SUI't7lVt in Iht junglt

of Enltrpri~ .... rchittdurt Fmmnoorb

Content
1
} ,1

Iolroductjon "" """"" " " """"""""""" """"" "" """"""""""" """"""""" """ ... 13

1.2

The holistic view ""." ....." ." ......... " ............ " ..... " ."..... " ..".".. " .".... "" ' ... " ........ 13

...
....

....

.."

....

."

.."

....

,,"

....

.....
...

.....
"

....

....

...

","

Val ue Net BaSEd Asst?:SS!!!ent ... "" ...... " ......... " ... "" ... "" ... "" " ... ...... 47
MfllIs! rement and Yab If' lion "..... ".".................... ...... '" ............ " ............'" ... '" ,48

...
.".

"

"

...

.....

.....
.....

..
..

""

""

.."
-9-

Crtating or Choosing an

13.2
13.3
13.4
13.5
13.6

EnlD'J'ri~ Archilfurt

FrAmtwOrt

. ,............. ,... ,......... ,...... ,.......... ,.. ,... ,......... ,........................ ,.. _.........91

........... ,.. ,...... ,...... ,....................... ,... ,.................... ,.......... ,................. _.92
Prinei Ies. ...... ,... ,.......................... ,...................................................._ ........93
Stn .rll! re ...................... '" '" .... '" .... '" '" ........ "' .... '"

"'

..... 96

.... " ' .. .. " ' ..

G ujdaOCP " .. ,... ,.. ,... ,.. ,... ,.. " .. ,.. ,.. "." .. " .. ,.. ,... ,.. ,.. ,... ,...... ,,.. ,.. " .. ,,,,, .. ,, ..,, .. ,... ,.99
"

..

..

"

..

....
....

.....
.....

....

....
....
." .

... ,

...

....
....
.....
...

... ,

....

,'"

'"

..

""

"

....

...
" ..

..
" ...

"

"

....
.....

....
....
....
....

"

... ..

.. .. ,
,,,..

....
....
" ..

'"

...

"

...

....
.... ,
....
" ...

.....
... ,
" ..
.....

,""

""

""

""

...
....
"'.
Guidance., ... ,.. ,...... ,... ,.. ,... ,.. ,.. ,.. " .. ,... ,.. ,.. " .. ,.. ,.. ,'''' ...... ,' .. ,... ,.. " ..... ,,,,",,,,,,, 109
" '"

....

16.6
16,7

....
.."
... ,

.."
,,,.
.."

....
....
... ,

....

....
.."
" ...

....
... ,

....
....

....
....

.,,"

""

.."

....
....
" ..
"'''
Guidance ...... "., .. ,,,., .. ,,,., .. ,"'''',,.,,,.... ,'', .. ,''', ...... ,,,., ......... ,, ..... ,....... ,..... ,.... 117
Compliance ." .. ,"', .. ,... ,.. ,.. ,... ,.. ,., .......... ,................ ,.................................... 117

.. ' "

17.6

....

.'"

Guidance .".. ,.............................................................................................. 124

...

...

....

""

..

"."

.."
....
.."

.."

....

,,,.

""

"

...

.."

....

....
.."

"

...

...
....

.."

.... .. .." .."' .. " ' " " ' ' ' '. ' ' '' ' ' .. "'" '" .... '" "''''''''...." 135
CompliallCe",,,., .. ,...... ,.,,, .. ,.,, .. ,.. ,,,,, .. ,.. ,,,,,,., ... ,... ,,,,,., ... ,... ,.. ,...... ,... ,", ...... ,137
.. ..

.. ..

"

'"

-10 -

How to survitot in tht jungft

19.6

,.

19.7

20.1
20.2
20.3

20.4
20.5
20.6

of Enlerprist IIrrhiltduTt Framnoorb

""

""

...

" ,

.. "

"

"

" .

.. " " " ' . " ' " " " " . " " " " " . .. 143
Com liance ................................................................................................ 143
Joint Tt'Chnkal Architecture
........................................................................................................ 145
................................... " .. " ................................... " ........ "." ........... t 47
Scope..................................................................,................ ,.......................149
PrindpJes...,... ,.. ,.. ,.. ,...... ,.. ,... ,.. ,... ,..... ,... ,.. ,.. ,... ,.. ".. ,.. ,...,.. ,.. ,...... ,...... ,......... 149
Sin cute .. ..
..
..
..
..
..
..
..
150

Gl!jda na>
152
.
....
.....
....
.... ..
...
..
...
...
".

Gujdance ".

" " " ,",

'"'

" "

" "

'

(J!A}-.--.-.-----.---

" ,

" ,

" ,

" ,

" ,

" , ,,,

" ,

" ,

" , , , ,

....

.....

." .

....
....
....
....

....

""

" ,,"

..

....
...

.....

....
.....
....
..".

.....
.....

" ,

" ,

..

.....

" ,

'"

....

....

....

".

'"

.,, '

.....

....
....
....
....
....
..
..
" ..
Compliance.,.. "." .. ,.. ,... ,.. ,... ,.. ,.... ,.. " .. ,.. ,.. ,... ,...... ,.. ,..... " .. " .. ,.. ,.. ,... ,........... 162
"

22.
227
23

....

".,

"

.,,'

""
,,'

"".

"

."

...

....

""

.....

..

"

..

.."

.....

"

...

'"

G uidance ".,,,, ... ,.,, .. ,.. ,... ,,,,,,,,,.,,,, .. ,,,,,.,,,,,,,,,,,,,,,.,, ... ,.. ,.", ... ,.. ,,,, ...... ,,,, .... ,, I(IiJ

Compliance ....... ,,,,.,, .. ,,,, ... ,.. ,... ,,, .. ,,.,,.,, .. ,.. ,,.,, .. ,, .. ,.. ,..... " .. " .. ,.. ,.. " .. ,.. ,... ,,, 171
An;hlt~ture fnmework fo, Inlonn .. tion M.n.lgement

ITAFIM).........." " ............

.....

....

" M. ." H. . . . . . . . . . . _

. . .. .. . .. . "

....

....
....
....

n '

",

... ,

.."

....
.....

....
" ..

. . . . ." . ". .M ". . . . . . _

""

... ,

....

....,

....

,... ,

...

....
....

.....

. H . M. . . " , , , , , , ,

" ....M173

....
.....
...

....

...

... ,

....

....

.....
....

n ...

.....

...
" ..

....

....

...

....
....

....

11

.."

....
.."

....

....

CfflI ting "r CMming Qn

25.'
25.5

Ent"pri~

Arr:hittdl4 rt Fmmnoort

Princi Ies... ................................................................................................... 186

" ....... 1M
StnK1me
.....
.......' .. " . ... ..........

.....

"

"

...

Gujda nce ..

...

..
....
"

"

"

27. 1

27.2

....
....
.....

....

266
26,7

..

"

"

... ...

"

"

"

" ,," " ,," ,," ,,"

...,

.....

..... ,." .. " .. ,...... ,............. ,... ,.. ,... ,,, ....,,, ... 197
Compliancy,.. ,... ,.. " .. ,.. ,........... " ...." ..... " ."." .." ....." ......... "."..".".." .......... 198
................

G " jdance ......

"

Enlerprise Architecture Tools ...................................................................... 201

Intnxluction ............................................" .. " .." .....""..." ..... ".".""".."."...201
Review."." ." .." ...." .................................201

....

....

.."

"

... "

....

" "

...

""

....

"

..

.."
.."
....

"

...

..
31

R . liltall.ink .

32

About the Author ..

"

.......

"

...

"

"

... " " " "

"

.. " .. " " .. " .. " " " " " "

.. 12 ..

"

""

.."

..."
..."

.....
....

............ ...................................._..............
"

..

....
....

....

....
....

. . ...... . "

__.

. ....... " ' my

"

219

Huw 10 5UI'IrivI! irr tht jurrglt of Errtnprist Archiltdurt' Frtlmnvom

What is Enterprise Architecture about?

1.1

Introduction

This chapter discusses Enterprise Architectures as they relate to

the broad decisions that must be made by organisations to
compete or survive in an ever-changing world. The concept of
Enterprise Architecture has been defined and discussed
variously in extant articles and in practitioner and research
publications for the last years. Let us take a look to a holistic
view of diverse interpretations.

1.2

The holistic view

Enterprise Architecture is a complete expression of the

enterprise; a master plan which "acts as a collaboration force"
between aspects of business planning such as goals, visions,
strategies and governance principles; aspects of business
operations such as business terms, organisation structures,
processes and data; aspects of automation such as information
systems and databases; and the enabling technological
infrastructure of the
Enterprl_ Stratel1lc
business such as
AlIlI"ment
computers,
Business
_. Technology
operating systems
Strategy
Strategy
and networks.
In a large modem
enterprise,
a
rigorously defined
Operational
Technology
framework
is
Capabilities .....~ Capabilities
necessary to be able
Enterprl_ ,..to capture a vision
Impt'Ov.m.llt
of
the
"entire

. 13
P'

W~

Crmtin8 or Choosing lin Enterprise ArdiittCilirt Fnlmt um*

organisation " in all its dimensions and complexity. Enterprise

Architecture (EA) is a program supported by frameworks, which
is able to coordinate the many facets that make up the
fundamental essence of an enterprise a t a holistic way.

1.3

Enterprise Architecture Program

Enterprise Architecture provides a mechanism that enables

communication about the essential elements and functioning of
the enterprise.
It yields centralized, stable, and consistent information about the
enterprise environment. In an insurance company, for example,
an EA would help executives pinpoint the companies more
lucrative markets, understand how well the company's current
resources are meeting customer needs in those locations, and
determine what kind of systems might be needed to improve

serv1ces.
The precise, high-quality information an EA provides also makes
it much easier for the organisation to respond to the forces of
change and make better decisions. And finally, because an EA
enables organisations to reduce duplication and inconsistencies
in information, they can dramatically improve ROJ for future IT
implementations common architecture information and building
a repository to store it.

Focusing on Enterprise Architecture is focusing added value to

the business in terms of ROI [Return on Information] and at the
same time streamlining the teclmology to reduce complexity and
costs.

- 14P'

How 10 SUrvfvr in I~ iung~of Entnprist Archikdure Frameworks

Technolog~y-:--=---;'; ;"-~'
ReducHon 01 Complexity & Coals
This EA program addresses at a holistic way the elements of
stra tegy, frameworks, the overall EA process, methods &:
techniques, standards and tools. In this book, the focus is on EA
frameworks and the area of popular EA tools.

St,..tegy

EA Program and its elements

- 15 -

Crtflting or Choosing olin Enlrrprise Ardriltcturl Fr,gmnoort

1.3.1

Analogy

7here is a paraUel between Enterprise Architecture design atld city

planning. City planners must design in the face of many unknowns,
such as future transportation techtlologies, changing work, living, and
commuting pattems, atld so on... "As a result of this level of planning,
our major cities are able to accommodate new tech1l01ogies for
transportation and communication which remain viable for hundreds of
years, and which make a major contribution to eQch city's brand of
urMn culture." {Nolan and Mu1ryan , 19871

1.4

Fundamental Enterprise Architecture Principles

- Always design a thing by considering it in its overall

context
A fundamental principle that can be applied to Enterprise
Architecture is: "Always design a thing by considering it in its
next larger context - a chair in a room, a room in a house, a house
in an environment, an environment in a city plan." fSaaritltn,
19561
Enterprise Architecture maps the design of the larger context
(i.e. the enterprise) within which organisational design, business
process reengineering. systems design, technology infrastructure
design and data analysis, should be considered. Also, the
Enterprise Architecture is part of the Extended Enterprise
environment and should also consider the external
environmental variables.

- Not to foresee, but to enable

The French aviator and writer Antoine de Saint-Exupery [SaintExuperyJ in one of his novels wrote:
"As for tlfe future, your task is not toforesee, but to enable it ".

- 16 -

In Enterprise Architecture as in city planning it is futile to

attempt to foresee every possible future change. The enterprise

architecture must rather provide the capability to enable change
to occur rapidly, without undue resource utilisation, yet in a
controlled manner and with minimal adverse impact.

- Strategic Vision is Leading

Professor William R. King (King, 1995) suggests that the guiding
enterprise architecture of organisations should be based on the
strategic vision. In other words, this vision bridges the extant
status of the firm ("Where it is?") and its projected future status
("Where it wants to be?").
The strategic vision is related to the firm 's current and future
capabilities. The guiding dictum is that: a single capability of the
firm cannot provide a sustainable competitive advantage to the
firm. The firm cannot compete on the basis of 'low cost' or 'best
quality' or 'customer service.'
The sustainable competitive advantage of the fum derives from
the "synergy" of the firm's various capabilities. Porter [Porter]
has proposed a similar concept in his notion of
"complementarities." He argues that the various competitive
capabilities of the firm should be "complementary" or
"synergistic" so that the synergy resulting from them cannot be
easily imitated by current or potential competitors.
It is worth considering that the same argument has been made

with reference to different business - technology related

innovations, such as the more ieceot communication technology
possibilities (Internet, wireless, etc.) and the discussions about
the benefits of Enterprise Architecture.

- 17 P'

Crmti"g or Choosi"g "" E"terprise Architecture FrRmeumt

The Only Constant is Dynamics

Dynamics is the only constant while adaptiveness is the natural
variable.ISchekkemtanJ
Good is Good Enough
An Enterprise Architect knows he has achieved the perfect
solution not when there is nothing left to add, but when there is,

nothing left to take away.lSaint-ExuperyJ

- Spirit & Creativity
Pure logic is the ruin of the spirit and creativity delivers
unexpected opportunities. fSaint-ExuperyJ

- Teaching Enterprise Architects

If you want to create an Enterprise Architecture, don't drum up

the architects to collect information and don't assign them tasks

and work, but rather teach them to long for the endless value
creating possibilities of the enterprise.lSaint-ExuperyJ

- 18-

How 10 survWt in t~ jung/~ if EnIDpr1st Archittduft frtlmeworts

Enterprise Architecture in Context

Recent Surveys of CEO's, ClO's and other executives provide

some evidence of the growing importance of Enterprise
Architecture over the last few years. In one of the most recent
studies of the Institute For Enterprise Architecture
Developments l , Enterprise Architecture was ranked near the top
of the list of most important issues considered by CEO's and
CIO's.
Apparently, this suggests the significance of the overarching
framework within which the various aspects of decision-making
and development are considered: including Business
Architecture, Information Architecture, Information-Systems
Architecture (Data Architecture), Technology Infrastructure
Architecture and things like Software Architecture.
The various decisions related to business development and
technology innovations need to be considered in a systemic
manner within the framework of various architectures. Otoires
of methods and techniques have to be made in the context of the
goals and objectives.
So, what is the problem? Many organisations have been
paralysed by the complexity of the business &. technology and
the rate of change in business &: technology. Organisations that
have decided to pursue IT projects still show an unacceptably
high failure rate: IT project failures in industry and Government

account for an astounding $75 billion in losses ench year, according to

Gartner Incl.

l lnstitul~

For

En ltTpriR

Archittctur~

~Iopmmts,

EA.

SUrtql

2003;

hltp:J/www.mlnpns-rchiltdurt.injo
1

Gtlrtl'ln' Inc.; http://www3.gartner.com!1nit

- 19 P'

CrtIlting or Choosing Rn Enterprise Architectu re FrJlmewort

Our great leap forward in business &: technology driven

procluctivity has created a plethora of overlapping and
confusing solutions, products and standards that increase the
complexity and risks associated with every decision a CEO and
CIO makes.
Exaggerated claims by vendors and standards bodies promoting
the latest panacea procluct or standard are mind numbing. It is
extremely difficult to construct an Enterprise Architecture based
framework that properly relates the vast array of overlapping
solutions, products and standards, much less an enterprise
framework that can be explained to financial decision-makers or
the end user community.
AU this puts Business &: IT executives at a crossroads. There are
tremendous rewards for organisations that are able to harness
the vast array of available options into a holistic EA framework
of flexible domains and supportive technology that meet the
rapidly evolving needs of their stakeholder communities.
Enterprise Architecture process and framework must effectively
align business &: IT resources and processes that they enable.
Developing a system based on the EA results is asking
moclelling methods that comply with the system development
environment. Supporting decision-making is asking other type
of modelling methods and techniques.
So, besides the choices for an EA framework at the same time
choices for supporting methods and techniques has to be made.
The decisions related to strategy, business goals, information
needs, data mapping. selection of product- independent systems,
and selection of specific hardware and software need to be
guided by this framework to ensure maximal effectiveness and
efficiency.

- 20 -

How to IUrvive in 'lit junglt of En 'trp~ Archi'te'urr FrJlmtwOrb

Unfortunately, while most Enterprise Architecture frameworks

and processes that are gaining currency are able to generate
good descriptive architecture models, they do not create
actionable, extended enterprise architectures that address
today's rapidly evolving complex collaborative environments.

2.1

Enterprise Architectnre definitions

The world has not really settled on precise definitions of

architecture or architecture description as these terms relate to
enterprises, systems, or software, The Institute of Electrical and
Electronics Engineer.; IIEEEI (see ANSI / IEEE 1471-21XXJ3). the US
Department of Defence [DoD], and various business and
technology authorities do, however, generally agree that
architecture is about the structure of important things (systems
or enterprises), their components, and how the components fit
and work together to fulfil some purpose.

Some well known Enterprise Architecture Definitions

'Enterprise Architecture is about understanding all of the diffrrent
elements that go to mnke up the enterprise atilt how those elements
inter-relnte'
The Open Grou p

"Enterpn'se Architecture is a strategic infonnntion asset base, which

defines the business mission, the informa tion necessnry to perfonn the
mission, the technologies necessnry to peifonn the mission, and ti,e
transitiottnl processes for implementing new technologies in response to
the chllnging mission needs,"
USA Federal CIO Council

ANSl/1EEE 14712000; htlp://www.it.org/potWllindtx,jsp

- 21 -

CrraUng or Choosing lIn nttrprist Arrhittdurt Fl1lrtll!!Wrk

"Ellterprise Architecture is tile holistic expression of an organisation's

key business, information. application ami technology strategies a"d
their impact on business functions and processes. T1te approachloaks
at business processes, the structure of the organisation, and what type
of technology is used to conduct these business processes."
Meta Grou p, Jnc.

2.1.1

Key Definitions in this context

Architecture
The structure of elements. their interrelationships and the
principles and gUidelines governing their design and evolution
over time.
Elements
A good definition of "elements" in this context are all the
elements that enclose the areas of People, Processes, Business
and Technology. In that sense, examples of elements are:
strategies, business drivers. principles. stakeholders, units,
locations, budgets, domains, functions, processes, services,
information,
communications,
applications,
systems,
infrastructure, etc.
Enterprise
A good definition of "enterprise" in this context is any collection
of organisations that has a common set of goals/principles
and /or single bottom line. In that sense, an enterprise can be a
whole corporation, a division of a corporation, a government
organisation, a single department, or a network of
geographically distant organisations linked together by common
objectives.

Baseline or As-Is Enterprise Architecture

The set of products that portray the existing enterprise, the
current business practices, and IT infrastructure. Commonly
referred to as the Asls Enterprise Architecture.

- 22 -

How to survrot in tilt jungle ofEnttrprist Arrhittdurt FmmtWOrb

Target or To-Be Enterprise Architecture

The set of products that portray the future or end-state
enterprise, generally captured in the organisation's strategic
thinking and business ok technology plans. Commonly referred.
to as the To-Be Enterprise Architecture.

Transfonnation or sequencing Plan

A document that defines the strategy for changing the enterprise
from the current baseline to the target enterprise architecture. It
schedules multiple, concurrent, interdependent activities, and
incremental builds that will evolve the enterprise.

Enterprise Architecture products or results

The visualisations, graphiCS, models, and /or narrative that
depicts the enterprise environment and design.

2.2

Type of Architectures

An Enterprise, Architecture relates organisational mission, goals,

and objectives to business tasks, activities and relations and to
the technology or IT infrastructure required to execute them.

A System or Solution Architecture relates requirements and the

external world to system I solution structures, including both
hardware and software, so that the effectiveness of a system
design concept can be communicated.
A Software Architecture relates requirements, fixed. system
hardware, and infrastructure (i.e., COTS or GOlS) to software
structures in order to demonstrate software effectiveness.

23

How 10 suroivrl in tilt jung/tof EllttTpr1se Arr.hittdu~ Frameworks

Critical Success Factors for Enterprise

Architectures

effective Enterprise
accompanying framework
Enterprise Architectures that:
An

o
o
o

o
o
o
o
o

Architecture approach and

and methodology produces

Create and maintain a common vision of the future

shared by both the business and IT, driving continuous
business/ IT alignment
Create a holistic, end-to-end future-state enterprise
architecture process that accurately reflects the business
strategy of the enterprise
Build agility by lowering the "complexity barrier," an
inhibitor of change
Increase the flexibility of the enterprise in linking with
external partners
Develop a proactive organisation capable of meeting
customer demands, outpacing the competition, and
driving innovation
Reduce risk and prepare the enterprise for rapid,
unplanned change
Avoid the pitfalls of business-unit IT functions operating
at odds with one another
Institute a program of progressive technology
reftnement
Create, unify, and integrate business processes across
the enterprise
Unlock the power of information, unifying information
silos that hinder corporate initiatives such as customer
relationship management and e-business
Eliminate duplicate and overlapping technologies,
decreasing support costs

- 25-

How 10 5UrvWt in lilt jung/~of Entnpri~ A.rchiltdurt Fl1lmf!WOrb

Key Concepts of holistic Enterprise

Architectures

An overall holistic Enterprise Architecture includes all the

elements presented in the Extended Enterprise Architecture
(E2A) Framework below.
While this framework is important, in that it outlines all the
enterprise architectural artefacts required, it does not completely
address the actionable aspects of an enterprise architecture,
which deal with business technology alignment, validation and
actual integration into the organisation.
These must be supported with an effective combined approach
for enterprise program management and enterprise architecture
to implement.
,

Extended Enterprise Architecture (E2A) Framework

The Extended Enterprise Architecture (E2A) Framework is

developed to meet existing and future evolving complex
enterprise collaboration environments.

- 29P'

W~

How 10 survivt in lhe jungle r! Enterprise Archittduft FrtllMVOrb

5.1

Extended Enterprises

Managing tile Enterprise beyond the boundaries

In a world populated by value creating and value exchanging

entities, often the decision will come down to owning one of
three fundamental value propositions.
You will either be able to own the customer, own the content
that the customer seeks to acquire, or own the infrastructure that
aUows the content to be produced. or the value to be exchanged.
Each has a different business model. Each exploits a unique core
competence. Each employs a different means of generating
added value. However, in the connected economy, attempting to
own aU of them simultaneously will increasingly become a game
of diminishing returns. When the network allows competitors to
fIll the gaps in their offerings at no additional cost, owning all of
these competencies only increases risk without necessarily
increasing returns.

As the factors that make up the economic environment change

under the influence of the Internet or economic circumstances,
we Can begin to anticipate how and where they will alter the
cohesion and boundaries of the entities that make up the
connected economy. We can estimate which industries and
business models will likely become threatened and which will
likely survive.
In the process, we can redefine the way in which ow
organisations will participate and continue to create value for
customers and shareholders alike. In the technology, we choose
the possibilities that fit best to this collaborative environment.

33
P'

How 10 survive in 1M jungle oj Enterprise A.rchillure FnlltlnDOrlcs

Enterprise Architecture Program &

Validation

6.1

Enterprise Architecture Program

While every organisation's budgeting and capital planning

process is different, and the Enterprise Architecture integration
with these processes will vary, there are several critical success
factors associated with a successful Enterprise Architecture
implementation.

SllQhold....

,,,..... COnllllft

Enterprise Architecture Strategic Governance Model

The EA implementation is funded as a separate program in

itself:

39
P'

W~

How to survive in tlu! j wnglt ofEntttpri~ .... rdrittctUrt Ftllmtuurb

EA Measurement Process

7.1

Value Net' Based Assessment

Interrelationship among the solution sets can be maintained

using cross-reference models, tables and matrices. Those
matrices must properly allocate the benefit, cost and risk
contributions of each enterprise architectural solution.
Misallocation can lead to major disasters, as can be witnessed by
the mistake made by a large industry company. The industry
company embarked on a $50 million plus effort to build a
business-to-business (B2B) portal environment to do business
transactions with their trading partners. They knew that the B2B
technology was risky, but thought the risk worthwhile given the
perceived benefit. The fact is that the architecture methodology
used mapped the trading transactions directly to business
drivers, rather than to the solution sets, it supported. The result
was that the focus was on doing business transactions rather
then how solutions sets can interact with each other in an
extended environment. By the fact that all trading partners have
their own definition of business transactions, the lack of focus on
a common overall definition language was due to the result that
this project failed.
A post-mortem mapping of the various architectural solutions
using the prescribed structure showed that the real gains were
from less risky EOI automated transactions, not from enabling
the trading partners with a B2B portal solution.

VII/Ut Nt!; Book '.... rchittCfwwr, btstwringsinstrwmtnt voor iUIIIptiew orgQnislll~'

RijSnlbrij, Schtkbrnuln, Htndrick, ISBN 9059312813,Pwb/WItr l.nn17lll, 2002

- 47 -

How to suroivt in tlrt junglt af Entnpri5e ArclrittctuTt FrtI~rts

8 Today's EA Frameworks Practice

Both industry and government aU over the world have
recognised the special value of Enterprise Architecture. The US
government's embrace of Enterprise Architecture driven by the
mandates of the Clinger - Cohen Act and OMS Circular A130, is
also driven by the growing complexity of their current IT
environments, and the movement from platform-based data
processing into value-based services. In Europe several EA
initiatives are started some sponsored by the European Union, to
define EA rules for governments and in other areas of the world
like South-Korea and Australia/New Zealand EA efforts are
ongoing.
Industry has been motivated by the simple reality that they need
Enterprise Architectures to remain competitive and support
business continuity as they consolidate their long spending
efforts on disparate IT resources.
While this is a positive move, a fundamental problem remains.
In the rush to implement Enterprise Architectures, most current
frameworks and methods are in need of updating to address
today's realities.
The virtual plethora of options and overlapping products and
s tandards, and the focus o n package integration, create a much
more complex environment then the environment that most of
these frameworks and processes were designed to address. Most
frameworks are focused on providing detailed modelling of
systems and activities that are only moderately relevant at the
enterprise level.
Many of these descriptive models and
frameworks have their pedigree in the systems engineering
arena, and so much of what is prescribed is more suitably

- 53 P'

How to survive in

t~ ju ngle

of Enltrprist Ardlittdurt FFlimtlOO,Q

Enterprise Architecture
Law & Regulations

- 55P'

Crtllting or Choosing an nttrpriM Archifhm Framework

- 56 -

How'o survive in,1It junglt of En'nprise ArchiltctuTt FnlllltwOrb

9 Enterprise Architecture in the United

States Government
Largely because of the USA Clinger-Cohen Act [CCA1,
Enterprise Architecture (EA) is emerging as a significant
business - technology trend in the government sector, including
federal, state, and local governments. In addition, a similar hend
is emerging in industry, as companies recognise that the IT
spending of the past was not well-aligned with organisational
objectives, creating islands of information and systems that
failed to meet their intended objectives.
Although federal EA efforts certainly do not encompass all the
industry efforts to standardize and benefit from EA, federal EA
efforts are important because of the large scope of the targeted
enterprises.

9.1

9.1.1

What is the USA - Clinger-Cohen Act?'

Background

The Clinger-Cohen Act fCCA1 assigns the Chief Wormation

Officers (CIO) the responsibility of "developing, maintaining,
and facilitating the implementation of a sound and integrated.
Wormation Technology Architecture." IITAJ
The Act defines the IT A as: an integrated framework for evolving
or maintaining existing information technology and acquiring
new information technology to achieve tlte agency's strategic goals
and information resources management goals.

, us

OJfict of Mmagtmrnl and Budgtl {OMBI mrnwnmdum 97..()2,

Infomuition Syslmr,

1m.,"I~I$. ~

~Funding

dalm Octobtr 25, 1996

- 57P'

Crttlting or Choosing an Entaprist Archittdurt FramnDOrk

9.1.2

Clinger.Cohen Act sets Standards

Investments in major information systems proposed for funding

in the President's budget should be consistent with Federal,
agency, and bureau information architectures which: integrate
agency work processes and information flows with technology
to achieve the agency's strategic goals; and specify standards
that enable information exchange and resource sharing.
These references highlight three important characteristics of the
Information Technology Architecture (ITA) as agencies plan for
investments in information technology (IT) assets:
o CIOs are responsible for the architecture;
o The architecture must integrate the business
processes and goals of the agency with IT
acquisitions;
o The architecture focuses on work processes,
information flows, and standards.
Agencies may address the topics and elements set out herein in a
manner appropriate to the agency. Each element identified need
not have specific or ~stand-alone" documentation.

9.1.3

Information Technology Architecture Defined

For the purpose of conforming to the requirements of ClingerCohen Act, a complete Information Technology Architecture
(ITA] is the documentation of the relationships among business
and management processes and information technology that
ensure:
o Alignment of the requirements for information
systems (as defined in OMB Circular A-l30) with the
processes that support the agency's missions;
o Adequate interoperability, redundancy, and security
of information systems; and,

- 58-

How 10 5U~ in tht iung'~of Ent~ri~ A.rchitmurr Fmmnoom

The application and maintenance of a coUection of

standards (including technical standards) by which
the agency evaluates and acquires new systems.

The following definition of Enterprise Architecture as described

in this memorandum is used in the context of the USA / ClingerCohen Act.

9.1.4

Enterprise Architecture Definition in the context

of CCA10

The ITA is broad in scope and includes processes and products.

An architecture in compliance with the Clinger-Cohen Act and
OMS guidance will contain two elements:
o
o

The Enterprise Architecture;

Technical Reference Model and Standards Proflles.

A variety of nomenclatures used in several Enterprise

Architecture frameworks are available to address these elements.
Agencies may address the elements of an ITA in different ways
and at various levels of granularity as appropriate, combining or
reorganising the parts to create a model that suits the agency's
organisational needs. Various aspects of the IT A can be
developed at the agency or sub-agency level. However, selfcontained sub-agency level architectures should be integrated
and consistent with an agency-wide ITA.

9.2

CCA - Enterprise Arc1litecture Compliancy

The Enterprise Architecture is the explicit description of the

current and desired. relationships among business and
I~

In Iht origil1lll CCA. dtfinilion of Enlerprist A.rchitm urr, ITA is limited 10 lilt
IIlignmtnl of busint5S rtquirrmmts lind IT sylllt ms. Hou'ftJt1. in liIltT US OMB
IInnounetllltnls. tht salIX of EA in tilt ron ta t of CCA is Illso addrming busint5S &
infontUllion IIrchitt(:tu rr liS pilrl of fA.

- 59P'

C/'tIlling or Choosing lin Enl"prise Archiltdllrt Framerwrt

management process and information technology. It describes

the "target" situation, which the agency wishes to create and
maintain by managing its IT portfolio.

Documentation
The documentation of the Enterprise Architecture should
include a discussion of principles and goals. For example, the
agency's overall management environment, including the
balance between centralization and decentralization and the
pace of change within the agency, should be clearly understood
when developing the Enterprise Architecture. Within that
environment, principles and goals set direction on such issues as
the promotion of interoperability, open systems, public access,
end-user satisfaction, and security.

Guidance
This gUidance
adapts a five
component
model used in
the National
Institute
of
Standards
and
Technology

f .. '

tt
"7

(NIST)

Special
Publication
500-167,
"Information
Management
Directions:
The
Integration
Challenge. ~

Ii. . . .

...

I,AAe

"'~.c

....

- 60-

,,.

..

"

How 10 survWt in 1M jungkof EnlnprN Archiltdurt FramtwOm

Sub or System Architectures

Agencies are permitted to identify different components as
appropriate and to specify the organisational level at which
specific aspects of the components will be implemented.
Although the substance of these components, sometimes called
~system architectures~ or ~sub-architectures," must be addressed
in every agency's complete Enterprise Architecture, agencies
have great flexibility in describing, combining, and renaming the
components, which consist of:
o
o
o
o
o

Business Processes
Information Flows and Relationships
Applications
Data Descriptions
Technology Infrastructure

Current &: Target Environment

With the exception of the Business Processes component, the
interrelationships among and priorities of these components are
not prescribed by this guidance; there is no hierarchy of
relationships implied. Furthermore, agencies should document
not only their current environment for each of these components,
but also the target environment that is desired.

9.2.1

Business Processes

This component of the Enterprise Architecture describes the core

business processes, which support the organisation's missions.

The Business Processes component is a high-level analysis of the
work the agency performs to support the organisation's mission,.
vision, and goals, and is the foundation of the ITA.
Analysis of the business processes determines the infonnation
needed and processed by the agency. Senior program managers
in conjunction with IT managers must develop this aspect of the

- 61 P'

Crmting or Choosing an Enterprise An:hittdllrt Fnlmttrort

ITA. Without a thorough understanding of its business processes

and their relation to the agency missions, the agency will not be
able to use its ITA effectively.

Business processes can be described by decomposing the

processes into derivative business activities. There are a number
of methodologies and related tools available to help agencies
decompose processes (see related chapters in this book about EA
tools).
Jllespective of the tool used, the model should remain at a high
enough level to allow a broad agency focus, yet sufficiently
detailed to be useful in decision-making as the agency identifies
its information needs. Agencies should avoid excessive emphasis
on modelling business processes, which can result in a waste of

agency resources.

9.2.2

Information Flows and Relationships

This component analyses the information utilized by the

organisation in its business processes, identifying the
information used and the movement of the information within
the agency. The relationships among the various flows of
information are described in this component. These information
flows indicate where the information is needed and how the
information is shared to support mission functions.

9.2.3

Applications

The Applications component identifies, defines, and organises

the activities that capture, manipulate, and manage the business
information to support mission operations. It also describes the
logical dependencies and relationships among business
activities.

- 62 ~

'"

How 10 suroWt in 1M jungle of Enlerprise Arr;hiltdurr Fmmeworlcs

9.2.4

Data Descriptions and Relationships

This component of the Enterprise Architecture identifies how

data is maintained. accessed. and used. At a high level, agencies
define the data and describe the relationships among data
elements used in the agency's information systems.
The Data Descriptions and Relationships component can include
data models that describe the data underlying the business and
information needs of the agency. Clearly representing the data
and data relationships is important for identifying data that can
be shared corporately. for minimizing redWldancy. and for
supporting new applications.

9.2.5

Technology Infrastructure

The Technology Wrastructure component describes and

identifies the physical layer including, the functional
characteristics. capabilities. and interconnections of the
hardware. software, and communications. including networks.
protocols. and nodes. It is the "wiring diagram" of the physical
IT infrastructure.

9.3

Technical Reference Model and Standards

Profiles

The Technical Reference Model (fRM) and Standards Profiles

(both technical and security) comprise a crosscutting element.
affecting aU components of the Enterprise Architecture.
Standards enable interoperability. portability. and scalability in
systems throughout the agency. Although the specificity of the
standards may vary by organisational level. the standards must
be consistent throughout the agency. Standards are the basis of
the development of components of the Enterprise Architecture,
ultimately guide. and constrain IT asset acquisitions.

- 63 -

Crmting or Choosing lin EnterpriK Archittd urt Frllmnwrt

9.3.1

Technical Reference Model

The TRM identifies and describes the information services (such

as database, communications, and security services) used
throughout the agency. For example, Data Interchange Services
support the exchange of data and information between
applications. This information service would identify the various
ways the agency enables the exchange of data, such as plain text,
spreadsheets,
databases,
graphical
information
over
Intranet/ internet, and video.

9.3.2

Standards Profiles

The standards profile defines a set of IT standards that supports

the services articulated in the TRM; they are the cornerstones of
interoperability. The profile establishes the minimum criteria
needed to specify technology that achieves the purposes of
standardization and supports specific business functions.
Standards Profiles are the published sets of standards or the
source references for standards that prescribe the interfaces
between those services that will be standards-based. A profile
may contain specifications that describe the technical standards,
which enable a service, such as operating systems, network. and
data interchange services.
Together with the TRM, the Standards Profiles enable the
development and acquisition of standardized systems to costeffectively meet the business needs of the agency. Agencies are
expected to adopt the minimum standards necessary to support
aU components of the desired Enterprise Architecture. The
profiles should address hardware, software, communications,
data management, user interfaces, and implementation
approaches, and may indicate specific products that implement
the standard .

- 64 prNO"

How 10 suroit.lt iNlilt iUNg/~of ENltrpnse Ardritedun Fmmnoorb

9.4

Security Standards Profiles

While security services may be considered part of the TRM and

security profiles may be a subset of the standards profiles, the
importance of security as a crosscutting issue warrants special
attention. Security standards need not be a separate component
of the Enterprise Architecture or of the TRM. Security standards
profiles are Standards Profiles specific to the security services
specified in the Enterprise Architecture. The profiles cover such
services as: identification, authentication, and nonrepudiation;
audit trail creation and analysis; access controls; cryptography
management; virus prevention; fraud prevention, detection and
mitigation; and intrusion, prevention and detection. The purpose
of the security profiles is to establish information and technology
security standards to ensure adequate security for each
component of the Enterprise Architecture, and to ensure that
information systems conform to agency security policy. The
security standards identified in the security standards profiles
must be consistent with the requirements of OMB Circular A
130, Appendix III.

65
P'

em/ting or Choosing "" Enterprise Archittdllrt Framewort

- 66-

How 10 $ UroM in the jungie of Enterprise Itrchitecture Fmmeworb

10 Enterprise Architecture in Europe

European Union supported projects
The European Union does not have up till know, any law's or
regulations to stimulate or enforce Enterprise Architecture
efforts. Therefore, in Europe most EA efforts came from
consultancy and system integrator companies like Capgemini,
IBM, EDS and Accenture and research organisations like IFEAD,
the META group and Gartner.
The European Union is supporting
and
participating in
several
initiatives and projects, however
they are not responsible for the
results of these projects.
Examples of these projects are:

10.1 The In!oCitizen project"

lnfoCitizen project aims at:
o

\I

Establishing a common Enterprise Architecture among

the participating European Union countries tested in
representative public administration segments;
Deploying a distributed, Internet-based infonnation
system that supports the above for all actors involved
(citizens, administrations, private sector), building on
emerging tedmologies (e.g. mobile agents, middleware,

InfoCitiun project: hllp:llwUJuJ.turia.dt/injocitiun

- 67 P'

W~

How 10 survivt in lhe jungle of Ell ltrprist Ardlittdure Ft'IImttOOrts

Enterprise Architecture Frameworks

- 83P'

Cmltin8 or Choosing In Entl!rprtSt Archittdurt FTJlmtumk

- 84-

How to survivt in tilt jllnglt of Entcpr1st Ardrittduu FrtlfM{JOrb

11 Creating or choosing an Enterprise

Architecture Framework
An Enterprise Architecture framework is a communication
model for developing an Enterprise Architecture (EA). It is not

an architecture per se. Rather; it presents a set of models,

principles, services, approaches, standards, design concepts,
components, visualisations and configwations that guide the
development of specific aspect architectures.

11.1 Benefits of an Enterprise Architecture

Framework
An Enterprise Architecture framework provides a generic
problem space and a common vocabulary within which
individuals can cooperate to solve a specific problem. EA
Frameworks are not necessarily comprehensive, but they can be
leveraged to provide at least a starter set of the issues and
concerns that must be addressed in enterprise architecture
development.
For many organisations and technical professionals, architecture
has traditionally meant an incomprehensible diagram or two
that has been around since the beginning of the project and
cannot be changed because "too much depends on it," nor can it
be questioned too closely because its meaning is not really clear.
What depends on it, and how was that decided?
The answers to those and many other related questions are too
often lost in the push to meet schedules or market demands.
Frameworks can provide guidance on a broader notion of
architecture than just what can be conveyed in block diagrams.

- 85 -

How to S II P11ive in Iht ;unglt of Enttrprist Ardriltctllrt Frllrnnrorl:s

12 The Enterprise Architecture Frameworks

History Overview
The history diagram below illustrates some of the historical
relationships among several frameworks. Most of the
frameworks represcnted in this diagram are described in the
next chapters.

:\

iI:

""H~

,...

"""

Having a closer look at this history diagram we can see that most
enterprise architecture frameworks today have a common
history and are build on refinements and add-ons of other
frameworks.
Terminology has changed over time; however the ideas behind
the function areas of the frameworks and the abstraction levels
are almost the same. So, a good and experienced enterprise
architect can deal with all the existing and future enterprise

- 89 -

How to SlIroivt in tht jlmglt of Enll.p, ist Archiltdllrt FnrmtWOrb

13 Extended Enterprise Architecture

Framework (E2AF)C
13.1 History
The Extended Enterprise Architecture (E2A) Framework is
developed by the Institute For Enterprise Architecture
Developments in 2002 and is based on ideas and influences of
other frameworks as well as real life experience in using several
frameworks.
The influences of the Zaclunan framework, EAP (Enterprise
Architecture
Architecture
Planning),
lAF
(Integrated
Framework) and the Federal Enterprise Architecture Framework
can be found in this framework. The framework is the results of
several years experience in using enterprise architecture
frameworks.

13.2 Purpose
The Extended Enterprise business model
In a world populated by value creating and value exchanging
entities, often the decision will come down to owning one of
three fundamental value propositions. You will either be able to
own the customer, own the content that the customer seeks to
acquire, or own the infrastructure that allows the content to be
produced or the value to be exchanged. Each has a different
business model. Each exploits a unique core competence. Each
employs a different means of generating economic returns.
However, in the connected economy, attempting to own all of
them simultaneously will increasingly become a game of
diminishing returns. When the network allows competitors to
o Tht l f1Stitlitt For Enttrprise Archittdllrt Dtvdopmtnts. Tht Ntthuumds.
http;//wtvwnfttrpriu-tlrdrittd ll re.in/o

91 .
P'

How to 5Urvivt in tht junglt of nttrprist ArdJittdurt FmlMlJOrO

14 Enterprise Architecture Planning (EAP)C

14.1 History
This commercial methcxiology is a specific attempt to provide
guidance for specifying the top two rows of the Zachman
Framework: Scope (Planner) and Business Model (Owner).
Published in 1992, the methcxiology has a business data-driven
approach intended to ensure quality information systems by
emphasizing the definition of a stable business mcxiel, data
dependencies defined before system implementation, and the
order of implementation activities based on the data
dependencies.

14.2 Purpose
EAP defines a process for enterprise architects that emphasizes
interpersonal skills and techniques for organising and directing
enterprise architecture projects, obtaining management
commitment, presenting the plan to management, and leading
the organisation through the transition from planning to
implementation.

14.3 Scope
EAP covers only the first two rows of the Zachman Framework.
This means that only the business planning is detailed, and no
attention is given to technical design or implementation. EAP
has been mainly used in business and industrial information
systems.
Spal'llk, Strum H.i Book ' EnttrprW Archittdurt Planning', Ntw Yo'*: / 01111 Wi/ql :1
Son,; 1992

101
P'

How to su/O;vt in 1M ;"n8/1 of Enttrprist A.rchiltcturt FnuntlOO,u

15 Federal Enterprise Architecture

Framework (FEAF)C

15.1 History
Following the industry hend of defming architectural
frameworks to guide the development of large, complex systems
development and acquisition efforts. the United States of
America Congress passed the Clinger-Cohen Act (also known as
the ITMRA) in 1996, which requires USA Federal Agency Chief
Information Officers to develop, maintain, and facilitate
integrated systems architectures.
The Federal Enterprise Architecture Framework is developed by:
the USA Chief Information Officers Council. The USA CIO
Council published version 1.1 of the FEAF in 1999.
Based on the earlier investments in FEAF. on February 6, 2002
the development of a Federal Enterprise Architecture (PEA) was
commenced.. Led by OMB, the purpose of this effort is to identify
opportunities to simplify processes and unify work across the
agencies and within the lines of business of the Federal
Government. The outcome of this effort will be a more citizencentred, customer-focused government that maximizes
technology investments to better achieve mission outcomes.

15.2 Purpose
The USA Office of management &: Budget lOMB] requires that
agency information systems investments be consistent with USA
Federal, Agency, and Bureau architectures.
o

USA. Chiq 'njarmation OfJial'$ Council. FA.F vtrSion 1.1; 1999.

105

How to survivt in the jungle of Enttrprist Architecture FrDmtWOrb

16 Treasury Enterprise Architecture

Framework (TEAF)C>

16.1 History
TEAF is derived hom an earlier US Treasury model, [TISAFJ
(1997). and the US FEAF (1999).

Additional direction was provided by the Information

Technology Management Reform Act lITMRAJ, also known as
the Clinger..cohen Act of 1996, and the Government
Performance and Results Act IGPRA] of 1993.

16.2 Purpose
One of the requirements of the US Clinger..cohen Act is the
development of enterprise architecture (EA) in Federal agencies.
Section 5125 requires that agencies develop "a sound and
integrated information technology architecture." Furthermore,
the OMS budget process requires that agencies indicate the
compliance of IT initiatives with an agency architecture on
Exhibit 3OOB, budget request form. In accordance with this, the
Department of Treasury developed and published an EA
framework in July 2XXJ. Based on this Treasury Enterprise
Architecture Framework (TEAF), Treasury Bureaus are
developing architecture descriptions. The Department of the
Treasury anticipates that these architecture descriptions will
contribute to business and IT strategic thinking. to the
integration of systems, and to the development of standards,
among other benefits. The Department of the Treasury is

us -

i)epQrllNCll of 1M TMlSUry; Soura: TAF

hllp://Wwul.USlrtOs.gov/ojfias/mllnagtmml/dolttll/1

1.0

2lXXJ;

- 113 P'

How 10 survive in

t~

jungle of fnterpri~ Archiltdurt Fnrmomoorb

17 The Open Group Architecture

Framework (TOGAF)C

17.1 History
Developed by the Open Group in 1995, this architectural
framework was based on the TAFlM, developed by the DoD.
TOGAF Version 8 is a superset of the well-established
framework represented by TOGAF Version 7. Version 8 uses the
same underlying method for developing IT architectures that
was evolved, with a particular focus on Technical Architectures,
in the Versions of TOGAF up to and including Version 7.
However, Version 8 applies that architecture development
method to the other domains of an overall Enterprise
Architecture - the Business Architecture, Data Architecture, and
Application Architecture, as well as the Technical Architecture.

17.2 Purpose
{TOGAFI intends to provide a practical, freely available, industry

standard method of designing an EA, leveraging all relevant

assets in the process. TOCAF is supported by a number of
different architecture consultants, and it is s ufficient for an

organisation to use "as-is" or to adapt as an EA development

method for use with other deliverables-focused. frameworks.
TOCAF focuses on mission-critical business applications that
will use open systems building blocks. The framework embodies
The Open Croup; soun:e: TOCM
htlp:J/www.opengroup.orx/Qrchittdurt/t08Qf/

. 119

version

fnlerpr1M

Edition;

How to .furoivt in 1M jungle of Enltrprist Archiltdurt FlIlIfttworics

18 Zachman Framework<'

1B.1 History
In 1987, John Zachman published the Zachman Framework for
Enterprise Architecture. He wrote 'To keep the business from
disintegrating, the concept of information systems architecture is
becoming less of an option and more of a necessity." With this
belief, he created the Zachman Institute for Framework
Advancement l ZIFAJ.

This organisation is a netwo rk of information professionals who

understand the value of EA for organisations participating in
today's global economy. The mission of ZIFA is to promote the
exchange of knowledge and experience in the use,
implementation, and advancement of the Zachman Framework
for Enterprise Architecture, This framework is used most
frequently for business and industry information systems.

1B.2 Purpose
The Zachman Framework is influenced by principles of classical
architecture that establish a common vocabulary and set of
perspectives for describing complex enterprise systems. This
influence is reflected in the set of rules that govern an ordered
set of relationships that are balanced and orthogonal. By
designing a system according to these rules, the architect can be
assured of a design that is clean, easy to understand, balanced,
and complete in it self. Zachman's Framework provides the
blueprint, or architecture, for an organisation's information
infrastructure.
o ZadI"""n 1ft$lilultftn' FramtwO'* Adwnctmt7lt; So"ra': hllpj/wwUJ.:i,fo.roml

- 131 ~

'"

Haw ta 8u. viw in the jungle of Enttrpri~ Ardritniurt Fnuntwarb

19 Integrated Architecture Framework (IAF)

19.1 History
The first version of Capgemini's proprietary Integrated
Architecture Framework [lAF] was developed in 1996 and
influenced by the Zachman Framework (1987) and Spewaks
ideas described in his book 'Enterprise Architecture Planning'
(EAP). The CUllent version is influenced by Capgemini's merger
of Ernst &: Young consulting in 2001 and combines best practices
from both organisations. The version of IAF in this book is an
enhanced and extended version, tuned for Enterprise
Architecture.

19.2 Purpose
IAF is Capgemini's proprietary integrated architecture
framework. lAF positions the way Capgemini communicates
about enterprise architecture with all stakeholders, based on the
philosophy and mindset behind the framework.
Every complex thing that has to operate as one system has to be
designed as one system. This to guarantee integration and
coherency of all its components and to ensure the system will
operate the way required. when it is created.

19.3 Scope
The Integrated Architecture Framework forces enterprise
architects to ensure that the organisation fully benefits from the
alignment of business and technology by integrating all
architecture aspect areas into one overall result, i.e. The
.

Propri&ryfnm~ulOrkofGlpgemj"j.

139
P'

How to suron!e in the junglt if Enttrprist Archittdurt FnllntwOtts

20 Joint Technical Architecture <ITA)"

20.1 History
Version 1.0 of the US Department of Defence (DoD) Joint
Technical Architecture was released on 22 August 1996 and was
immediately mandated by the Under Secretary of Defence,
Acquisition and Technology (USD [A&n) and ASD(C3I) for all
new and upgraded C4I systems in DoD.
JTA Version 2.0 development began in March 1997 under the
direction of a Technical Architecture Steering Group (TASG), c0chaired by ASD (CJI) and USD (AT&L) Open Systems Joint Task
Force (OSJTF). The applicability and scope of Version 2.0 o f the
IT A was expanded to include the information technology in aU
DoD systems.
ITA Version 3.0 d evelopment began in June 1998. JTA Version
3.0 includes additional sub domains and incorporated the newly
developed DoD Technical Reference Model (DoD TRM). JTA
Version 3.~ mandated a Gigabit Ethernet standard. JTA Version
4.0 was available July 2002. JTA Version 4.0 removes the Orange
Book mandate and mandates the Common Criteria.
The DoD Joint Technical Architecture (}TA) version 5.0 is
currently being reviewed (08-2003) by the National Defence
Industrial Association (NOlA).

() US Drportmmt if Dtftna; Source: 'oint Ttchniall Archiltdun vrnIUm 4;

II tIp:!fwww.illl.jlsi.ili5ll.mill

- 145 -

How 10 5uroivt in thL jungle of Enlerprise Archittdun Fmmnuorlcs

21 C41SR and DoDAfC>

Command, Control, Communications, Computer, Intelligenu,
Surveillanu and Reconnaissance {C41SR]
Department o/Defence Architecture Framework [DoDAFJ

21.1 History
In response to increasing needs for joint and multinational

military operations, the DoD has become increasingly aware of

the need for a standard architectural approach to ensure that its
systems can communicate and interoperate. Beginning in 1995,
the DoD has developed guidance on architecture development.
The C4ISR Architecture Framework, Version 1.0 was published
in 1996. Version 2 of the framework was published in 1997. After
experience with these versions and in recognition of the need to
strengthen adoption, the DoD is nearing completion on a new
version entitled the DoD Architecture Framework, Version 1.0.

21.2 Purpose
The C4ISR Architecture Framework is intended to ensure that
the architecture descriptions developed by the Commands,
Services, and Agencies are inter-relatable between and among
each organisation's operational. systems, and technical
architecture views. and are comparable and interoperable across
Joint and combined organisational boundaries.
The DoD Architecture Framework is an evolution of the C4ISR
Architecture Framework. When finalized and released in late
o USA DqMrtmmt

of Difma; Souras: C4rSR Archittcture Fmmnrort, vtTS~1I

2.0;

DoD Archittchm Fmmnrork, dmft vrrsioll 1.0

. 157 ~

'"

How to survive in tilt jung/e at Entnprise Ardrittdurt FlIImrworb

22 Department of Defence Technical

Reference Model (000 TRM)C

22.1 History
The DoD TRM should be referenced for the complete definition
of a service or interface. DoD Memorandum March 21. 2CXXJ.
Subject-DoD Technical Reference Model (DoD TRM). Version 1.0
and DoD Memorandum November 29, 1999. Subject-DoD Joint
Technical Architecture Version 3.0 contained. in Appendix A
should be consulted for amplifying guidance.
The DoD Technical Reference Model (DoD TRM) User Guide is
to be used with the DoD TRM document. The User Guide
provides added. insight into a number of areas that are not
elaborated. in the 000 TRM document:
o
o
o
o
o

o
~

How to use the DoD Technical Reference Model;

Insight into examples and case studies;
Different applications of the DoD TRM;
How to interpret and use model service and interface
categories;
Contrasts and identifies the relationships between the
DoD TRM document and other related. documents (e.g.,
Joint Technical Architecture UTA). Defence Information
Wrastructure Common Operating Environment [011
COE];
Command,
Control.
Communications.
Computers.
Intelligence.
Surveillance,
and
Reconnaissance Architecture Framework [C4ISR AF]);
Methodology for applying the DoD TRM.

us ~rlmrnt at ~u; DoD Ttchniall Rrforrna Model, VtTSion 1.Ollnd tilt DoD

TRM Users guide, 2001

- 165 -

How 10 suroivt in lhe ;ungit of Enltrprlst Ardtiltdul't Framnw,b

23 Technical Architecture Framework for

Information Management (TAFIM)C

23.1 History
The latest version of US DoD TAFIM, Version 3.0, was published
in 1996. Contractors and US DoD organisations have been
applying this set of gUidelines to current and future information
systems. The US Defence Information Infrastructure Common
Operating Environment is an implementation of T AFIM. It may
take several years, after multiple new TAFIM-compliant systems
are in the field, to determine the effectiveness of the reference
model with respect to achieving a common, flexible, and
interoperable DoD infrastructure.

The TAFIM }UlS been rescinded via Architecture Coordinnting Council

(ACC) Memo, dated 7 /ammry, 2()()(), Subject: DoD Policy Change Cancellation of the TechniCiJ I Arc},itecture Framework for Informa tion
Management (TAFIM),
The ACe's Technical Architecture Steering Group (TASG)
finalised the re-evaluation of the TAFIM in 2(XX). The TASG
concluded that the TAFIM as a collective entry is inconsistent
with the new DoD architecture direction. Further, the TASG
recognised that TAFIM legacy elements, such as a Technical
Reference Model (TRM), need to be continued since it is the
source for the DoD Joint Technical Architecture (JTA) and
Defence Information Infrastructure, Common Operating
Environment as well as DoD's compliance with the Clinger
Cohen Act,

us Dqlarlllmll of Dtf'tru:e: Soura': TwmiCJlI Archiltdurt Fl'IlmtWO'*Jor Irt/ontUl,iort

M,ulIIgmttIII (TMIM). Vmion 3.0: hllp://www-library.i'si4is4.frtjl/lllfiml

173
~

'"

How 10 SlI rvive ill lire iU1l8~ of Ellterprise Archittdure Frameworks

24 Computer Integrated Manufacturing

Open System Architecture (CIMOSA)C

24.1 History
CIMOSA is a well-known OM Open System Architecture
developed by the AMICE Consortium, and the most important
CIM initiative within the former European FSPRIT program. The
term AMICE is a reversed. acronym for 'European CIM
Architecture'. CIMOSA is an European Standard.

24.2 Purpose
The aim of this project was to elaborate an open system
architecture for CIM and to define a set of concepts and rules to
facilitate the building of future CIM systems. An important
aspect of the project is its direct involvement in standardization
activities. The two main results of the project are the Modelling
Framework, which is well known and the Integrating
Wrastructure.

24.3 Scope
The Modelling Framework supports all phases of the CIM
system life cycle from requirements definition, through design
Specification, implementation description and execution of the
daily enterprise operation. The Integrating Wrastructure
provides specific information technology services for the
execution of the Particular Implementation Model, but what is

CI CIMOSA Associal ion; htlp:/lwww.cimCl$ll.dt/inda.hlml

1 75
prNO"

How 10 5Urvivt in lilt junglt o/EnttrpriS4! Archiltdurt! FrumtWOrts

25 Purdue Enterprise Reference Architecture

(PERA) c

25.1 History
During the period 1989-1992, research at Purdue Laboratory for
Applied Industrial Control (PLAlC1 was devoted almost
exclusively to servicing the Industry-Purdue University
Consortium on Computer Integrated Manufacturing (aM). The
group of ten companies developed, with major input from
PLAIC, an Implementation Procedures Manual for Computer
Integrated Manufacturing.
The manual outlines in a complete, step-by-step manner the
preparation of detailed Master Plans for implementing CIM in
any factory of any company, regardless of industry. Formal
work on the Manual was completed with its publication on June
8.1992.
Also completed at the same time was the related publication
entitled, Tlte Purdue Enterprise Rejerellce Architecture, described
just below.
The successful pursuit of the Implementation Procedures Manual
hinged upon the parallel development of a better method of
describing the modelling of an enterprise system and
particularly a method for describing the place of the human in
the development and operation of such systems.
This was accomplished with the completion of The Purdue
E"terprise Referetlce Architecture (PERA). PERA has shown itself
o Pmlue lAboruturyfor AppliftllndustriQ/ Control; Sourer: http;llpnrt.nd/

. 183
P'

Huw 10 suroif/e in I~ iung/~ if Ent"p~ ArdrittduTt Fmmnuorb

26 Standards and Architectures for

eGovemrnent Applications (SAGA)O

26.1 History
With the Standards and Architectures for eGovemment
Applications (SAGA), the Gennan Federal Government is
making an important contribution towards modem and serviceorientated administration. In September 2000, Chancellor
Gerhard SchrOder launched the BundOnline 2005 e-govemment
initiative and obliged the Federal administration to provide its
more than 350 Intemet-enabled services online by the year 2005.
Federal administrations, agencies and authorities have started
implementing this initiative.
Since the end of 2002, more than 160 administration services
have now become available online.
Coordinated by the German Federal Ministry of the Interior
(BMI), an implementation plan was drafted. and basic
components defined. These basic components and applications
that were developed according to the "one-for~all n principle, as
well as new e-govemment applications to be created during the
years to come are to smoothly interact with each other. A
uniform "look and feel" system is to be made available to users.
Following the development of the implementation plan, the
Federal Ministry of the Interior set up a project group
responsible for developing concrete technical procedures for this
implementation plan.
CI Gmrum Ftdmd Ministry of lilt In/mar in aH1pt!flIlilm with
Offi~ fo r Ilf/ontUltioll 5urity; Source; ""p:li1cMt.burul.dt/M8"

- 191 -

,~

Gmrum Ftdmll

How to surviut in the jungle of Enterprise Arrhittdurt: Frllmnoorts

Enterprise Architecture Tools

- 199 -

,,
Crtll ting or Choosing lin Enttrprise ArchittCfllrt Fram(!WOrt

- 200-

Crmting or Choosing an EnttTprist Arrhittcturt Fra~rlc

dimensions: the basic functionality of the tool, and the utility of

the tool to different professionals.
When reviewing an EA tool's basic functionality, the reviewer
has to describe how well the tool performed the different
functions needed for the enterprise architecture development
activity. The tools basic functionality was examined in the
following areas:
Methodologies and Models; Model
Development Interface; Tool Automation; Extendibility and
Customization; Analysis and Manipulation; Repository.
The second dimension, the tool's utility to different
professionals, captures the fitness for purpose of the tool, and
describes how useful the tool would be to particular
professionals. The types of professionals considered were:
Enterprise Architects; Strategic Planners; Enterprise Program
Managers.

27.3 Functionality Dimension

This dimension of the EA Tools review approach attempts to
capture how well the tool performs the core functions needed to
support the enterprise architecture development activity. This
dimension breaks the functionality of an enterprise architecture
tool into eight key areas.
.

27.4 Methodologies and Models

The most important feature of an enterprise architecture tool the
methodologies and modeUing the approaches it supports. The
approaches the tool supports dictate the types of enterprise
architectures the tool is capable of supporting, and to an extent,
the type of analysis and manipulation functions the tool is
capable of performing. As well as reviewing the methodologies
and modelling approaches, this functional area also reviews how

- 202prNO"

How 10 sul'Vh!t! in 1M junglt of Entetp,iM A.rchittdurt FnlmtwOtis

well, or how completely, the tool implements the methodologies

and modelling approaches it claims to support.

27.5 Model Development Interface

The model development interface is the most obvious part of an
enterprise architecture development tool. It is the interface used
to design, build, maintain and often manipulate, the models that
make up the architecture. Generally, models are built and
maintained graphically, by manipulating irons and the
connections between them. The tool's model development
interface may also use textual interfaces to allow additional
information to be appended to the graphical models.
The overall quality of the model development interface is an
important characteristic of any enterprise architecture
development tool. The interface must support the modelling
activity well, for example by automating some of the drawing
functions, by automatically laying out models, or by providing
pick lists of alternative values at the appropriate places during
the modelling activity. The model development interface must
also be intelligently structured, make good use of limited screen
space, be logical and consistent to use and navigate. The tool
should ideally follow the graphical user interface conventions
and guidelines that apply to its host operating system.

27.6 Tool Automation

Developing and populating enterprise architecture models is
often the most time consuming part of the enterprise architecture
development activity. By providing support for automating
parts of the enterprise architecture development processes, a tool
can help speed up the overall development activity.

- 203 -

CrtIlting or Choosing lin

fnltrpri~

Archiltdurt Frrl~rk

A tool may also provide the ability to automatically generate

enterprise architecture models based on data held within the
tool's repository. or have the ability to generate enterprise
architecture models as a result of data manipulation functions.

27.7 Extendibility and Customization

This functional group captures how well an enterprise
architecture tool can be modified to meet the unique enterprise
architectural requirements of a unique organization. Enterprise
Architectwe tools may support customization by allowing users
to add new modelling approaches or to modify the modeI1ing
approaches already supported by the tool. A tool may also
support modification by providing a programming interface.
allowing the functions of the tool to be modified, or allowing the
tool to be integrated with other software products. Most
enterprise architecture tools that support high levels of
customization allow the underlying meta-models of the tool to
be modified. and new meta-models added. The ability to modify
the tool via a programming interface allows the functionality
and behaviour of the tool to be customized to meet the unique
requirements of the organization.

27.8 Analysis and Manipulation

As well as supporting the development of enterprise architecture
models. an enterprise architecture tool may also provide support
for analysis and manipulation of the developed models. The
type of analysis and manipulation support provided by the tool
is often tied to the particular modelling approaches supported
by the tool. For example. Flow Analysis is often tied to
process / workflow modelling.
Analysis support provided by a tool may simply examine how
correct or complete the model is. relative to a particular

- 204-

How 10 su~ irl lilt jUrlglt

of EnltrprN Archiltcfurt Fmmnrorb

modelling approach used . More sophisticated analysis support

may allow the model to be interrogated in some way, or be
subjected to particular analysis methods. Analysis support may
include the ability to compare different versions of models,
allowing current and to-be enterprise architectures to be
compared. Manipulation functions capture a tool's ability to
change the way the models are represented and viewed. This
may include the ability to view models from particular
perspectives, for example showing only particular classes of
entities, or the ability to amalgamate separate models into a
single model.

27.9 Repository
Most of the tools on the market make use of some kind of data
repository to hold the developed models. The functions
provided by the tool's repository have a significant impact on
the overall functionality, scalability and extendibility of an
enterprise architecture tool.
Some tools make use of commercial relational database
management systems, or commercial Object Orientated or
Object/Relational database systems, while others use
proprietary repository systems.
A tool's repository often dictates the way users can collaborate.
A repository may provide support for collaboration by
supporting multiple, concurrent, users on the one repository, or
by prOViding the ability to combine models developed by
different modellers into one model.
The repository may also provide many different data
management functions, including the ability to support model
versioning, the ability to roll back to previous versions, the
ability to lock parts of the model against change, and the ability
to control access to part or the entire model.

205

CrtOting or Choosing lin

Enltrp~

Archittduft Fn""nlorlc:

27.10 Overview of popular EA Tools

- 206pr "'"

How 10 sutvivc1 in 1M junglt of Enltrp,w Ardriltclurt FmllU!WOrics

28 Examples of some EA Repository Tools &

Suites

28.1 USA-Federal Enterprise Architecture

Management System C
The Federal Enterprise Architecture Management System
[FEAMS} tool is a U.S. govemment-owned, Webbased tool used
to track and analyse an organisation's enterprise architecture. As
an automated tool, FEAMS simplifies the management of a large
amount of information and provides access to this information,
relationships among information elements, and work products.
FEAMS is becoming a popular tool in the USA federal IT
community with approximately 21 federal organisations in the
process of reviewing or implementing it. FEAMS is not perfect,
and several "early adopter" organisations have identified
necessary modifications and desired enhancements. However, it
does not make business sense to have separate federal
organisations making enhancements to FEAMS at the same time.
Doing so could result in: - Spending money for multiple fixes to
the same problem simultaneously, .. FEAMS - fracturing- with
multiple incompa tible versions of FEAMS arising, and - An
uncoordinated approach that puts the government in a weak
n egotia ting position when dealing with s upport contractors and

will most likely lead to higher support costs.

Thus, a consortium of federal agencies is working to manage
FEAMS an open source d evelopment project. Specifically, the
U.S. Departments of H ousing and Urban Development,
Agricultwe, and Labour, and the National Technology Alliance
Cl

U.S. g~mcl l; SoUra': hllpJ/ftapmo.gov!fmmsASp

- 207 prNO"

CrtQling or Choosing an Enltrprise Archilfurt Framawrt

ann of the National Imagery and Mapping Agency are in the

process of taking FEAMS open source .
...-., .

--_.__.......

._.
.-- ,--_. - -- , .,.
--........ -_.
~-

-.~

... 'c'

'''''''''-

"n_

~-

~. -

FE~TooI

28.2 Popkin System Architect"

System Architect is a comprehensive and powerful modelling
solution designed to provide all of the tools necessary for
development of successful enterprise systems. It is the only tool
to integrate, in one multi-user product, industry-leading support
for all major areas of modelling, including business process
modelling, object-oriented and component modelling with UML,
relational data modelling, and structured analysis and design.
All hUlctionality is harnessed within System Architect's
extensible repository with native support for Microsoft VBA.

o Popkin Software; Sysltm Archittcl iJ rrgisltrtd by Popkin Softwal't; Soura:

hllp://www. popkin.coml

- 208 -

How to suroWe i1l

t~

jlmglt of E1Ittrprist Archittcfurt FramtWOrb

Over the last few years, organisations have become more aware
of the growing need to develop integrated models of their
business in order to remain competitive and flexible to change.
To this end, interest in industry-accepted Enterprise Architecture
Frameworks (for example, the Zachman Framework and
DoDAF (C4ISR Framework has increased dramatically.
The System Architect: FrAmework Manager
To make navigating and viewing all of these models easier from
a framework perspective, the new System Architect Framework
Manager has been introduced . The System Architect Framework
Manager enables users to view and access the models and
artefacts they have developed in a System Architect
encyclopaedia through a framework interface. Each cell of the
framework can be opened to view a filtered browser list of all
diagrams and definitions in the encyclopaedia that pertain to
that cell of the framework. Users may use predefined, industry
accepted, frameworks such as the Zachman Framework or the
US Department of Defence Architecture Framework (OODAF more commonly known as the C4lSR framework) that are
provided by Popkin, or build their own framework browser to
support their own custom framework.

28.3 Metis - Cornputas"

M etiS is a powe rful visual modelling tool that h elps you by

using complex enterprise knowledge to answer critical questions

and solve business problems. Metis allows you to capture and
link information in multiple areas of an enterprise, from
products to processes to systems. View your enterprise as a
whole or focus in on the details. By analysing infonnation and

CComputJu Nonwy; Mdis is rtgistunl by Computlfs; Souru: http://www.mdis.lIO/

- 209-

Cmlling or Choosing an nl~risr Archiltcfurtl Fmmnwrk

relationships, you can determine the effect of changes and make

informed decisions about your business.
Metis is consistently ranked as one of the world's leading
products in the field. Metis was recently certified as TOGAF 7
compliant, and supports UML, C4ISR and TEAF/ FEAF.
The field of Enterprise Architecture is one in which the strengths
of Metis are clearly seen. In order to optimise the use of
Information Technology by complex, often global organisations,
Enterprise Architects need a tool that not only can represent
complexity, but also aid in analysis, and in producing output
that is intelligible to many different user groups. The Metis ITM
(EAHemplate provides the necessary starting point for a
successful Enterprise Architecture.
Computas and its partners offer a rich selection of MetiS
templates, metamadels and starter models, minimizing the time
and resources required to create highvalue, customized
business solutions for your modelling needs.
Metis templates support Enterprise Architecture, Process
Modelling, Business Strategy, IT Architecture, Project
Management, Document Knowledge Management, and many
other model types. MetiS is unique in letting you integrate all
these models into holistic, enterprie.wide model structures,
thus enabling true Visual Enterprise lntegration.

28.4 MEGA Integrated Modelling Environmente

The MEGA Integrated Modeling Environment is supported by
MEGA's common repository architecture. This robust, scalable,
object~riented repository fully supports enterprise architects
teams ensuring the fullest collaboration and information sharing.
C

Copyriglll C M ECA

Inlt:nl~ /iol'ltll,

IIIC.; htlp;//l.uwUI. rnt'gII .coltl

- 210prNO"

How to survivt in the jungle of Enttrprist Archittdurt FrcrmttOOrXs

Through enterprise blueprints, business analysts, IT architects

and development teams operate in an aligned and highly
productive environment. Dedicated MEGA products facilitate a
comprehensive and streamlined approach to business process
and enterprise architecture design and implementation.
MEGA
products are complemented
with ex.tensive
administration facilities with full support for document and
intranet publishing, repository import, / export and generation
capabilities. MEGA Supervisor provides the team management
facilities required for business and IT to deliver complex projects
and specialized publishing requirements. MEGA products offer
full customization capabilities that allow MEGA deliverables to
accommodate the requirements of your organization.

28.4.1 MEGA Process

MEGA Process provides powerful analysis and design capability
for capturing, mapping and documenting business processes
and organizational structures. MEGA Process provides decision
support and impact analysis for multiple design scenarios.
Simulation features and variant management capability enable
dynamic scenarios for costs and resource analysis. With
scenarios comparison, MEGA Process unlocks the road to
process optimization.
With its powerful Repository and easy to use graphical tools,
MEGA Process captures and manages your company's business
process maps. Usc of the RepOSitory ensures consistency and
traceability e.g. changes a name in one model and has it
automatically propagated to all other models using the same
object. MEGA Process automatically produces documentation
and HTML websites for sharing within the project team and to a
wider company audience. Such documentation can be used as a
decision making tool for business managers.

- 211 -

CrtDfing or Choosing,n Enferprise ArchiltdllTl.' Frrllt~Wf}rl:

28.4.2 MEGA Architecture

MEGA Architecture delivers Business and IT Managers the
reference maps they need to align and fully integrate business
and IT. CIOs, IT Directors and Enterprise Architects can validate
IT investments and minimize development costs and
deployment risks.
MEGA Architecture provides advanced modeling features to
build application portfolios and deliver the application
perspective of Enterprise Architecture maps. MEGA
Architecture provides an information flow centric approach that
exposes how IT systems support enterprise business processes
and operations. Using City Planning techniques, IT managers
can establish plans for developing new applications and revising
old applications based on the enterprises objectives and goals.
Taking into account the fast changing business requirements and
technology offering, IT Professionals can deliver continuous
application optimization and cost reduction.
28.4.3 MEGA Designer
Analysis & Design Tools and Methodologies are key factors in
developing flexible IT systems that are in alignment with
business objectives and requirements.
MEGA Designer is the modeling based solution of choice to
produce arcrutf'Ctwe for the development of responsive,
adaptive new applications and to control and manage enterprise
data assets.

- 212~

'"

How to survive' in the jungle of Enttrpri# A.rchit turr: F11ImtwlJrb

29 Acronyms & Glossary

ADM

Architecture
Development Method

TOCAF Architecture Development

M,thod
(http://www .opei1group.org/ archite

cturell
AF

Architecture Framework Typically a collection of guidance for

developing and or documenting
Architectures.

CADM

Core Architecture Data A fonnal model defining the data

organisation for a repository of
Model
C4ISR/ DoDAF-compliant
architecture products.

C4ISR

Command,
Control,
CommunicaUons,
Computers, Intelligence,
Sun-eillance,
and
Reconr"laissance

ClMOSA

Computer
Integrated European standard for enterprise
Manufacturing
Opensystem
integration
in
the
System Architecture
manufacturing environment

CIO

Chief InformaHon Officer

OingerCohen

The Clinger.cohen Act of Also known as the InfonnaUon

1996
Technology Management Refonn Act,
ITMRA
or
Ihttp://wwwoinn.nih.gov / policy / it
mn.hlml]

CMM

Maturity Cal?"bility Maturity Model is

regastered in the US. Patent and
Trademark Office by Ca"'egie Mellon
University.
Commercial off the Shelf

COTS

Capability
Model

- 213-

CrMling or Choosing an Enlnprist Archiltdun Fr'Il~ri:

OARS

US DoD Architecture A DoD iepository for approved

Repository System
architecture information compliant
with the DoOAF.

000

us

01

Department

"'I~

DoOM

us

EA

Enterprise Architecture

ElA

Extended
Architecture

E2AF

Extended
En terpriseSel'Y tce Marks of the Institute For
Architecture Framework Enterprise
Architecture
Developments, the Netherlands.

ElAMM

Extended
Architecture
Model

EAESC

Enterprise Architecture
ExecutivE
Steering
Committee

EAP

Enterprise
Planning
Enterprise

EAPMO

FEA

FEA'

Department
of
Defence
Architecture
Framework
The oollection of infonnation, models,
technologies, prOCESSes, and plans
that
underlies
organisational
functions.

Enterprise E2A~ ok
Extended
Enterprise
Architecture are Service Marks of
the
Institu te
For
Enterprise
Architecture
Developments,
the
Netherlands.

EnterpriseServke Marks of the institute For

Maturity Enterprise
Architecture
Developments, the Netherlands.

Arch itecture

Architecture The
USA
Federal
Enterprise
Prognom
Management Architecture Progra m Management
Office
Office (FEA-PMO)
Federal
Enterprise [http://www.f4:'iIpmo.govl
Architecture (USA)
Federal

Enterprise

- 214 -

CrtfJting or Choosing lin

Ent~

Archittcturt Fnlmnrort

TAFIM

Technical
Architecture
for Infonnatioo Systems
(USA DoD)

TEAF

Treasury
Enterprise
Architecture Framework
(USA)

TOGAf

The
Open
Group
Architecture Ffamework Ihttp: //www.opengroup.org/ ardlite
cturelJ

nSAF

Treasury

Infonna tion
Systems
Architecture
Framework (USA)

TRM

Technical

Reference The Open Group or DoD TRM

Mod~

W3C

Wide
World
Consortiu m

ZlfA

Zachman

Institute

Web (hllp:! I www.w3c.org]

for (http: / /www.zil.a.coml

Framework
Advancement

- 216-

CM/ting or Choosing an EntnpriM ArchittCtllrt Fm~,*

18. King, 1995: "Creating a strategic capabilities

architecture." Injonnatiotl Systems Marlllgement, Vol. 12,
No. 1, pp. 67--69, 1995, William R. King, Professor
University of Pittsburgh, USA.
19. Nolan & Mulryan: Richard L. Nolan and Dennis W.
Mulryan, "Undertaking an Architecture Program," Stage
by Stage, Vol. 7, Number 2 (March-April, 1987).
20. Porter; Book, 'Competitive Strategy'; Porter, Michael E.
1980.
21. Saarinen. 1956; Eero Saarinen, President of the
Cranbrook Academy of Art.
22. Saint-Exupery; 'The Little Prince', Antoine de SaintExupery, 1900 - 1944.
23. Spewak, Steven H. 1992; Enterprise Architecture Planning.
New York: John Wiley & Sons.
24. Gansler, Jacques 5 . Arthur L. Money, and John L.
Woodward, Jr., 2<XXJ; TAFIM.
25. US Dept. of the Treasury 2IXXJ; The Treasury Enterprise
Architecture Framework, Version 1.0.
26. The Open Group; TOGAF, Version 8.0.
27. Villiers de, D. J. 2001 ; Using the Zachman Framework to
Assess the Rational Unified Process, The Rational Edge
2001.
28. Australian Defense Force; A Review of Architecture
Tools, DSTD-TR-1l39, 2001
29. Zachman, J. A. and J. F. Sow.l99~ Extending and
Formalizing the Framework for Information Systems
Architecture, IBM Systems }ountllI. (31) 3: 590-616 (1992).
30. Zachman, J. A.; The Zachman Institute For Framework
Advancements.

- 218-

How to survive in the ;ungle of Enterprise ArchitrxtUTe Frtl~

31 Related Links
o

C41SR Architecture Framework;

http://www.defonse/ink.mil/c3i/org/do/i3/

Zachman Institute for Framework Advancement;

htlp://www.zifocom/

The Federal Enterprise Architecture Framework, and the

CIO Council Web page for information on FEAF;

hllp,/lwwwfrDp""'g""ifrD.asp
o

Joint Technical Architecture, JTA Development

Organisations, Documents, and Participation Information;
htlp://wwtlrjttJ. itsi.disa.mil/

The Treasury Enterprise Architecture Framework and the

Treasury Department official Web version of TEAF;
http://www.ustreJls.gov/o/fius/malUlgement/do/tetl//

Extended Enterprise Architecture (E2A) Framework, the

Institute For Enterprise Architecture Developments;
http://www.enterpn5t-ll.rchiledurt.info

Technical Architecture Framework for Information

Management (TAFIM), Version 3.0; US Deparbnent of
Defence; http://wwtlr/ibrary.ifsi.disa.mil/lajim/

Federal Enterprise Architecture Manageme nt Sys tem;

http://fNpnw.gOO!fetlms.asp

TOCAF Version 8: Enterprise Edition, the Open Group's

official Web version of TOCAF;
http://www.opengroup.org/archilecture!toga/

CIMOSA Association; http://www.dmosa.de/index.hlm/

- 219~

'"

Cmllillg or Choosing IlIl ElItnprise Arrhittdu" Frtlmnvork

"'Creating a strategic capabilities architecture," William R

King, Professor University of Pittsburgh, USA;
htlp://www.kalz.pill.edu/foc...pagtS/Killg.hlm

Eero Saarinen; http://www.vitruvio.ch/tirc/mlisters/sanrillm.htm

Antoine de Saint-Exupery;
htlp://www.thillkexist.rom/f.llgfish/Autlwr/x/Author_1147_3.htm

The Open Group; http://www.opengroup.org/

The USA Office of Management & Budget;

http://Www.whilehouse.gov!omb/

220

How to 511rvrVt in tlat jllng/I! of Entnprist Archittctllrt Fmmnwrts

32 About the Author

Jaap Schekkerman (1953) received an engineer's
degree in electronic engineering and
information technology and a degree in clinical
chemistry and business economics.
From 1973 till 1974, he was working as a
scientist at the Free University Amsterdam.
From 1974 ti111985, he was Chief Wormation Officer at the Red
Cross Hospital Beverwijk, the Netherlands.
In 1982, Schekkennan was awarded with the American Ames

Award for his international awarded article about the

developments in medical information technology and the
influence on human beings.
From 1985 till 1995, he was Manager of a Research &
Deve10pment department and Manager of a Technology
Consulting Group at RAET N.V.
The focus of his R&D activities was at Wormation Systems
Architecture and multi-user / multi-tasking programming.
In 1995, Schekkerman joined Capgemini and became the
Thought Leader in the areas of Business Technology Strategy &
Enterprise Architecture.
In 2001, Schekkerman founded the Institute For Enterprise

Architecture Developments to do research and knowledge

exchange around Enterprise Architecture.
This institute is today one of the most important EA sources of
information in the world .
Schekkerman is giving lectures on the topics of Information
Management & Enterprise Architecture at several Universities
and training institutes.

- 221 -

CrtIlting or Choosing In Enterprise Archittdllrt frarnt'l.OOrl;

Schekkerman has published several methods, articles and books

on topics related to Enterprise Architecture and he is a
frequently invited speaker on national and international
congresses and symposia.
For his most recent publications go to the website of the Institute
For Enterprise Architecture developments:
http://www.enterprise-archiledure.info
Member ships:
o Alliance member of the Federal Enterprise Architecture
Certification Institute, USA.
o Member of the 'MANYWORLDS' knowledge network of
Business Thought Leaders, USA.
a Member of the IEEE 1471 (Recommended Practice for
Architectural Description) working group of the
Institute of Electrical and Electronic Engineers (IEEE)
USA.
o Member of the World Wide Institute of Software
Architects (WWISA) USA.
o Member of the Netherlands Society of lnfonnation
Architects (GIA) NL.

- 222-