THIRD EDITIONAn Introduction toEnterprise Archit.docx

THIRD EDITION
An Introduction to
Enterprise Architecture
Scott A. Bernard
EA3 Cube Framework ™
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network

Infrastructure
Network
Infrastructure
Networks &
Infrastructure
Systems &
Applications
Data &
Information
Products &
Services
Network
InfrastructureNetwork
InfrastructureGoals &
Initiatives
Lines of Business
C
O
M
P
O
N
E
N
T
S

S
ec
ur
it
y
/ S
ta
nd
ar
ds
/
S
ki
lls
Te
ch
n
o
lo
g
y
–
B
u

si
n
es
s
–
S
tr
at
eg
y
AuthorHouse™
1663 Liberty Drive
Bloomington, IN 47403
www.authorhouse.com
Phone: 1-800-839-8640
© 2012 by Scott A. Bernard. All rights reserved.
No part of this book may be reproduced, stored in a retrieval
system, or transmitted by any
means without the written permission of the author.
INTERNATIONAL EDITION Copyright © 2012.
Exclusive rights by Scott A. Bernard for translation,
manufacture, and export.
Published by AuthorHouse 08/07/2012
ISBN: 978-1-4772-5800-2 (sc)

ISBN: 978-1-4772-5801-9 (e)
Library of Congress Control Number: 2012914406
Any people depicted in stock imagery provided by Thinkstock
are models, and such images
are being used for illustrative purposes only.
Certain stock imagery © Thinkstock.
First published by AuthorHouse 08/25/04 (First Edition)
08/25/05 (Second Edition)
This book is printed on acid-free paper.
Because of the dynamic nature of the Internet, any web
addresses or links contained in this
book may have changed since publication and may no longer be
valid. The views expressed
in this work are solely those of the author and do not
necessarily reflect the views of the
publisher, and the publisher hereby disclaims any responsibility
for them.
Table of Contents
Foreword 7
Preface 11
Section I. The Concept of Enterprise Architecture
21
Case Study: Danforth Manufacturing Corporation
23
Introduction: Will this be an Architected Enterprise? 29
1 An Overview of Enterprise Architecture 31

2 The Structure and Culture of Enterprises
51
3 The Value and Risk of Creating an Enterprise Architecture
67
Section II. Developing an Enterprise Architecture
81
4 Implementation Methodology 89
5 Documentation Framework 103
6 Architecture Components and Artifacts 117
7 Developing Current Architecture Views 141
8 Developing Future Architecture Views 165
9 Developing an Enterprise Architecture Management Plan
181
Section III. Using an Enterprise Architecture 199
10 The Role of Investment Planning and Project Management
205
11 The Role of Security and Privacy 221
12 The Enterprise Architecture Repository and Support Tools
233
Section IV. Future Trends in Enterprise Architecture 251
13 Future Trends in Enterprise Architecture 253
Concluding Thoughts 265
Appendices
A Business Case for an Enterprise Architecture Component 267
B Example Approach to Architecture: Federal Government 271
C Example Approach to Architecture: State Government 277
D Example Approach to Architecture: Defense Department
279
E Example Approach to Architecture: The Open Group
281
F Examples of Enterprise Architecture Artifacts 283

Glossary of Terms 331
Subject Index 335
An Introduction to Enterprise Architecture – 3rd Edition 7
Foreword
By John A. Zachman
I am delighted that Scott Bernard has written this book, “An
Introduction to
Enterprise Architecture.”
We need as much focus on this critical issue as possible,
especially in the
academic environment and especially as we continue the
transition into the
Information Age. It is my opinion that this issue of Enterprise
Architecture is
not well understood in the ranks of General Management who
see Enterprise
Architecture as just an I/S or IT issue, nor in the ranks of I/S
management who
see it as taking too long and costing too much, nor in the ranks
of academia
who tend to focus on what they perceive constitutes current
market demand,
typically a promising technology. My opinion is, Enterprise
Architecture may
well be the “Issue of the Century.” In fact, I felt strongly
enough about this
issue that I published an article by that title in the year 2000,

the turn of the
Century.
Exacerbating the problem, we seem to have raised a generation
of people, the
“web generation,” who are facile with the technology, but as a
result seem to
think that the solution to all problems lies in technology. They
are tempted to
see strategy and architecture, engineering and design, modeling
and
methodologies as prehistoric, the preoccupation of cave men.
Now, real men
do Java … or whatever constitutes the current “silver bullet,”
technological
panacea.
I have a wise and profoundly insightful friend, Roger Greer,
who was the
Dean of the School of Library and Information Management at
the University
of Southern California. I sat on his advisory council for many
years and he
observed that a few decades ago, the library community became
enamored
with the technologies of the library and lost sight of their
reason for being,
which he argued was to identify problems of the community and
to assemble
the required knowledge to bring to bear and participate in
solving the
problems. Now it appears that many universities are de-
committing the
Library Schools because they are simply technical, storing and
retrieving
books. There is no conceptual substance requiring research or

advanced
degrees. You can learn how to store books and find them again
in secondary
schools. In fact, USC discontinued Roger’s School because of
the persistence
of the technical perceptions on the part of the Administration.
In fact, I was
having lunch with the Dean of the Library School at the
University of
California, Berkley the day they de-committed that school on
the same basis.
In “The Next Information Revolution” article published in
Forbes ASAP
August 24th, 1998, Peter Drucker observes that the present
information
revolution is actually the fourth information revolution. “The
printing
revolution (the third information revolution) immediately
created a new and
unprecedented class of information technologists … who
became great stars
… great gentlemen … revered all over Europe … courted by
kings, princes,
the Pope … showered with money and honors. … The printers,
with their
focus on technology (later) became ordinary craftsmen …
definitely not of the
upper class. … Their place was soon taken by what we now call
publishers …
whose focus was no longer on the ‘T’ in IT but on the ‘I.’… Is
there a lesson

in this for today’s information technologists, the CIOs in
organizations, the
software designers and developers, the devotees of Moore’s
law?” (said Peter
Drucker).
Several months ago, I saw an old friend, Gordon Everest, the
originator of the
“crow’s feet” in logical data models. Gordon is retiring this
summer because
the Information Systems Department of the Business School at
the University
of Minnesota is being de-committed. In fact, I am afraid that
the same thing
may have happened at the Business School, Information
Systems Department
at UCLA as I have not seen any of my academic friends from
UCLA for
several years.
I know I have a rather radical view of this, but my observation
would be the
whole reason you want people with technical skills in your
Enterprise is not
for building and running systems. Anybody can build and run
systems, the
employment of the technology. The reason you want these
kinds of people in
your Enterprise is because they have the capability of
engineering and
manufacturing your Enterprise for you. That’s the reason for
their being, NOT
simply for building and running systems.
I have some strong convictions that the raw material for
engineering and

manufacturing Enterprises are primitive models, not composite
models.
Composite models are for implementations, the embodiment of
the
technologies. Primitive models are for architecture,
ENTERPRISE
Architecture. I don’t think it is possible to engineer and
manufacture
enterprises without building and managing primitive models. It
is similar to
elements and compounds. Before Mendeleyev defined the
periodic table of
elements, chemistry was not a science. It was alchemy, working
with
compounds, trial and error, unpredictable. In like fashion, I
believe that until
Enterprise Architects understand and manage the primitive
(elementary)
constructs, Enterprise Architecture is dealing with composites
(compounds),
technical implementations. It is not a science and is not
predictable and it is
not engineering and manufacturing Enterprises.
Although, Scott does not necessarily share my rather strong and
radical
convictions, he graciously makes reference to them several
times in the body
of his work, which I greatly appreciate.
In any case, I feel strongly, we must infuse these critical
Enterprise

Architecture ideas into the next generation, through the
academic
environment. We sorely need a generation of people who
understand and are
committed to these complex issues that will persevere and see
Enterprise
Architecture become a reality. If we fail to bring these longer
term issues into
focus and continue only to focus on technology, on
implementations, short
term propositions, we will not only sacrifice our legitimacy as a
discipline, but
from an Enterprise standpoint, may even forfeit the Enterprise’s
continued
viability.
I was visiting a major telecommunications service provider
recently in which
some of the management folks got into a rather heated
discussion about what
was more important, to serve the customer … or to increase the
stock price. I
would not argue that it is unimportant to increase the stock
price, but I would
suggest that this is a very short term perspective. If somebody
doesn’t pay
attention to the customer in this very competitive industry, you
may find
yourself out of the game in the longer term and your stock price
might not
even appear anymore in the newspaper. It is not EITHER the
short term OR
the long term. It is the short term AND the long term.
I am not arguing that technical implementations, composites,
building and

running systems in the short term are unimportant, but I am
arguing that if we
don’t pay attention to our reason for being, to engineering and
manufacturing
Enterprises, to primitive models, ENTERPRISE
ARCHITECTURE in the
longer term, we may well forfeit either our relevance as a
discipline … or
sacrifice the continuing viability of the Enterprise in the
process. Engineering
and manufacturing Enterprises is the context within which
building and
running systems becomes relevant. By the way, this has
profound conceptual
implications for research and advanced degrees in academia.
Scott Bernard has taken a major step in intensifying the focus
on these critical
issues and I am particularly pleased that he has produced this
work as a
textbook for the academic environment.
“Introduction to ENTERPRISE ARCHITECTURE”! Our hope
lies in the new
generation’s capacity to grasp its significance and persist in its
realization.
Thank you, Scott Bernard!
John A. Zachman
Glendale, CA 2004

Preface
Intended Audience
An Introduction to Enterprise Architecture is intended for
executives,
managers, practitioners, students, and others interested in
finding out what
Enterprise Architecture (EA) is all about. EA is as much about
the
purpose, structure, and functioning of enterprises as it is about
the systems
and technologies that support them. The concepts presented in
this book
are applicable to enterprises in the public, private and non-
profit sectors.
Hopefully the book will promote the discipline and support the
development of new courses on EA, as well as enhance and
update
existing courses on business strategy and planning, information
systems
analysis and design, operations research, government planning,
change
management, knowledge management, and project management.
Typically these courses are offered in graduate programs or the
later part
of undergraduate programs. Though it is not a prerequisite,
students using
this book may benefit from having prior business management
and/or
information technology knowledge.
Why I Wrote This Book
An Introduction to Enterprise Architecture is the culmination of

several
decades of experience that I have gained through work initially
as an
information technology manager and then as a consultant to
executives in
the public and private sectors. I wrote this book and produced
two updated
editions for three major reasons: (1) to help move business and
technology
planning from a systems and process-level view to a more
strategy-driven
enterprise-level view, (2) to promote and explain the emerging
profession
of EA, and (3) to provide the first textbook on the subject of
EA, which is
suitable for graduate and undergraduate levels of study. To
date, other
books on EA have been practitioner books not specifically
oriented toward
a student who may be learning the subject with little to no
previous
exposure. Therefore, this book contains references to related
academic
research and industry best practices, as well as my own
observations about
potential future practices and the direction of the profession.
The response to the first and second editions of this book from
teachers
and practitioners was overwhelmingly positive, which I am most
grateful
for. The changes presented in the third edition include a
discussion of EA

as a meta-discipline; the identification of six basic elements
that an EA
program must have; updates to the security and privacy chapter;
a
discussion of the use of EA in mergers and acquisitions; and
updates that
have occurred with other approaches to EA.
Relationship to Systems Analysis and Design
This book is a suitable companion to the numerous Systems
Analysis and
Design (SA&D) textbooks that are in use, as it can provide an
overarching
context and unifying framework for the system development
approaches
and documentation techniques described therein. An
Introduction to
Enterprise Architecture helps to set the context for SA&D
courses and
related professional activities. Without the context of EA,
systems
development efforts throughout an organization run the risk of
being
disjointed and duplicative…. a phenomenon that has occurred
during the
past several decades. This book provides a more detailed
explanation of
the EA concepts that are often only summarized in SA&D
textbooks, in a
way that compliments, extends, and refers to foundational
SA&D
concepts.
It should be noted that this book identifies EA documentation

techniques at
each level of a generalized framework and documentation
methodology,
called the EA3 “Cube” Framework. These documentation
techniques
originate from existing methods in strategic planning, business
administration, and technology development. While this book
identifies
and briefly describes these elements, it does not go into detail
or attempt to
build proficiency in a particular technique…. that is left to the
many other
books on strategy, business, and technology.
Relationship to Strategy and Business Planning
An Introduction to Enterprise Architecture provides a clear
explanation of
the relationship between strategic planning, business planning,
and
information technology planning. While IT resources are
increasingly
becoming a commodity, the importance of IT services as a
business
enabler continues to grow in many public and private sector
organizations.
In recognition of this, EA’s identification of integrated IT
solutions to
organization-wide (crosscutting) and mission-specific (vertical)
requirements is one of the focal points of this book. Strategic
goals and
business requirements should drive IT solutions, and EA’s
contribution to
this alignment is another focal point of the book. Finally, this
book

provides specific EA documentation techniques that create
strategy and
business-driven views of the enterprise, which in turn can help
to identify
gaps in performance that IT solutions can help to close.
Relationship to Component-Based and
Service-Oriented Architectures
An Introduction to Enterprise Architecture presents EA as a
holistic
management, planning, and documentation activity and
introduces the EA3
Cube Framework and implementation methodology. This
approach to EA
identifies distinct lines of business which encompass five sub-
architecture
levels and three common thread areas. The five sub-
architectures address
strategic initiatives; business services; information flows;
systems and
applications; and technology infrastructure. The three threads
are security,
standards, and workforce. The EA3 Cube Framework is
component-based
in that the “building blocks” of each of the sub-architectures are
‘plug-and-
play’ components. These components vary widely in their
purpose and
nature, but are increasingly interoperable and integrated due to
the
standards thread that promotes non-proprietary solutions. For
this reason,
architecture documentation approaches (such as the Model-

Driven
Architecture, or IT Infrastructure Library) can be used to
populate one or
more of the sub-architectures in the EA3 Cube Framework.
The EA3 Cube Framework not only recognizes and preserves
the role of
early architecture approaches that addressed data, applications,
and
networks, but also recognizes newer approaches that promote
strategic
scenario planning, the value of business supply chains, and
web-based
services. In particular, the ‘Business Services’ sub-architecture
within the
EA3 Cube Framework (the second level) exemplifies how EA
can link
strategy, business, and technology components across the
enterprise within
a “Service Bus” that encompasses platform-independent
horizontal and
vertical EA components. Services extend throughout the
framework, but
in my opinion have their origination of purpose at level two of
the EA3
Cube… being driven by strategic goals and initiatives (the
framework level
above the “Business Services’ level), and calling for supporting
information flows, systems, applications, and network
infrastructure
components (the framework levels below). Basic to the concept
of EA
components presented in this book is the idea that the
“Standards” thread
that enables interoperability within the Service Bus by
promoting the use

of EA components that are based on open-standards/protocols
and non-
proprietary solutions.
Organization of This Book
An Introduction to Enterprise Architecture is organized into
four sections
of material, a case study, and several appendices of amplifying
or
reference material. The case study is presented at the beginning
of each
section and before selected chapters to reinforce the application
of the
concepts in a variety of settings. The four sections are intended
to
sequentially develop the student’s understanding of the concepts
of EA, as
well as methods for implementing these concepts.
Section I provides an overview and context for the book,
identifies the
value and risk of doing an EA, discusses the structure and
changing nature
of enterprises, and shows how EA helps to link strategic,
business, and
technology planning. Section II defines and describes what an
EA
framework is, presents a step-by-step methodology to
implement an EA
through the documentation of current and future views of
resources, and
describes how to communicate changes in the EA through an EA

Management Plan that also can serve as a “blueprint” for
modernization.
Section III discusses how to use and maintain EA information in
an on-line
repository within the enterprise, and how governance processes
can be
integrated (e.g., investment planning, project management, and
security).
Section IV provides the author’s thoughts on EA as a profession
and
opinions on future trends. The Appendices amplify or extend
the material
presented in all Sections and are intended to be primarily for
student
reference. A glossary of key terms is provided along with
examples of the
EA documentation described in various chapters.
An Introduction to Enterprise Architecture is structured such
that each
section and chapter builds on the material previously presented.
The
sections and chapters are organized to promote understanding
and a
consistent, cogent flow of material by using the following
design:
Sections:
Overview. Describes the general purpose of the Section and the
contribution of each Chapter.
Case Study. An ongoing case study from the private sector that
provides scenes which make the concepts of the Section and
Chapters
more tangible and relevant.
Chapters:

Overview. Describes the purpose and key concepts of the
Chapter.
Learning Objectives. Lists the learning objectives for the
student in
that Chapter.
Introduction. Provides context and introductory commentary to
build
student interest in the main body of material.
Discussion. Provides the Chapter’s concepts through
descriptions,
graphics, and footnoted references.
Analogy Boxes. The analogy of the architecture of a house is
used
throughout the book to assist readers in understanding and
relating the
various concepts of Enterprise Architecture in a context that is
common to most students.1
Key Term Definition Boxes. Definitions of key terms are
provided
when they are first used to promote student understanding at the
time
that associated concepts are being presented.
Summary of Concepts. Provides a recap of the purpose of the
Chapter
and its key concepts, and introduces the following
Section/Chapter.
Review Questions and Exercises. Provides questions that
address key
concepts and exercises that allow students to further explore
key

concepts of the Chapter and tie-in concepts from other
Chapters.
General Comments
The EA3 Cube Framework, EA3, and Living Enterprise are
registered
Trademarks. All rights are reserved. Concepts for the EA3
Cube
Framework, EA3, Living Enterprise, and the Organizational
Network
Model were generally influenced by the works of John
Zachman, Steven
Spewak, Talcott Parsons, and James Thompson, as is
acknowledged
throughout the book. The specific concepts for the EA3 Cube
Framework,
EA3, Living Enterprise, and the Organizational Network Model
were not
developed as a result of, or influenced by, any other public or
private
sector enterprise architecture approach or graphic. Any
similarity to other
EA approaches or graphics is coincidental. Of specific note; a
cubic shape
is generic and may be in use with other systems development,
architecture,
and/or business planning approaches. The uniqueness of the
EA3 “Cube”
is the singular combination of all of its dimensions, functions,
levels,
components, and other attributes. The concepts and graphics in
this book
were originally presented in lectures given by Dr. Bernard at
various
1 Spewak, Steven. Enterprise Architecture Planning:

Developing a Blueprint for Data, Applications,
and Technology. New York: John Wiley & Sons Publishers.
1992. Dr. Spewak equated the
disjointedness of IT planning without enterprise architecture to
the haphazard construction of the 160-
room Winchester House in California over a period of 38 years
without a master building plan.
academic and professional conferences in 2002-2003 and are
copyrighted
by Dr. Bernard separate from this or any other publication.
Permission for
the use of the EA3 Cube Framework, EA3 logo, Living
Enterprise, and
Organization Network Model is given for use in this book.
Acknowledgements
I would like thank my colleagues and former students in the
growing field
of EA for their encouragement in writing An Introduction to
Enterprise
Architecture. John Zachman’s Foreword is a wonderful
contribution to the
book that in my opinion gives new students to the subject of EA
the best
possible beginning for their studies. In the view of many, John
Zachman is
the founder of Enterprise Architecture as it has come to be
known, and I
sincerely thank him for writing the Foreword. John got it right
when he
introduced the Information Systems Architecture in 1987,2 and

he has
continued to provide on-target architecture consulting, training,
and
mentoring on a global basis ever since.. remaining an active
teacher,
lecturer, and practitioner in 2012 as this edition is published. I
believe that
John’s emphasis on the basics, on using “primitive” EA artifacts
that focus
on discrete aspects of an architecture, is not in conflict with the
EA3 Cube
framework or documentation methodology. My work is
intended, in part,
to extend that focus and to discuss the utilization of what John
refers to as
“composite” EA artifacts which combine several types of
primitives to
form specialized views of an enterprise…. views that are often
helpful to
managers and executives. My bottom line position is that
without solid
EA primitives, the composite artifacts are not possible to
develop.
I would also like to thank and remember Dr. Steven Spewak
who helped
start the profession of EA. Steve was an inspirational mentor to
me during
my initial years as an architect. He passed away in March 2004
a few
months before the first edition of this book was published…. he
is sorely
missed by many in our profession.
It is both exciting and challenging to be part of a still young
profession,

and I salute those who endeavor to develop enterprise
architectures for
public and private sector organizations. To them I would say
good luck,
the work ahead of you will be frustrating at times, yet fulfilling
as the
contribution of EA to organizational success is fully realized.
2 Zachman, J.A. A Framework for Information Systems
Architecture. IBM Systems Journal: Volume
26, Number 3, Page 276. 1987.
One more thought. My father was a successful land developer
and home
builder who learned the essentials of traditional architecture on
his own.
There are many parallels in our lives, and this is yet another.
As the head
of information technology enterprises and projects, I found that
I needed
some way to organize the perpetual chaos of systems
development and
upgrade projects, ongoing operations, and more than occasional
surprises.
Because of this, I learned about EA, which helped to establish a
reference
framework for planning and decision-making…. the most
valuable tool
one can have in a dynamic field like IT management. Now,
with greater
appreciation, I enjoy being part of the growth of this field,
which in many

ways is like the one that my father came to know… a nice
blessing in the
journey of life.
This book is dedicated with love
to my wife Joyce
and our children
Bill, Kristin, and Katie
About the Author
Scott Bernard has nearly thirty years of experience in
information
technology management, including work in the academic,
federal
government, military, and private sectors. Dr. Bernard has
served as the
United States Federal Chief Enterprise Architect with the
Executive Office
of the President’s Office of Management. He has also held
positions as a
Chief Information Officer (CIO), IT management consultant,
line-of-
business manager, network operations manager,
telecommunications
manager, and project manager for several major IT systems
installations.
He has developed enterprise architectures for a number of
public and
private sector organizations, started an enterprise architecture

practice for
an IT management firm, developed his own consulting practice,
and taught
enterprise architecture at a number of universities, businesses,
and
government agencies. In 2002, Dr. Bernard created the EA3
CubeTM
framework and methodology that is featured in this book, as
well as the
design for an on-line EA repository that is called Living
Enterprise.TM
Dr. Bernard has served for over a decade on the faculty of the
School of
Information Studies at Syracuse University. He is also a Senior
Lecturer
in the Executive Program of the CIO Institute and the Institute
for
Software Research at Carnegie Mellon University’s School of
Computer
Science. Dr. Bernard was the founder of the Association of
Enterprise
Architects, and first editor of the Journal of Enterprise
Architecture, which
is still published to a world-wide readership.
Dr. Bernard earned his Ph.D. at Virginia Tech in Public
Administration
and Policy; a master’s degree in Business and Personnel
Management from
Central Michigan University, a master’s degree in Information
Management from Syracuse University, and a bachelor’s degree
in
Psychology from the University of Southern California. He is a
graduate
of the Naval War College, and earned a CIO Certificate and an

Advanced
Management Program Certificate from the National Defense
University.
Dr. Bernard was designated a member of the Federal
Government’s Senior
Executive Service in 2011. He is also a former career naval
aviator who
served onboard aircraft carriers and with shore squadrons, led
IT programs,
and was the Director of Network Operations for the Joint Chiefs
of Staff.
Section I
The Concept of Enterprise Architecture
Section I presents an introduction to the subject and concepts of
Enterprise
Architecture (EA), as well as an overview of the purpose and
value of EA
for business, government, and non-profit organizations. A case
study
based on a fictitious business is introduced that will help the
student to
understand and apply EA concepts. Section I is organized as
follows:
Case Study Scene 1: Possible Need for an EA Program
Introduction Will this be an Architected Enterprise?

Chapter 1 An Overview of Enterprise Architecture
Chapter 2 The Structure and Nature of Enterprises
Case Study Scene 2: Considering an EA Program
Chapter 3 The Value and Risk of Creating an Enterprise
Architecture
Case Study (Scene 1) - Possible Need for an EA Program
The Case Study introduces the Danforth Manufacturing
Company3 and
several business and technology challenges that will cause the
company
to consider using EA to improve planning, decision-making, and
solution implementation.
Introduction – Will this be an Architected Organization?
Enterprise Architecture is becoming increasingly recognized as
the only management and technology discipline that can
produce
holistic designs for organizations that are agile and all-
encompassing. Whether an organization uses EA in this way
becomes the question, and if not, what are the consequences.
Chapter 1 - An Overview of Enterprise Architecture
Chapter 1 provides the student with an overview of the
emerging
profession and practice of EA. The chapter’s discussion
introduces the
concept that EA provides a holistic view of an enterprise. This
differs
3 The Danforth Manufacturing Company that is portrayed in

this Case Study is a fictitious enterprise.
Any resemblance to an actual business or similar business
activities is coincidental.
from the more system-centric or process-centric views that
previous
analysis and planning approaches have emphasized. EA is both
a
management program and a documentation method, and
comment is
made on the similarities and differences of doing EA in private
and
public sector enterprises.
Chapter 2 - The Structure and Culture of Enterprises
Chapter 2 describes the structure of enterprises and why it is
important
to include culture in the EA documentation effort. The driving
theme
of this chapter is that an enterprise involves one or more social
activities that involve the sharing of information. It also shows
that the
boundary between the structure of the enterprise and the culture
is
dynamic. The importance of stakeholder involvement and the
management of expectations are also discussed.
Case Study (Scene 2) - Considering an EA Program
The Case Study continues with the Chief Information Officer of
Danforth Manufacturing Company. The CIO makes a
presentation
regarding how an EA approach can help to evaluate several

requests for
IT systems, and coordinate their implementation.
Chapter 3 - Value / Risk of Creating an Enterprise Architecture
Chapter 3 discusses the value and risk of creating an enterprise-
wide
architecture. The main concepts of this chapter are (1) that EA
represents a different way of looking at resources across the
enterprise,
and (2) that the significant cost of creating an EA must be
justified by
the value that it brings to the enterprise by linking strategy,
business,
and technology. Another key concept is (3) that an integrated
set of
planning, decision-making, and implementation processes can
better
identify and resolve performance gaps across the enterprise, and
that
EA promotes this type of integrated governance. The
management of
change is discussed in terms of why an EA may not be accepted
or used
if stakeholder buy-in and participation is not achieved.
Case Study:
Danforth Manufacturing Company
Scene 1: Possible Need for an EA Program
The Danforth Manufacturing Company (DMC) develops,
produces, and
sells several lines of photovoltaic storage cells (solar-powered

batteries)
for use in various consumer, business, and aerospace products.
Robert
Danforth, the President and Chief Executive Officer (CEO) of
DMC, has
called a meeting of the Executive Committee to review several
recent
capital investment requests. The largest two of these was a
request by
Kate Jarvis, the Chief Operating Officer (COO), for a new sales
and
inventory tracking system and a request by Jim Gorman, the
Chief
Financial Officer (CFO) to invest in a new cost accounting
system. Also
invited to the meeting were Sam Young, the company’s first
Chief
Information Officer (CIO) who joined the company two weeks
before, and
Gerald Montes, the company’s Chief Counsel.
Robert Danforth was the last one to enter the executive
boardroom. He
smiled at his top management team and said, “Thank you all for
coming by
to talk a bit more about several investment requests that came
out of our
annual planning meeting last month. Sam, you hadn’t joined the
company
yet, so I’m particularly interested in your thoughts today.
Mainly, I want
to better understand from the group why our current capabilities
are
insufficient and how these new systems will help bottom-line
performance.
Kate, why don’t you go first and then we’ll hear from Jim.”

Kate rose and walked to an easel that held several charts and
diagrams.
“Gentlemen, as mentioned at the planning meeting, my request
for a new
Sales and Inventory Tracking System (SITS) is based on an
insufficient
current ability to match inventory and production information
with
customer orders. We are also experiencing excessive
turnaround time for
orders in the industrial product lines, as compared to our
competition. Our
sales representatives in the field are beginning to lose orders.
They can’t
provide on-the-spot quotes based on real-time checks of
available
inventory and current pricing. The same goes for our
representatives.
They are not able to see when the custom and small job
production runs
are being scheduled. This would help sales in this high-profit
area which
we will be expanding. Our major competitor fielded this
information
capability almost a year ago. While I was skeptical at the time
about the
impact it would have on their sales, I now believe that it’s a
successful
model for them and therefore is going to make or break us in the
industrial

product line.”
Robert leaned forward. “Kate, this sounds quite serious. Even
so, from a
cost perspective I am concerned about the return on investment
(ROI) for
SITS. Last month you stated that initial cost estimate for the
development
of SITS was over three million dollars. We have tight budgets
for the next
two years… have you looked at ROI?” “Yes,” responded Kate.
“These
charts show the level of investment and payback period for
SITS, which I
estimate to be two years, depending on how quickly and
thoroughly the
sales force adopts it. The lifecycle for SITS should be seven
years, with
positive ROI seen in years three through seven, and an average
of about
twelve percent per year.”
Robert turned to Sam, “What do you think Sam? Isn’t part of
the problem
here that many of our information systems don’t talk to each
other?” Sam
grimaced slightly and said, “I think you’re right, from what I’ve
seen in
my initial survey of information technology (IT) capabilities, a
lot of our
systems were built as individual projects based on what then
were unique
requirements. We now have some duplication of functionality
and
evidence of inefficient support for evolving business
processes.” Robert

responded quickly, “Isn’t the SITS proposal just more of the
same?”
“Perhaps” said Sam, “I’m hearing that Kate wants to integrate
information
exchanges across the sales, inventory, and production lines of
business.
This represents a somewhat higher-level approach to meeting
several
business requirements.”
Robert turned to Jim, “What do you think about Kate’s
problem? Jim
answered with a pensive look, “Well, I agree that we need to
address our
competition’s capability. While our aerospace product line is
the most
profitable, the industrial product line brings in the most
revenue, so there
would be a significant impact on the entire company if we lose
market
share in the industrial product area.” Robert then turned to
Gerald, “So
what does the Chief Counsel think?” Gerald paused for a
moment and
then said, “I think that we must act decisively to protect market
share in
the industrial product line, but I’m not sure that SITS is the
answer. You
might be right Robert, the proposal that Kate is making might
be more of
the same type of technology solution that Sam says got us in
this
situation.”

Robert leaned back in his chair and said, “Before going further
on this
proposal, let’s talk about Jim’s investment request. I wonder if
there are
any parallels.” Jim activated the conference room’s projector
and brought
up a set of briefing slides. “My request is for a cost accounting
system that
would replace the current accounting system. As Robert
mentioned, there
are tight budgets the next two years, and having the ability to
more readily
see spending and profit generation within each line of business
will help us
to manage the budget more effectively. This system is one
module of
“WELLCO” a proven commercial enterprise resource planning
(ERP)
product. We can utilize this product by expanding it if other
back office
requirements emerge. The cost of the investment is just under
$600,000.
According to the vendor, the historical payback period for this
cost
accounting module is eighteen months, with an average annual
ROI of
sixteen percent during the subsequent years.”
“Jim, can this new accounting capability support what Kate is
looking
for?” said Gerald. Jim responded, “The WELLCO module can
handle
some of the things Kate is probably looking for, including price
and

volume information in sales, inventory, and production
activities, but this
module is not configured to specifically support all of the
information I
believe she will need.” “Can it be modified?” Interjected
Robert.
“Possibly so,” said Jim, “and if not, I would think that other
modules of
WELLCO could handle it. Sam, help me out with this one if you
can.”
Sam responded, “I know that WELLCO is one of the leading
ERP
products designed to support many front and back office
functions. It
might be possible to get enough functionality to support both
Jim’s and
Kate’s requirements. I am concerned that we are still looking
at
requirements from a program-level and systems-level
viewpoint…
essentially bottom-up planning. Wouldn’t the company benefit
more from
a more strategic approach that evaluates requirements and
proposed
solutions across the entire enterprise in the context of our
strategic goals?”
The group was silent for a moment, and then Gerald spoke.
“Our annual
planning retreat is where most of the company’s strategic
planning
happens. We look at our current strategic goals and initiatives.
We look at
what changes are needed to keep us competitive. As you saw
from the
meeting last month, new proposals are also surfaced during the

retreat and
then followed-up on. That is to say if they merit consideration
for funding
and implementation.” Sam asked, “Is there some model of the
enterprise
that is used to support these discussions?” “Well, if you mean
our annual
business plan, we have that” said Jim. “More than that” said
Sam, “A
model of strategy, business, and technology that enables you to
see what
we have now and what is planned for the future. Something that
gives us
the ability to play with the model to see what other future
investment and
operating scenarios would look like.” “We don’t have anything
as fancy
as that” said Kate, “Though a model like that would have helped
me
analyze what we could do to help the field.”
Robert stood up and walked to the window. “Sam, you are new
to the
team, but sometimes a fresh look at a situation can provide
valuable
insights. What I believe you are telling us is that we lack a true
top-down,
strategy-driven capability to surface requirements and
solutions… is that
right?” “Yes” responded Sam. “DMC is not alone. Many
companies

have the same problem because they still support program-level
decision-
making. We tend to let it occur in a relative vacuum with few
overarching
goals and standards to guide analysis, planning, documentation,
and
decision-making. I am going to propose that both Kate’s and
Jim’s
proposals be reviewed through a different lens, that of an
enterprise-wide
architecture. If we had this type of model, we could see current
capabilities, future requirements, and gaps in our ability to meet
those
requirements. We could also see duplicative current
capabilities and future
solutions. From what I have heard at this meeting we may have
some
overlapping requirements which probably should not be met
with separate
solutions if we are to optimize our financial and technology
resources.”
“Interesting” said Robert. “Sounds like a silver bullet, and I am
wary of
those” said Gerald. Robert spoke again, “Sam, would an
enterprise-wide
architecture really help us? If it is doable, that’s great, but why
haven’t we
heard about it before? I know there are no free lunches and
where is the
ROI in such an architecture?” Kate added “While I appreciate
the idea, I
don’t have time to wait for the entire company to be modeled, I
need a new
capability now.”

“Well,” said Sam. “You are right, establishing an enterprise
architecture
will not be free and it will take time. Fortunately there are
approaches
being used by the public and private sector that support the
modeling of
requirements and solutions in a standardized way between
multiple lines of
business, which are referred to as architecture segments. So, as
each
segment is completed it adds to the architecture as a whole. By
treating
Jim’s area as the company’s financial segment, and Kate’s area
as the
production segment, we can just address these areas first,
thereby reducing
the time for completion of the architecture part of the larger
project that
may implement a combined solution. We can do this by
modeling only
those strategic drivers, business services, and technology
solutions that
apply to those two segments. Eventually though, for the
architecture to be
the most valuable to DMC, the entire company should be
modeled in its
current state, and several possible future states.”
“As far as ROI,” continued Sam, “that is more difficult to
pinpoint since
the cost of doing the analysis and modeling depends on the

amount of
existing information and the degree of cooperation that is
achieved with
stakeholders. By the way, these stakeholders include our
executives,
managers, and support staff. But let’s say that a top-down
architectural
analysis reveals that there are common requirements between
Kate and
Jim, and we can meet those requirements either through adding
functionality to SITS or by buying several more modules of the
commercial WELLCO product, and doing some customization.
We
potentially could save several hundred thousand dollars, or
perhaps
millions of dollars compared to doing SITS and WELLCO
separately… all
of which become ROI from the architecture effort. You
probably haven’t
heard about enterprise architecture because when a company is
doing it
well, it can become a strategic asset that makes the company
more efficient
and agile. That type of capability is normally not broadcasted.”
“So what’s the downside?” asked Gerald. “Enterprise
architecture tends to
be viewed as a hostile takeover by program managers and
executives who
have previously had a lot of independence in developing
solutions for their
own requirements” said Sam. “Also, architecture brings a new
language
and planning processes, which like any type of change can be
seen as
threatening to those involved and therefore may be resisted.

Strong
executive sponsorship and stakeholder involvement can
overcome much of
this.”
“Sam, the architecture approach seems to make sense, but I am
not
completely sold yet” said Richard. “Let’s do a pilot project. I
want you to
work with Kate and Jim and bring me a plan and business case
within two
weeks to develop the part of an architecture for DMC that
addresses their
current capabilities and stated future requirements. We’ll use
this as the
test for whether we want to go forward with an enterprise-wide
architecture. Thank you all for your time today, see you in two
weeks.”
Introduction
Will this be an Architected Enterprise?
Basically, I am asking whether an enterprise (often an
organization or part
of an organization) is going to be structured based on an over-
arching agile
design and set of standards for how work is done and
technology employed
- or is the enterprise going to consist of a collection of un-

coordinated
processes, programs, and systems? If the organization decides
to develop
and maintain an authoritative enterprise-wide architecture to
serve as a
primary reference for planning and decision-making, then
leadership and
management must embrace and implement this decision by
properly
resourcing the EA function and seeing that it is incorporated
into all
aspects of how the organization is run… called “baking it in.”
A similar question is faced when an enterprise considers making
a major,
holistic commitment to a quality assurance (QA) approach that
will be
consistently applied throughout all lines of business. To date,
many
enterprises have decided to do this only to find that their effort
fails when
leadership does not continually back it, especially if that
enterprise is not
used to standard processes and metrics. We saw how beginning
in the
1980’s QA made a tremendous difference in the competitiveness
of major
automotive industry players – with Japanese manufacturers
being the first
to take the QA plunge. Now, QA is baked into the culture of
auto
manufacturers around the world – and the products of the
surviving
companies are much better as a result. Some companies could
not adapt to
higher quality standards, and are no longer in business or lost

major market
shares. It should therefore be no surprise that many of these
surviving
companies began embracing EA during the past decade along
the same
path that their QA initiatives were implemented. Other industry
sectors are
doing this too – insurance, retail, and aerospace to name a few.
For some
governments, including the U.S. Federal Government, it is a
legal mandate
that agencies develop and maintain a holistic EA.
The existence of an organization chart, documentation on
processes and
resources, or employees who hold architect titles do not
necessarily mean
that the enterprise is “architected.” The litmus test for this is
similar to the
key question for QA adoption – does the enterprise consider the
architecture to be an authoritative reference and are the
associated methods
baked into how things are done every day… in other words, is
EA part of
the culture? If not, then there is a paper architecture that may
provide one-
time or occasional value – but not a living architecture culture
that
contributes to high levels of agility and performance on an
ongoing basis
across all lines of business, business units, and program offices.

Let’s say that an enterprise decides to not have an EA, for
whatever
reason. The main problems that I see are that leadership will
not have the
ability to generate clear, consistent views of the overall
enterprise on an
ongoing basis, they won’t be able to effectively compare
business units,
and the locus of power for planning and decision-making will be
at the
line-of-business, program, and/or system owner levels – with
significant
differences in how things are done and high potential for
overlapping or
duplicative functions and resources… waste and duplication.
Now let’s say that an enterprise decides to have an EA, and is
prepared to
maintain leadership backing and put resources behind it. This
would allow
the enterprise to avoid the problems just described and create a
culture of
ongoing controlled adaptation and optimization in response to
changes in
external and internal drivers. This sounds to me like a more of
a recipe for
success, especially in highly dynamic operating environments –
but to take
the test for your own enterprise – go ahead and ask “what would
happen if
we did not become an architected organization” and play out the
costs and
benefits, then ask “what if we do go with EA” and try to
identify the cost,
benefits, risks, and mitigation strategies.

On significant benefit for large private sector companies that
decide to be
an architected enterprise is that EA can play a key role in
evaluating
merger and acquisition (M&A) opportunities, whether that
company is
acquiring or being acquired. In that EA helps to rationalize and
align
strategic, business, and technology plans – and associated
processes and
resources – the architecture can clarify the capabilities, assets,
and value of
that company – potentially adding tens or hundreds of millions
of dollars
to the valuation and reducing risk in the post-
merger/acquisition period as
the resulting company makes dozens or hundreds of decisions
about what
business capabilities, systems, and groups should go forward,
and which
should be eliminated. A historical stumbling block to M&A
efforts is a
lack of understanding of the culture and capabilities of the
companies
being brought together – and EA can help with this throughout
the M&A
lifecycle – from initial due diligence research, to valuation
negotiations, to
post merger/acquisition streamlining and new product/service
rollouts.
This book is for enterprises that decide to take the plunge and
embrace EA
- I think they will find that it is a source of competitive
advantage.

Chapter 1
An Overview of Enterprise Architecture
Chapter Overview
Chapter 1 provides an overview of the discipline of Enterprise
Architecture (EA). The main concept of this chapter is that EA
is a
strategy and business-driven activity that supports management
planning
and decision-making by providing coordinated views of an
entire
enterprise. These views encompass strategy, business, and
technology,
which is different from technology-driven, systems-level, or
process-
centric approaches. Implementing an EA involves core
elements, a
management program, and a framework-based documentation
method.
Learning Objectives
Understand the purpose of EA.
Understand the elements of an EA management program.
Understand the elements of an EA documentation method.
Understand differences to other analysis / planning approaches.
Introduction
Enterprise Architecture is a management and technology
practice that is

devoted to improving the performance of enterprises by
enabling them to
see themselves in terms of a holistic and integrated view of
their strategic
direction, business practices, information flows, and technology
resources.
Key Term: Enterprise
An organization or sub-activity whose boundary is defined by
commonly-
held goals, processes, and resources. This includes whole
organizations in
the public, private, or non-profit sectors, part(s) of an
organization such as
business units, programs, and systems, or part(s) of multiple
organizations
such as consortia and supply chains.
Key Term: Enterprise Architecture
The analysis and documentation of an enterprise in its current
and future
states from an integrated strategy, business, and technology
perspective.
By developing current and future versions of this integrated
view, an
enterprise can manage the transition from current to future
operating states.
The strategic use of resources is increasingly important to the
success of
public, private, and non-profit sector enterprises, including

extended
enterprises involving multiple internal and external participants
(i.e.,
supply chains). How to get the most from business, technology,
and
human resources requires an enterprise to think in terms of
enterprise-wide
solutions, rather than individual systems and programs (Figure
1-1).
Doing this requires a new approach to planning and systems
development,
an approach that has come to be known as Enterprise
Architecture. The
word ‘enterprise’ implies a high-level, strategic view of the
entire entity,
while the word ‘architecture’ implies a structured framework
for the
analysis, planning, and development of all resources in that
entity.4
Figure 1-1: The Organizing Influence of Enterprise Architecture
4 The term “enterprise architecture” most likely came from
Steven Spewak, Ph.D. in his book
Enterprise Architecture Planning. John Wiley & Sons, 1992.
Video
Network
Strategy
Business
Information
Systems

B
usiness &
T
echnology A
lignm
ent
IT
Systems
Web
Services
Process 1
Process 2
Data
Network
Applications
Voice
Network
Systems
Web
Services
Process 1
Process 2

Data
Network
Applications
Voice
Network
Video
Network
Process 3
Strategic
Initiative 2
Strategic
Initiative 1
Strategic
Initiative 1
Strategic
Initiative 2
Data
Dictionary
Object
Reuse
Data
Flows
Object

Reuse Data
Dictionary
Data
Flows
Video
Network
Strategy
Business
Information
Systems
Networks
B
usiness &
T
echnology A
lignm
ent
IT
Systems
Web
Services
Process 1

Process 2
Data
Network
Applications
Voice
Network
Systems
Web
Services
Process 1
Process 2
Data
Network
Applications
Voice
Network
Video
Network
Process 3
Strategic
Initiative 2

Strategic
Initiative 1
Strategic
Initiative 1
Strategic
Initiative 2
Data
Dictionary
Object
Reuse
Data
Flows
Object
Reuse Data
Dictionary
Data
Flows
E
A
=
S
+
B
+

T
Network
Video
Network
Strategy
Business
Information
Systems
B
usiness &
T
echnology A
lignm
ent
IT
Systems
Web
Services
Process 1
Process 2
Data
Network

Applications
Voice
Network
Systems
Web
Services
Process 1
Process 2
Data
Network
Applications
Voice
Network
Video
Network
Process 3
Strategic
Initiative 2
Strategic
Initiative 1
Strategic
Initiative 1

Strategic
Initiative 2
Data
Dictionary
Object
Reuse
Data
Flows
Object
Reuse Data
Dictionary
Data
Flows
Video
Network
Strategy
Business
Information
Systems
Networks
B
usiness &

T
echnology A
lignm
ent
IT
Systems
Web
Services
Process 1
Process 2
Data
Network
Applications
Voice
Network
Systems
Web
Services
Process 1
Process 2
Data
Network

Applications
Voice
Network
Video
Network
Process 3
Strategic
Initiative 2
Strategic
Initiative 1
Strategic
Initiative 1
Strategic
Initiative 2
Data
Dictionary
Object
Reuse
Data
Flows
Object
Reuse Data
Dictionary

Data
Flows
E
A
=
S
+
B
+
T
Home Architecture Analogy: Building a house one room at a
time
without the blueprints for the whole house can lead to a poor
result. It is
analogous to developing organizations, business units,
programs, and
systems without an enterprise-wide architecture for reference,
as duplication
and inefficiency in resources, and a lack of overall agility can
result.
With regard to resources, one of the greatest challenges that
many
enterprises continue to face is how to identify the business and
technology
components of strategic initiatives. A big part of this challenge

is that
technology, information technology (IT) in particular, has
historically not
been viewed as a strategic asset. As such, planning activities
often have
focused on the development of individual technology solutions
to meet
particular organizational requirements.
What is Enterprise Architecture?
The following equation is the ‘sound bite’ version of what EA is
all about,
and is intended to help readers remember the distinct difference
between
EA and other types of IT planning… that EA is driven by
strategic goals
and business requirements.
EEAA == SS ++ BB ++ TT
Enterprise Architecture = Strategy + Business + Technology
This is a straight-forward, simple representation of the unique
holistic
value of EA, as is the geometry of the “cube” framework that it
derives
from. I am a believer in the principle captured by Occam’s
Razor, which
in the philosopher Occam’s original 14th Century form states
that “entities
should not be multiplied unnecessarily”. It is my hope that the
equation
EA = S + B + T and the EA3 Cube Framework are easy to
understand and
highly useful in many contexts because they adhere to this
principle and
capture the essential elements that characterize human

organizations.
EA is primarily about designing virtual things - organizations
and their
capabilities, whereas traditional architecture is primarily about
designing
physical things. There are many parallels in these two
disciplines and
there are a number of intersecting areas such as creating work
environments that promote productivity and support agility. EA
is both a
noun and a verb. The architecture of an enterprise is a thing – a
collection
of models and information. Creating an enterprise-wide
architecture is
accomplished through a standardized process that is sustained
through an
ongoing management program. EA provides a strategy and
business-
driven approach to policy, planning, decision-making, and
resource
development that is useful to executives, line managers, and
support staff.
To be effective, an EA program must be part of a group of
management
practices that form an integrated governance structure, as is
shown in
Figure 1-2 on the next page.
Figure 1-2: Major Areas of Integrated Governance
Enterprise Architecture as a Meta-Discipline

An enterprise-wide architecture should serve as an authoritative
reference,
source of standards for processes / resources, and provider of
designs for
future operating states. An EA is therefore THE architecture of
the
enterprise and should cover all elements and aspects. Having a
single
source of reference is essential to avoiding waste and
duplication in large,
complex organizations. It also resolves the “battle of best
practices” and
competition between sub-architectural domains which can be
problematic
for organizations that are trying to become for efficient.
Developing an enterprise-wide architecture using the EA
methods
described in this book is a unique and valuable undertaking for
organizations, in that the EA is holistic and serves as an
umbrella or “meta-
context” for all other management and technology best
practices. The EA
also creates abstract views, analyses, and models of a current or
future
enterprise that helps people make better plans and decisions.
EA extends
beyond technology planning, by adding strategic planning as the
primary
driver of the enterprise, and business planning as the source of
most
program and resource requirements. There is still a place for
technology
Integrated
Governance

Strategic
Planning
Enterprise
Architecture
Capital
Investm ent
Planning
Workforce
Planning
Knowledge
Managem ent
Program
Managem ent
Risk
Managem ent
Operations
and Security
planning, which is to design systems, applications, networks,
call centers,
networks, and other capital resources (e.g. buildings, capital
equipment) to
meet the business requirements… which are the heart of the
enterprises

activities… creating and delivering those products and services
that
accomplish the strategic goals of the enterprise.
Regarding the “battle of the best practices”, organizations in the
public and
private sectors are often faced with decisions about which
practices to
adopt as they pursue quality, agility, efficiency; manage risk,
and adopt
new technologies. There are dozens of best practices out there,
and most
of them were created in isolation – relative to the other best
practices. I
call this the “battle of the best practices” and it creates an
expensive
dilemma for organizations – what to adopt? Because the
implementation
and maintenance methods for many of the best practices are
very resource
intensive, and the scope is not all-inclusive, the organization is
faced with
the challenge of deciding which to adopt, how to do it, and what
overlaps,
contradictions, and gaps are produced from the resulting
collection.
When EA is THE architecture of an organization in all
dimensions, it
becomes the over-arching, highest level discipline and the
authoritative
reference for standards and practices. This is a tremendous and
unique
contribution, because when EA is used in this way, the dilemma
disappears
and organizations can use the EA framework to make rational
decisions

about which best practices need to be adopted, what they will
cover, and
how they can relate to each other. Figure 1-3 illustrates how
EA serves as
an organizing context for the adoption and use of best practices.
Figure 1-3: Enterprise Architecture as a Meta Discipline
Strategic
Level
Business
Level
Technology
Level
The Enterprise Architecture
Balanced
Scorecard
SWOT
BPI / BPR
Business
Cases
Alternatives
AnalysisSOA
ITIL
CORBA
Object-Oriented

Design & Analysis
SDLC
Six Sigma
EA is the organizing
meta-context and
standards authority
for implementing
all management
and technology
best practices
Information Assurance
CPIC
Cloud Computing
Mobile
PMBOK
The Enterprise Architecture Approach
For an EA approach to be considered to be complete, the six
core elements
shown in Figure 1-4 must be present and work synergistically
together.

Figure 1-4: Core Elements of an Enterprise Architecture
Approach
Governance
The first core element is “Governance” which identifies the
planning,
decision-making, and oversight processes and groups that will
determine
how the EA is developed and maintained, accomplished as part
of an
organization’s overall governance.
Methodology
The second core element is “Methodology” which are specific
steps to
establish and maintain an EA program, via the selected
approach.
Framework
The third core element is “Framework” which identifies the
scope of the
overall architecture and the type and relationship of the various
sub-
architecture levels and threads. Not all frameworks allow for
sub-domains
or are able to integrate strategy, business, and technology
planning.
Artifacts
The fourth core element is “Artifacts” which identifies the types
and
methods of documentation to be used in each sub-architecture
area,
including strategic analyses, business plans, internal controls,
security

Framework ArtifactsBest Practices
Methodology
Governance
Methodology
Standards
Methodology
Standards
Governance
controls, and models of workflow, databases, systems, and
networks. This
core element also includes the online repository where artifacts
are stored.
Standards
The fifth core element is “Standards” which identify business
and
technology standards for the enterprise in each domain,
segment, and
component of the EA. This includes recognized international,
national,

local, and industry standards as well as enterprise-specific
standards.
Best Practices
The sixth core element is “Associated Best Practices” which are
proven
ways to implement parts of the overall architecture or sub-
architectures, in
context of the over-arching EA.
Enterprise Architecture Activities
Enterprise architecture is accomplished through a management
program
and an analysis and design method that is repeatable at various
levels of
scope. Together the EA program and method provide an
ongoing
capability and actionable, coordinated views of an enterprise’s
strategic
direction, business services, information flows, and resource
utilization.
As a management program, EA provides:
Strategic Alignment: Connects goals, activities, and resources
Standardized Policy: Resource governance and implementation
Decision Support: Financial control and configuration
management
Resource Oversight: Lifecycle approach to
development/management
As an analysis and design method, EA provides:
EA Approach: The framework, analysis/design method, and
artifact set
Current Views: Views of as-is strategies, processes, and
resources

Future Views: Views of to-be strategies, processes, and
resources
EA Management Plan: A plan to move from the current to the
future EA
EA as a Management Program
EA an ongoing management program that provides a strategic,
integrated
approach to capability and resource planning / decision-making.
An EA
program is part of an overall governance process that
determines resource
alignment, develops standardized policy, enhances decision
support, and
guides development activities. EA can help to identify gaps in
the
performance of line of business activities/programs and the
capabilities of
supporting IT services, systems, and networks.
Strategic Alignment
EA supports strategic planning and other operational resource
planning
processes by providing macro and micro views of how resources
are to be
leveraged in accomplishing the goals of the enterprise. This
helps to
maximize the efficiency and effectiveness of these resources,
which in turn
will help to promote the enterprise’s competitive capabilities.
Development projects within the enterprise should be reviewed

to
determine if they support (and conform to) one or more of the
enterprise’s
strategic goals. If a resource and/or project is not aligned, then
its value to
the enterprise will remain in question, as is shown in Figure 1-
5.
Figure 1-5: Strategic Alignment of Capabilities and Resources
Standardized Policy
EA supports the implementation of standardized management
policy
pertinent to the development and utilization of IT and other
resources. By
providing a holistic, hierarchical view of current and future
resources, EA
supports the establishment of policy for:
Identifying strategic and operational requirements
Enterprise Strategic Goals
Line of Business
#1 Goals
Enterprise-Wide Strategic Initiatives
Line of Business
#2 Goals
Line of Business
#3 Goals
Line of Business #1
Program Group

Line of Business #2
Program Group
Line of Business #3
Program Group
P
ro
je
ct
1
-1
P
ro
je
ct
1
-2
P
ro
je
ct
1
-3
P
ro

je
ct
2
-1
P
ro
je
ct
2
-2
P
ro
je
ct
2
-3
P
ro
je
ct
3
-1
P
ro

je
ct
3
-2
P
ro
je
ct
3
-3 C
ap
ab
ili
ty
A
lig
nm
en
t
Resource Alignment

Determining the strategic alignment of activities and resources
Developing enterprise-wide business and technology resources
Prioritizing the funding of programs and projects
Overseeing the management of programs and projects
Identifying performance metrics for programs and projects
Identifying and enforcing standards and configuration
management
Policy documents include those which can be categorized as
general
guidance (e.g., high-level directives and memos); specific
program
guidance (e.g., plans, and manuals); and detailed process
guidance (e.g.,
standard operating procedures). By using these hierarchical
categories of
documents, succinct and meaningful policy is established. It
does so in a
way that no single policy document is too long and therefore not
too
burdensome to read. It is also important to understand how the
various
areas of policy are inter-related so that program implementation
across the
enterprise is coordinated. EA policies must integrate with other
policies in
all governance areas, so as to create an effective overall
resource
management and oversight capability.
Decision Support
EA provides support for IT resource decision-making at the
executive,
management, and staff levels of the enterprise. At the executive
level, EA
provides visibility for large IT initiatives and supports the

determination of
strategic alignment. At the management level, EA supports
design and
configuration management decisions, as well as the alignment
of IT
initiatives with technical standards for voice, data, video, and
security. At
the staff level, EA supports decisions regarding operations,
maintenance,
and the development of IT resources and services.
Resource Oversight
EA supports standardized approaches for overseeing the
development of
capabilities and optimizing supporting resources. Depending on
the scope
of the resources involved and the available timeframe for
development,
various system development lifecycle methods can be used to
reduce the
risk that cost, schedule, or performance parameters may not be
met. EA
further supports standardized, proven approaches to project
management
that promote the comprehensive and effective oversight of
ongoing
programs and new development projects. Finally, EA supports
the use of a
standardized process for selecting and evaluating investment in
IT
resources from a business and financial perspective.

EA as an Analysis and Design Method
References to EA began to emerge in the late 1980’s in various
management and academic literatures, with an early focus on
technical or
systems architectures and schemas for organizing information.
The
concept of ‘enterprise’ architecture analysis and design emerged
in the
early 1990’s and has evolved to include views of strategic
goals, business
services, information flows, systems and applications, networks,
and the
supporting infrastructure. Additionally, there are ‘threads’ that
pervade
every level of the architecture: standards, security, and skills.
EA analysis and design are accomplished through the following
six basic
elements: (1) an EA documentation framework, and (2) an
implementation
methodology that support the creation of (3) current and (4)
future views
of the architecture, as well as the development of (5) an EA
Management
Plan to manage the enterprise’s transition from current to future
architectures. There are also several areas common to all levels
of the
framework that are referred to as (6) “threads” as shown in
Figure 1-6.
Figure 1-6: Basic Elements of EA Analysis and Design
EA Analysis and Design Element #1: The Framework.
The EA framework identifies the scope of the architecture to be
developed
and establishes relationships between the architecture’s areas.

The
framework’s scope is reflected through its geometric design and
the areas
that are identified for documentation. The framework creates
an abstracted
set of “views” of an enterprise through the way that it collects
and
organizes architecture information. An example that will be
used
throughout the book is the framework that is illustrated in
Figure 1-7,
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure

Networks &
Infrastructure
Systems &
Applications
Data &
Information
Products &
Services
Network
Initiatives
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure

Network
Infrastructure
Network
Infrastructure
Optimized Networks
and Infrastructure
Integrated Systems
and Applications
Enhanced Data and
Information Flows
Improved Business
Products and Services
Network
InfrastructureUpdated Strategic
Goals & Initiatives
CURRENT ARCHITECTURE FUTURE ARCHITECTURE
Lines of Business
Highest
Level & View
Lowest
Level & View
C
O

M
P
O
N
E
N
T
S
Architecture
Management
Plan
E
A
F
ra
m
ew
or
k
2
Lines of Business
C
O
M
P
O
N
E

N
T
S
S
ec
u
rit
y
/ S
ta
n
da
rd
s
/ S
ki
lls1
3 4
5
6
which has a cubic shape with three dimensions that relate to

different
aspects of modeling the abstracted enterprise.
Figure 1-7: EA³ Cube Analysis & Design Framework
Known as the EA³ Cube Framework™ the levels of this example
framework are hierarchical so that the different sub-
architectures (that
describe distinct functional areas) can be logically related to
each other.
This is done by positioning high-level strategic goals/initiatives
at the top,
business products/services and data/information flows in the
middle, and
supporting systems/applications and technology/infrastructure
at the
bottom. In this way alignment can be also be shown between
strategy,
information, and technology, which aids planning and decision-
making.
Chapters 4 through 6 provide more details on EA frameworks,
components, and methods.
To lower risk and promote efficient, phased implementation
methods, the
EA framework is divided into segments of distinct activity,
referred to as
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure

Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Networks &
Infrastructure
Systems &
Applications
Data &
Information
Products &
Services
Network
Initiatives
Lines of Business

C
O
M
P
O
N
E
N
T
S
S
ec
ur
it
y
/ S
ta
nd
ar
ds
/
S
ki
lls
Te
ch
n

o
lo
g
y
–
B
u
si
n
es
s
–
S
tr
at
eg
y
Framework Dimension 3: Artifacts
The documentation of components at each
level of the architecture, including all threads
F
ra
m
ew

o
rk
D
im
en
si
o
n
1:
L
ev
el
s
S
ub
-a
rc
hi
te
ct
ur
es
; d
is

tin
ct
f
un
ct
io
na
l
ar
ea
s
an
d
th
ei
r
re
la
tio
ns
hi
p
s

Lines of Business (LOBs). For example, each LOB has a
complete sub-
architecture that includes all five hierarchical levels of the EA³
framework.
The LOB therefore can in some ways stand alone architecturally
within the
enterprise except that duplication in data, application, and
network
functions would occur if each LOB were truly independent. An
architecture encompassing all five framework levels that is
focused on one
or more LOBs can be referred to as a segment of the overall EA.
EA Analysis and Design Element #2: EA Components
EA components are changeable goals, processes, standards, and
resources
that may extend enterprise-wide or be contained within a
specific line of
business or segment. Examples of components include strategic
goals and
initiatives; business products and services; information flows,
knowledge
warehouses, and data objects; information systems, software
applications,
enterprise resource programs, and web sites; voice, data, and
video
networks; and supporting infrastructure including buildings,
server rooms,
wiring runs/closets, and capital equipment. Figure 1-8 on the
next page
provides examples of vertical and crosscutting EA components
at each
level of the EA³ Cube framework, and Chapter 6 provides

additional
details.
Key Term: Architecture Segment
A part of the overall EA that documents one or more lines of
business at all
levels and threads. A segment can exist as a stand-alone part of
the EA.
Key Term: Line of Business
A Line of Business (LOB) is a distinct area of activity within
the enterprise.
It may involve the manufacture of certain products, the
provision of
services, or internal administrative functions.
Key Term: Vertical Component
A vertical component is a changeable goal, process, program, or
resource
(equipment, systems, data, etc.) that serves one line of business.
Key Term: Horizontal (Crosscutting) Component
A horizontal (or crosscutting) component is a changeable goal,
process,
program, or resource that serves several lines of business.
Examples include
email and administrative support systems that serve the whole
enterprise.
Figure 1-8: Examples of EA Components
EA Analysis and Design Element #3: Current Architecture

The current architecture contains those EA components that
currently exist
within the enterprise at each level of the framework. This is
sometimes
referred to as the “as-is” view. The current view of the EA
serves to create
a ‘baseline’ inventory of current resources and activities that is
documented in a consistent way with the future view of the EA
so that
analysts can see gaps in performance between future plans and
the current
capabilities. Having an accurate and comprehensive current
view of EA
components is an important reference for project planning, asset
management, and investment decision-making. The current
view of the
EA is composed of ‘artifacts’ (documents, diagrams, data,
spreadsheets,
charts, etc.) at each level of the framework, which are archived
in an on-
line EA repository to make them useable by various EA
stakeholders.
EA Analysis and Design Element #4: Future Architecture
The future architecture documents those new or modified EA
components
that are needed by the enterprise to close an existing
performance gap or
support a new strategic initiative, operational requirement, or
technology
solution.
Network
Infrastructure
Network

Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Network
Infrastructure
Technology &
Infrastructure
Systems &
Applications
Data &
Information
Products &
Services
Network

Initiatives
Examples
of EA
Components
• Information Systems
• Web Sites
• Desktop Applications
• Intranets & Extranets
• Telecommunications
• Buildings & Equipment
• Knowledge Warehouse
• Databases & Data Marts
• Data Interchange
• Manufacturing
• Financial Services
• Marketing & Sales
• Mission Statement
• Strategic Goals
• Strategic Initiatives
Vertical
Components
Crosscutting
Components
Network
Infrastructure
Network

Initiatives
Examples
of EA
Components
• Information Systems
• Web Sites
• Desktop Applications
• Intranets & Extranets
• Telecommunications
• Buildings & Equipment
• Knowledge Warehouse
• Databases & Data Marts
• Data Interchange
• Manufacturing
• Financial Services
• Marketing & Sales
• Mission Statement
• Strategic Goals
• Strategic Initiatives
Vertical
Components
Crosscutting
Components

As is shown in Figure 1-9, the future architecture is driven at
both the
strategic and tactical levels in three ways: new directions and
goals;
changing business priorities; and emerging technologies. The
EA cannot
reflect these changes in the future architecture unless the
enterprise’s
leadership team provides the changes in strategic direction and
goals;
unless the line of business managers and program managers
provide the
changes in business processes and priorities that are needed to
accomplish
the new goals; and unless the support/delivery staff identifies
viable
technology and staffing solutions to meet the new business
requirements.
Figure 1-9: Drivers of Architectural Change
The future architecture should cover planned changes to EA
components in
the near term (tactical changes in the next 1-2 years), as well as
changes to
EA components that are a result of the implementation of long-
term
operating scenarios that look 3-10 years into the future. These
scenarios
incorporate different internal and external drivers and can help
to identify
needed changes in processes, resources, or technology that
translate to
future planning assumptions, which in turn drive the planning
for new EA
components. An example future scenario and additional details

on the
future architecture are provided in Chapter 8.
EA Analysis and Design Element #5: EA Management Plan
The EA Management Plan articulates the EA program and
documentation
approach. The EA Management Plan also provides descriptions
of current
and future views of the architecture, and a sequencing plan for
managing
the transition to the future business/technology operating
environment.
The EA Management Plan is a living document that is essential
to realizing
the benefits of the EA as a management program. How the
enterprise is
going to continually move from the current architecture to the
future
architecture is a significant planning and management
challenge,
especially if IT resources supporting key business functions are
being
Capabilities
of the
Current
Enterprise
Capabilities
of the
Future
Enterprise
Emerging Technologies

(Support Team)
New Business Priorities
(Management Team)
New Direction & Goals
(Leadership Team)
S
trategic
T
actical
Operating
Scenarios
Program
Plans
Capabilities
of the
Current
Enterprise
Capabilities
of the
Future
Enterprise
Emerging Technologies
(Support Team)
New Business Priorities

(Management Team)
New Direction & Goals
(Leadership Team)
S
trategic
T
actical
Operating
Scenarios
Program
Plans
replaced or upgraded. Chapter 9 provides additional details on
the
development of an EA Management Plan.
EA Analysis and Design Element #6: Threads
EA documentation includes ‘threads’ of common activity that
are present
in all levels of the framework. These threads include IT-related
security,
standards, and skill considerations.
Security. Security is most effective when it is an integral part
of the EA
management program and documentation methodology. A
comprehensive IT Security Program has several focal areas

including:
information, personnel, operations, and facilities. To be
effective, IT
security must work across all levels of the EA framework and
within all
of the EA components. Chapter 11 provides more information
on
security.
Standards. One of the most important functions of the EA is
that it
provides technology-related standards at all levels of the EA
framework. The EA should draw on accepted international,
national,
and industry standards in order to promote the use of non-
proprietary
solutions in EA components. This in turn enhances the
integration of
EA components, as well as better supporting the switch-out of
components when needed.
Skills. Perhaps the greatest resource that an enterprise has is
people. It
is therefore important to ensure that staffing, skill, and training
requirements are identified for LOB and support service
activities at
each level of the EA framework, and appropriate solutions are
reflected
in the current and future architectures.
Reference Architecture / Segment Architecture
A reference architecture is the part of an EA that provides
standards and
documentation for a particular type of capability throughout the
enterprise
– such as mobile services or cloud computing. A segment

architecture is
somewhat similar, but usually focuses one or more particular
business
units or functions – such as the finance and accounting group,
or how a
financial ERP system and all of its modules are going to be
implemented
(general ledger, accounts payable, accounts receivable, payroll,
benefits,
etc.).
Fitting the Architecture Elements Together
While the basic elements of EA analysis and design provide
holistic and
detailed descriptions of the current and future architecture in all
areas of
the underlying framework, it is important to also be able to
articulate these
relationships in discussions and presentations with executives,
managers,
support staff, and other EA stakeholders. Being able to
understand and
relate how the architecture fits together is essential to being
able to use the
EA in planning and decision-making throughout the enterprise.
This
communication is supported through two EA program resources:
the EA
Management Plan and the EA Repository. As was mentioned in
the
previous section, the EA Management Plan is a living document
that is

periodically updated so that it remains relevant as the ongoing
primary
reference for describing where the current and future
architectures are at.
The EA Repository is the on-line archive for EA information
and the
documentation artifacts that are described in the EA
Management Plan.
The EA Repository is described in the next section of this
chapter.
The following is an example of how to communicate about EA
with
stakeholders. In this example, some questions are presented
about how to
apply an EA framework to an enterprise, which subsequent
chapters of the
book answer. These are the types of questions that should be
answered in
the first few sessions of EA program and documentation
meetings in order
to promote an understanding of how the EA framework and
documentation
can reflect the enterprise. In the following example of how to
talk about
EA, the five levels and three vertical threads of the EA3 Cube
framework
are used for illustration. Notice how the questions build in a
way that
reflects the hierarchical relationships between the levels of the
EA3
Framework.
Each area of the EA3 Framework represents a functional area of
the
enterprise. The EA3 Framework can be used in a top-down,

bottom-
up, or single-component manner. To begin to use the
framework in
a top down-manner, a series of questions at each level should be
asked in order to determine how information about the
enterprise
will fit within that level of the framework.
The first questions to ask relate to the strategic ’Goals and
Initiatives’ level of the framework. The questions are: (1) for
what
purpose does the enterprise generally exist (usually expressed in
the
mission statement) and (2) what kind of organization does the
enterprise generally intend to be (often given in the vision
statement)? What are the primary goals (strategic goals) of the
enterprise? What then are the strategic initiatives (ongoing
programs or new projects) that will enable the enterprise to
achieve
those goals? Finally, for this level, when will the enterprise
know
that it has successfully reached these strategic goals or is
making
progress toward these goals (outcome measures)?
Second is the business ‘Products and Services’ level of the
framework, and it is important to first ask what are the ongoing
activity areas (lines of business) that the enterprise must engage
in
to support and enable the accomplishment of both strategic
initiatives and normal ‘maintenance/housekeeping’ functions?

What then are the specific activities in each line of business
(business services)? What are the products that are delivered in
each line of business? How do we measure the effectiveness and
efficiency of the line of business processes (input/output
measures)
as well as their contribution to strategic goals (outcome
measures)?
Do any of these business services or manufacturing processes
need
to be reengineered/improved before they are made to be part of
the
future architecture? What are the workforce, standards, and
security issues at this framework level?
Third is the ‘Data and Information’ level of the framework.
When
the lines of business and specific business service/products have
been identified, it is important to ask what are the flows of
information that will be required within and between activity
areas
in order to make them successful? How can these flows of
information be harmonized, standardized, and protected to
promote
sharing that is efficient, accurate, and secure? How will the
data
underlying the information flows be formatted, generated,
shared,
and stored? How will the data become useable information and
knowledge?
Fourth is the ‘Systems and Applications’ level of the framework
and
it is important to ask which IT and other business systems and
applications will be needed to generate, share, and store the
data,
information, and knowledge that the business services need?

How
can multiple types of IT systems, services, applications,
databases,
and web sites be made to work together where needed? How
can
configuration management help to create a cost-effective and
operationally efficient ‘Common Operating Environment’ for
systems and applications? What are the workforce, standards,
and
security issues at this level?
Fifth is the ‘Network and Infrastructure’ level of the framework
and
it is important to ask what types of voice, data, and video
networks
or computing clouds will be required to host the IT
systems/applications and to transport associate, data, images,
and
conversations, as well as what type of infrastructure is needed
to
support the networks (e.g. buildings, server rooms, other
equipment). How can these networks be integrated to create a
cost-
effective and operationally efficient hosting and transport
environment? Will these networks and clouds extend beyond
the
enterprise? What are the workforce, standards, and security
issues
at this level? What are the physical space and utility support
requirements for these infrastructure resources?
The EA Repository

Providing easy access to EA documentation is essential for use
in planning
and decision-making. This can be accomplished through the
establishment
of an on-line EA repository to archive the documentation of EA
components in the various areas of the EA framework. The EA
repository
is essentially a website and database that stores information and
provides
links to EA tools and other EA program resources. Figure 1-10
provides
an example of how an EA repository might be designed. This
example is
called Living Enterprise™ and it is designed to support
documentation that
is organized through the use of the EA³ Cube Framework.
Chapter 12
provides additional details on the design and function of an EA
repository.
Figure 1-10: Example EA Repository Design – Living
Enterprise TM
Detailed
View
Mid
Level
View
High
Level
View
Current EA
Views

Enterprise Architecture Repository
Perf ormance
Measures
Strategic
Plan
Goals &
Initiatives
Investment
Portf olio
Business
Plan
Business
Processes
Data
Dictionary
Knowledge
Warehouse
Inf ormation
Flows
Application
Inventory
Business
Systems

Support
Systems
Buildings
& Equipment
Wide Area
Network
Local Area
Network
Data
Privacy
Security
Program
System
Certif ications
Goals
& Initiatives
Products
& Services
Data &
Information
Systems &
Applications
Networks &
Infrastructure

Security
Solution
s
Site MapEA TutorialEA Program Future EA Views EA
StandardsEA Management Plan
Summary of Concepts
A program or systems-level perspective is not sufficient for the
management and planning of technology and other resources
across
enterprises with significant size and complexity. EA is the one
discipline
that looks at systems holistically as well as provides a strategy
and
business context. EA was described as being as both a
management
process and an analysis and design method that helps

enterprises with
business and technology planning, resource management, and
decision-
making. The purposes of an EA management program were
described:
strategic alignment, standardized policy, decision support, and
resource
development. The six basic elements of an EA analysis and
design method
were presented: the EA documentation framework, EA
components,
current EA views, future EA views, an EA Management Plan
and multi-
level threads that include security, standards, and workforce
planning. An
example of how to communicate the various areas of an EA
framework
was also provided. The following chapters of Section I will
describe why
EA is valuable to many types of enterprises, what the risks of
doing EA
are, and how to ensure that an architecture is driven by strategic
goals and
business requirements.

Chapter 1 Questions and Exercises
1. What are some of the differences between enterprise
architecture (EA)
and a systems-level planning approach?
2. Why is EA described as both a management program and an
analysis
and design method?
3. What are the four elements of an EA management program
and the six
elements of an EA analysis and design method?
4. What are some of the EA components and documentation
artifacts that
would be included in current and future views at each level of
the EA³
Cube framework?
5. Can EA be used by all types of enterprises? If so, why?
6. How does an EA repository support the implementation
methodology?
7. Choose a real-world large-sized enterprise and determine:

a. Is information technology seen as a strategic asset?
b. Does an enterprise architecture program exist?
c. Are there gaps in business/technology performance that an
enterprise architecture program could help identify and correct?
Chapter 2
The Structure and Culture of Enterprises
Chapter Overview
Chapter 2 discusses the need for enterprise architects to
understand the role
of organizational structure and culture in developing an EA.
Structure and
culture are important to include in the EA in order to accurately
reflect the
true nature of organizational goals, processes, and informal
structures

which influence the current and future views of the architecture.
Understanding structure and culture are also important in
working with
stakeholders to gain their support and manage expectations for
the
development and implementation of the EA program.
Enterprises are
types of social organizations and as such, the concepts of
organizational
theory presented in this chapter are applicable to the practice of
EA.
Learning Objectives
Understand the structural and cultural aspects of an enterprise
Understand the differences between an organization and an
enterprise
Become familiar with models of organizations and enterprises
Be able to tie structural and cultural aspects of the enterprise to
the architecture
Key Term: Culture
The beliefs, customs, values, structure, normative rules, and

material traits
of a social organization. Culture is evident in many aspects of
how an
organization functions.
Key Term: Stakeholder
Everyone who is or will be affected by a policy, program,
project, activity,
or resource. Stakeholders for the EA program include executive
sponsors,
architects, program managers, users, and support staff.
Introduction
Enterprise architecture is as much about people and social
interaction as it
is about processes and resource utilization. Understanding each
of these
aspects of an enterprise is essential to the development of
accurate views
of the current architecture and relevant, meaningful views of the
future

architecture.
Insight into the “people aspect” of enterprises is also important
to the
development of policy, standards, and an EA Management Plan
that will
be accepted by the enterprise. Moving from current to future
states of the
EA involves changes in processes and how people will
communicate.
Change involves moving from what is familiar to something
unfamiliar,
which is uncomfortable and/or threatening to many people.
Therefore,
there may be resistance to programs such as EA that cause or
support
changes in resources and processes throughout the enterprise.
Discussion
Influences on the Field of Enterprise Architecture
Developing an enterprise-wide architecture involves an
evaluation and
depiction of people, processes, and resources. Some of the
areas of
practice and theory that have influenced the EA practices

include business
administration, public administration, operations research,
sociology,
organizational theory, management theory, information science,
and
computer science. Understanding the mission, goals, and
culture of an
enterprise is as important to implementing an EA as the
selection of
analytic methods and documentation techniques. The EA
approach
described in this book is based on theories of how social
organizations are
structured and how systems and activities function within
enterprises.
Figure 2-1 on the next page shows the academic fields and areas
of
theory/practice that influence EA.
Home Architecture Analogy: An architect needs to understand
the
composition, preferences, and activities of the occupants to be
able to
produce an effective design for their new or remodeled home.
How they

will use the rooms, their activity patterns, and storage needs are
examples of
the factors to be considered.
Figure 2-1: Influences on the Field of Enterprise Architecture
The Structure of Enterprises
In this part of Chapter 2 there will be some references to
organizations
instead of enterprises because the concepts come from
established
organizational theory. The concepts of organizational theory
also apply to
enterprises because they are types of social organizations.
Organizations
and enterprises are essentially complex social systems, which
regardless of
mission, share many similarities in their basic structure and
functions.
The Leavitt Diamond Model

One of the early models of general
organizational structure is the
“Levitt Diamond” presented in
1965 and shown in Figure 2-2.5
Leavitt argued that a change in any
of these four components will have
an effect on the others and that the
interaction of the components
underlies organizational success.
Figure 2-2: Leavitt
Diamond
5 Leavitt, H.J. 1965. Applied Organizational Change in
Industry: Structural, Technological and
Humanistic Approaches in: Handbook of Organizations, edited
by J.G. March. Chicago, Rand McNally
Organizational
Theory
Systems
Theory
Enterprise
Architecture

Contributing ConceptsContributing Concepts
••BeliefsBeliefs
••Values & EthicsValues & Ethics
••LeadershipLeadership
••CultureCulture
••Language & MeaningLanguage & Meaning
••CompetitionCompetition
••BureaucracyBureaucracy
••ProcessProcess
••TechnologyTechnology
••Management Management
••QualityQuality
••EnvironmentEnvironment
••ReengineeringReengineering
••RiskRisk
Contributing FieldsContributing Fields
PsychologyPsychology
SociologySociology
Political SciencePolitical Science
Public AdministrationPublic Administration

EngineeringEngineering
Computer ScienceComputer Science
Business AdministrationBusiness Administration
Operations ResearchOperations Research
Emerging FieldsEmerging Fields
Information Resources MgmtInformation Resources Mgmt
Information SecurityInformation Security
Enterprise ArchitectureEnterprise Architecture
Records & Data MgmtRecords & Data Mgmt
Emerging ConceptsEmerging Concepts
Systems Lifecycle DevelopmentSystems Lifecycle Development
Information AssuranceInformation Assurance
IT Program MgmtIT Program Mgmt
Knowledge MgmtKnowledge Mgmt
IT Capital PlanningIT Capital Planning
EE--Government & CommerceGovernment & Commerce
Digital DivideDigital Divide

Organizational
Theory
Systems
Theory
Enterprise
Architecture
••BeliefsBeliefs
••Values & EthicsValues & Ethics
••LeadershipLeadership
••CultureCulture
••Language & MeaningLanguage & Meaning
••CompetitionCompetition
••BureaucracyBureaucracy
••ProcessProcess
••TechnologyTechnology
••Management Management
••QualityQuality
••EnvironmentEnvironment
••ReengineeringReengineering

••RiskRisk
PsychologyPsychology
SociologySociology
Political SciencePolitical Science
Public AdministrationPublic Administration
EngineeringEngineering
Computer ScienceComputer Science
Business AdministrationBusiness Administration
Operations ResearchOperations Research
Emerging FieldsEmerging Fields
Information Resources MgmtInformation Resources Mgmt
Information SecurityInformation Security
Enterprise ArchitectureEnterprise Architecture
Records & Data MgmtRecords & Data Mgmt
Emerging ConceptsEmerging Concepts
Systems Lifecycle DevelopmentSystems Lifecycle Development
Information AssuranceInformation Assurance

IT Program MgmtIT Program Mgmt
Knowledge MgmtKnowledge Mgmt
IT Capital PlanningIT Capital Planning
EE--Government & CommerceGovernment & Commerce
Digital DivideDigital Divide
The Parsons/Thompson Model
Another model of general organizational structure is a three-
level view that
was originally envisioned by sociologist Talcott Parsons in the
1950’s and
further developed by sociologist James Thompson in the
1960’s.6 Parsons’
research identified three general levels that are common to most
social
organizations (technical, managerial, and institutional), based
on the
observation that different types of activities occur at each
level.7

Thompson built on Parsons’ ideas by further identifying the
different types
of activities that occur at each level.8 Figure 2-3 summarizes
the
Parsons/Thompson Model of social organizations.
Organizational
Level
Structure
Parson’s
Purpose of each Level
Function
Thompson’s
Activities of the Level
Institutional
Where the organization
establishes rules and relates
to the larger society as it
derives legitimization,

meaning, and higher-level
support, thus making possible
the implementation of
organizational goals.
The organization is very open
to the environment in order
to determine its domain,
establish boundaries, and
secure legitimacy.
Managerial
Where mediation between the
organization and the
immediate task environment
occurs, where the
organization’s internal affairs
are administered, and where
the organization’s products
are consumed and resources
supplied.
A dynamic of mediation
occurs where less formalized

and more political activities
occur.
Technical Where the actual “product” of
an organization is processed.
The organization is “rational”
as it carries on production
(input/output) functions and
tries to seal off those
functions from the outside to
protect them from external
uncertainties as much as
possible.
Figure 2-3: Parson/Thompson Model of Enterprises
6 Bernard, S. A. Evaluating Clinger-Cohen Compliance in
Federal Agency Chief Information Officer
Positions. Doctoral Dissertation, Virginia Polytechnic Institute
& State University, April 2001.
7 Thompson, James D. Enterprises in Action. New York:
McGraw-Hill. 1967.
8 Ibid.

The geometry of the Parson/Thompson Model has been adapted
by the
author to resemble a series of concentric circles. This may
provide a more
useful image for depicting a social organization that interacts
with its
environment via the model’s Institutional Level, facilitates
internal
resources via the Managerial Level, and protects a “core” of
essential
processes and resources at the Technical Level. Figure 2-4
shows this
spherical version of the Parsons/Thompson Model, which also is
more
useful in relating it to how an EA framework can document
organizational
functions.
Figure 2-4: Relating Models of Organizational Function and
Structure

The value of the Parsons/Thompson Model is its use as an
authoritative
reference for developing EA views of structure and process for
an
organization. Regardless of the model’s wide acceptance in
academia, the
question of whether this fifty year old view would be relevant
and useful to
understanding the structure of current public and private sector
organizations is answered by observing that many large and
medium sized
corporations and government agencies continue to be
hierarchical, rule-
based, and goal-oriented. These were some of the primary
characteristics
of the “rational” organization that Parsons and Thompson
originally
studied. Evidence of this still being a valid model is also seen
in the
rational nature of organizational charts, mission statements,
strategic plans,
operational plans, and business services of these types of
organizations.
NetworkNetwork

InfrastructureInfrastructure
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
Networks Networks &&

Systems Systems &&
ApplicationsApplications
Data Data &&
InformationInformation
Products Products &&
ServicesServices
NetworkNetwork
InfrastructureInfrastructureNetworkNetwork
InfrastructureInfrastructureGoals Goals &&
InitiativesInitiatives
Lines of BusinessLines of Business
CC
OO
MM
PP
OO
NN
EE

NN
TT
SS
S
ec
ur
it
y
/ S
ta
nd
ar
ds
/
W
or
kf

or
ce
S
ec
ur
it
y
/ S
ta
nd
ar
ds
/
W
or
kf
or

ce
T
ec
hn
o
lo
gy
T
ec
hn
o
lo
gy
––
B
us

in
es
s
B
us
in
es
s
––
S
tr
at
eg
y
S
tr

at
eg
y
Technical
Level
Managerial Level
Institutional Level
Parsons/Thompson Model
of Generic Organizational Structure
EA3 Cube Architecture
Documentation Framework
NetworkNetwork
NetworkNetwork
NetworkNetwork

NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
Networks Networks &&
Systems Systems &&
ApplicationsApplications
Data Data &&

Products Products &&
ServicesServices
NetworkNetwork
InfrastructureInfrastructureGoals Goals &&
Lines of BusinessLines of Business
CC
OO
MM
PP
OO
NN
EE
NN
TT
SS
S
ec

ur
it
y
/ S
ta
nd
ar
ds
/
W
or
kf
or
ce
S
ec

ur
it
y
/ S
ta
nd
ar
ds
/
W
or
kf
or
ce
T
ec
hn

o
lo
gy
T
ec
hn
o
lo
gy
––
B
us
in
es
s
B

us
in
es
s
––
S
tr
at
eg
y
S
tr
at
eg
y
NetworkNetwork

at
eg
y
Technical
Level
Managerial Level
Institutional Level
Technical
Level
Managerial Level
Institutional Level
Parsons/Thompson Model
of Generic Organizational Structure
EA3 Cube Architecture
Documentation Framework

However, there are new types of organizations that have
emerged due to
technology-based changes in how people communicate and
work. Global
telecommunications and the Internet have made location a
largely
irrelevant factor in terms of where some types of work are being
done
(e.g., knowledge work and on-line services). Two primary
changes related
to organizational structure and function have resulted. First,
more
organizations are becoming regional or global in nature, and are
relying on
remote sub-groups to do significant amounts of the work.
Second, more
people are becoming self-employed knowledge workers who
contract their
services remotely to various enterprises depending on their
interest, skills,
and availability. Examples include people who process

digitized health
care forms, software developers, web site developers, distance
learning
instructors, financial traders, insurance salespeople, and
telemarketers.
Because these organizations can get certain functions
accomplished
remotely, their structure may become less hierarchical and more
collaborative.
While it can be argued that these new networked organizations
exhibit
many of the structural and functional characteristics found in
the
Parsons/Thompson Model, there are enough differences to merit
discussion of a variation of that model which may better
describe how
organizations operate in a more global on-line business
environment.
The Organizational Network Model
New types of organizations and enterprises are appearing which
are based
on cooperative networks of local and remote individual workers
and semi-

autonomous teams who carry out key functions. In these
enterprises,
greater cost efficiency and more mission flexibility are achieved
by
removing layers of management that are not needed in a
decentralized
operating mode. These teams are actually sub-groups that have
their own
management level and technical level with core processes, and
therefore
will still exhibit some of the characteristics of the
Parsons/Thompson
Model. The difference presented here is that the
organization/enterprise’s
structure is based on these teams and remote workers, whose
goals and
functions may change depending on internal and external
influences.
Called the Organizational Network Model (ONM), an Executive
Team sets
policy and goals, approves resources, and evaluates results,
while semi-
autonomous Functional Teams and Independent Workers
manage ongoing

programs/lines of business, new development projects, and
team-specific
resources. The Functional Teams and Independent Workers
receive
policy, goals, and general direction from the Executive Team,
yet carry out
organizational functions in an independent and/or cooperative
manner,
depending on the goal(s). Figure 2-5 provides an illustration of
the ONM.
Figure 2-5: Organizational Network Model
Being less hierarchical, these “flatter” and more flexible ONM
organizations can respond to changing requirements more
quickly by
creating, modifying, or eliminating Functional Teams and/or
adjusting the
number and type of Independent Workers. These types of ONM
organizations and enterprises can also exist as extended supply

chains or
networks of teams from inside and outside the traditional
organizational
boundary. This includes trusted business partners and
independent
consultants who are allowed to share sensitive information and
key
resources with the enterprise as part of the activities of the
Functional
Teams and Independent Workers.
Figure 2-6 on the next page shows how Functional Teams in
ONM
organizations can be related to an enterprise’s Lines of Business
(LOBs) in
the EA3 Cube Framework.
Figure 2-6: Relating Functional Teams to EA Lines of Business
Organizations and Enterprises
Organizations and enterprises are similar in that they are both

types of
social entities that have a culture, a formal and informal
structure, goals,
activities, and resources. The difference is that an enterprise
can be
defined as a subset of an organization or can involve multiple
organizations.
Why isn’t this book called An Introduction to Organizational
Architecture? Because that would largely limit the subject to
architectures
that encompass an entire organization, and while those
architectures are
important, a more versatile concept is an enterprise, which can
cover part
of the organization, all of the organization, or multiple
organizations.
Enterprises are normally made up of vertical, horizontal, and
extended
components. Vertical components (also known as lines of
business or
segments) are activity areas that are particular to one line of
business (e.g.,
research and development). Horizontal components (also known

as
crosscutting enterprises) are more general areas of activity that
serve
multiple lines of business. Extended components comprise
more than one
organization (e.g., extranets and supply chains).
EA views of vertical components are complete stand-alone
architectures in
that they contain documentation from all levels of the EA
framework.
These types of vertical components are also known as
“segments.” When
vertical segments are documented using the same EA
framework, they can
NetworkNetwork
NetworkNetwork
NetworkNetwork

NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
TechnologyTechnology
Systems &Systems &
ServicesServices
FlowsFlows
BusinessBusiness

ProcessesProcesses
NetworkNetwork
InfrastructureInfrastructureStrategicStrategic
LOB LOB --33
S
ec
u
ri
ty
, S
ta
n
d
ar

d
s,
W
o
rk
fo
rc
e
S
ec
u
ri
ty
, S
ta
n
d

ar
d
s,
W
o
rk
fo
rc
e
LOB LOB --22
LOB LOB --11
Lines of Business (LOB)
NetworkNetwork
NetworkNetwork

NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
Systems &Systems &
ServicesServices

FlowsFlows
BusinessBusiness
ProcessesProcesses
NetworkNetwork
LOB LOB --33
S
ec
u
ri
ty
, S
ta
n

d
ar
d
s,
W
o
rk
fo
rc
e
S
ec
u
ri
ty
, S
ta

n
d
ar
d
s,
W
o
rk
fo
rc
e
LOB LOB --22
LOB LOB --11
NetworkNetwork
NetworkNetwork

NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
NetworkNetwork
Systems &Systems &
ServicesServices

FlowsFlows
BusinessBusiness
ProcessesProcesses
NetworkNetwork
LOB LOB --33
S
ec
u
ri
ty
, S
ta
n

d
ar
d
s,
W
o
rk
fo
rc
e
S
ec
u
ri
ty
, S

ta
n
d
ar
d
s,
W
o
rk
fo
rc
e
LOB LOB --22
LOB LOB --11
Lines of Business (LOB)

be aggregated into a larger architecture picture that may cover
several or
all lines of business. This may be a preferable way to develop
the first
version of an enterprise’s EA as it allows them to undertake a
more
manageable amount of work at less initial cost (compared to
attempting to
do the EA for the entire enterprise all at once, without prior
experience).
This is called a “segmented approach” to documenting the
overall EA.
The segmented approach is also useful in large and/or
decentralized
enterprises where parts of the architecture may need to be
developed and
maintained by a number of different groups.
Understanding Culture
Understanding the culture of an enterprise is essential to
developing
realistic views of how strategic goals are established, how
processes

function, and how resources are used. Every enterprise is
different in some
way, as are the vertical, horizontal, and/or extended sub-
enterprises. This
is due to the culture of the enterprise being an amalgamation of
the values,
beliefs, habits, and preferences of all of the people throughout
the
enterprise or sub-enterprise.
Managing Change
Changes within the enterprise will happen regardless of the
presence of an
EA program, however they will happen in a more disjointed or
completely
independent manner without EA. The effect of the EA program
is to
coordinate change such that it is much more driven by new
strategies and
business requirements, and less by new technologies.
According to John Kotter, “To date, major change efforts have
helped
some organizations adapt significantly to shifting conditions,
have

improved the competitive standing of others, and have
positioned a few for
a far better future. But in too many situations the improvements
have been
disappointing and then carnage has been appalling, with wasted
resources
and burned-out, scared, or frustrated employees.” 9
People can be resistant to changes in their environment, whether
it is at
home or the workplace. If the EA program promotes changes in
the
enterprise, and if people are often resistant to any type of
change when
they do not have some level of control, then the EA program
may be
resisted by stakeholders unless something is done to increase
their level of
9 Kotter, J.P. 1996. Leading Change. Harvard Business School
Press. Boston, MA.

control. Increasing their level of control helps to successfully
manage
change, and can be accomplished in several ways, including:
Involving stakeholders in the EA program’s establishment and
management.
Regularly and effectively communicating EA activities to
stakeholders.
Allowing for stakeholder input to EA planning and decision-
making.
Managing stakeholder expectations as to what the EA program
can do.
Those who are affected by the EA program are called “EA
stakeholders”
and they are the ones most likely to resist the program and/or
changes that
are perceived to be the product of the EA program. Therefore,
one of the
things that the EA program manager needs to ensure is that
there is
stakeholder involvement in as many aspects of the EA program
as is
possible. This includes governance and oversight activities, the

selection
of an EA framework and methodology, participation in and
reviews of
documentation activities, and participation in the development
of and
updates to the EA Management Plan.
Another aspect of managing change within the EA program is
regular and
effective communication on program activities with all
stakeholders. This
includes formal documents such as an EA Program
Communication Plan,
the EA Management Plan, and notices regarding the periodic
update of the
current and future EA views. It also includes informal
communication on
an ongoing basis with all stakeholders to ensure that their
participation and
support is maintained.
The details of EA program governance are discussed in Chapter
4, but it is
sufficient to say that it is important to provide “a place at the
table” for as

many stakeholders as can be accommodated. This increases
buy-in for EA
policy and decision-making, as well as the success of
implementing
changes called for in the future architecture.
Expectation management is yet another way to promote the
success of the
EA program and help stakeholders deal with change.
Expectation
Key Term: Change Management
The process of setting expectations and involving stakeholders
in how a
process or activity will be changed, so that the stakeholders
have some
control over the change and therefore may be more accepting of
the change.
management is about identifying realistic outputs and outcomes.
It can be

accomplished by collaboratively assessing the capability of the
EA
program to document current and future architectures, the
timeframe and
resources that will take, and the obstacles to acceptance by
stakeholders.
Expectation management is an ongoing aspect of the EA
program.
Summary of Concepts
This chapter described how enterprises are types of social
organizations
and discussed the importance of understanding the structure and
culture of
the enterprise that an EA is documenting. While it is also
important to
understand the enterprise’s processes and supporting
technologies, it is the
people of the enterprise who make plans and decisions about
strategic
direction, business activities, and resource utilization. The
chapter also
covered influences on the field of EA and presented two models
of
organizations and enterprises that can assist in the development

of current
and future EA views. Finally, the importance of managing
change was
discussed in that EA program activities may be resisted by
stakeholders
who feel a loss of input or control.
Chapter 2 Questions and Exercises
1. Why is it important to understand the “people side” of EA?
2. Compare and contrast an organization and an enterprise.
3. What are some of the academic fields that influence the field
of EA?
4. Describe the purpose of each level of the Parsons/Thompson
Model.
5. How is the Organization Network Model different from the
Parsons/Thompson Model of organizations?
6. Who are stakeholders in the EA program and associated
activities and
might they want to resist the EA program and associated
activities?
7. What are four ways to manage change with stakeholders?
8. Select a large or mid-size enterprise from business or
government and

describe the following:
a. What structural and cultural aspects should be captured by
EA?
b. Who are the potential stakeholders in an EA program?
c. What strategies for gaining stakeholder buy-in could be used?
d. Relate strategies for managing change to various
stakeholders.
Case Study:
Danforth Manufacturing Company
Scene 2: Considering an EA Program
Robert Danforth, the President and CEO of DMC, has called a
follow-on
meeting of the Executive Committee to review several recent
capital
investment requests and the suggestion to use an enterprise
architecture

approach to evaluate these requests and coordinate potential
implementation projects. COO Kate Jarvis has requested a new
custom
Sales and Inventory Tracking System (SITS), and CFO Jim
Gorman, has
requested a new cost accounting system that is part of a
commercial
software package. Also invited to the meeting is CIO Sam
Young, who
joined the company one month ago, and who is giving a briefing
on how
enterprise architecture can help in this review.
“Good morning everyone” said Robert. “I’m eager to hear what
you have
to say about the architecture initiative. Sam, why don’t you
lead off, and
then let’s hear from Kate and Jim.”
“Thank you Robert” said Sam as he handed out an 8-page
document
entitled DMC Enterprise Architecture Plan – Financial and
Production
Segments. “Kate, Jim, and I have spent a good deal of time
together

during the last two weeks and I believe that we have found
several
interesting things about their requirements and how an
architecture
approach can save us money and provide a more valuable long-
term
solution. We formed a working group to do the analysis and
included an
experienced enterprise architect and a senior systems analyst
who I know
from some past work, as well as several managers and staff
from Kate and
Jim’s groups, including two sales representatives from the field.
The
architect, Vince Albright, provided some background on what
enterprise
architecture is all about and how to document and evaluate
current and
future views of resources and requirements. With that, the
group
documented the current business services and associated IT
resources that
might be replaced or modified by Kate’s and Jim’s proposals.
Then, the
group documented Kate’s and Jim’s requirements from a

business process
perspective and looked for areas of commonality or duplication.
Finally,
Vince and the systems analyst, Lily Jefferson, led the group in a
scenario
planning exercise that developed two plausible business and
technology
solutions that meet both of their requirements in an integrated
manner.
Either of these integrated solutions look to be less expensive to
implement
than it will be to do Jim’s and Kate’s systems independently.”
Jim then spoke to the group. “I was really impressed with what
the group
did in only two weeks. Sam is right about looking at these
types of
requirements from an architecture perspective. What I realized
is that my
back office support systems can have more types of direct feeds

of
information from Kate’s line of business systems. In fact, the
more we do
this, the more timely and accurate the information across the
company will
be. The big thing here is that we eventually need to look at all
of our
business and technology requirements from a company-wide
standpoint so
that we can start to integrate and streamline our processes and
capabilities.”
Kate then spoke. “I agree with Jim that this was an eye-opener.
There are
flows of information between Jim’s financial group and my
business
managers, but these flows and the supporting systems have been
developed
independently with no overarching plan in mind. Sam and his
associates
showed me an architecture approach and implementation
process that can
be completed for our respective areas within the next two
months and then
be used to guide the implementation of a solution that I believe

will meet
my requirements and those that Jim has as well. This is a win-
win that can
lead to more of the same. Even the sales reps were getting into
the game,
and provided a couple of ideas about automatically pushing
sales and
inventory data to them that I had not considered. I am
recommending that
we go with this approach to refine and select a solution so that I
don’t lose
any more time on my competition.”
Gerald leaned forward and looked at Sam. “Sam, I remember
you saying
that enterprise architecture links strategy, business, and
technology. I am
not hearing about strategy…. was that left out?” “Good
question Gerald”
responded Sam. “We did not go too much into company
strategy because
of the two-week timeframe for developing the initial
architecture plan.
However, that is an area that we will have to quickly address if
the

architecture plan for these two segments is approved for
implementation.
The way that I would pursue this is to identify DMC’s strategic
goals that
relate to Kate and Jim’s requirements, and ensure that the
solutions align
with the accomplishment of those goals. For example, I see that
the
company will be opening a new custom order line of business
next year
that builds on what we are doing on an ad-hoc basis right now.
I would
want to see if the solution for Kate and Jim’s requirements
could also be
able to support similar requirements for the custom order
business.”
Robert then spoke. “I always want to talk about value and risk
before
approving any project. I am seeing value through cost savings
and

potential scalability of the solution. So, what is the cost of
doing these
segments and then the whole architecture? And, what are the
risks and
how do we mitigate those risks?”
“The cost of doing a complete and detailed architecture for a
mid-size
company like DMC may be considerable” said Sam. “And I
therefore
recommend this type of segmented approach to developing a
company-
wide architecture, where we take one line of business at a time.
In the plan
we developed, you will see that the cost for the first two
segments is
$105,000, which covers analysis, modeling, documentation, and
an EA
tool. There is also an $11,600 cost for documenting and
applying the
general architecture methodology, framework, and standards,
that is
largely reused in subsequent segment efforts. The analysis of
these two
segments should take two to three weeks, and depending on

which of the
two solutions is selected, the supporting documentation will
take another
month. So this plan delays Jim and Kate approximately two
months, but
saves the company well over the $121,600 cost if a combined
solution is
adopted.”
Sam continued. “By having a standardized architecture
approach, we
ensure alignment in each completed segment and can also use it
to guide
each new development and upgrade projects throughout the
company, so
that architecture alignment occurs much more quickly. This
approach is
also a risk mitigation strategy, in that we are spreading out the
cost and
effort over time, involving stakeholders in the development of
each
segment, and incorporating lessons learned from each segment
effort. Two
of the most important success factors for doing an enterprise
architecture

are the strong support of executive leadership, and buy-in from
stakeholders. If you see value in having an architecture, and
have a say in
how it affects you, then the architecture can become a powerful
planning
and decision-making tool for DMC.”
Robert thought for a moment about what Sam had said and then
addressed
the group. “I am inclined to approve the plan to develop a
standardized
architecture approach and these first two segments, are there
any
objections?” There were no other comments. “Ok Sam, let’s
proceed with
the plan and get together every two weeks for a progress
report.”
Chapter 3

The Value and Risk of Creating an
Enterprise Architecture
Chapter Overview
Chapter 3 discusses the value and risks associated with creating
an
enterprise-wide architecture. The main concepts of this chapter
are that
EA represents a different way of looking at resources across the
enterprise,
and that the significant cost of creating an EA must be justified
in terms of
the value that it will bring to users of EA products in their
planning and
decision-making activities.
Learning Objectives
Understand the potential value of the EA.
Understand the risks associated with implementing an EA.
Learn an approach for measuring the costs and benefits of an
EA
program.
Understand how EA helps integrate strategy, business, and

technology.
Introduction
There is both value and risk associated with the establishment
of an EA
program in an enterprise. On the value side, EA has the unique
capability
to bring together views of strategy, business, and technology
that allow an
enterprise to see itself in current and future operating states.
EA also
supports the modeling of different future operating scenarios,
which may
help the enterprise survive (or thrive) as it responds to changes
in the
internal and external operating environment, some of which can
be
unexpected. Additionally, an EA program establishes an
integrated set of
IT resource planning, decision-making, and implementation
processes that
can better identify and resolve performance gaps across the
enterprise.

On the risk side, creating an EA for an entire enterprise can be
time-
consuming, costly, and disruptive to business services. Also,
developing
detailed EA documentation that covers strategy, business, and
technology
within each area of the enterprise can be time consuming and
costly.
Hiring and/or training architects and supporting analysts is one
element of
the cost. Another cost element is the time it takes line of
business
managers and support staff away from their normal work.
Finally, the cost
of EA documentation tools and on-line repositories has to be
factored in as
well. Further, there is the risk that the EA will not be used by
stakeholders
if they do not buy-in to the concept of EA or its perceived
value.
On the value side, EA is unique in its ability to promote

enterprise-wide
thinking about resource utilization. EA replaces the systems-
level
approaches to IT resource development that have characterized
the last
several decades, and has left many enterprises with stovepipe
and/or
duplicative IT resources. EA promotes the development of
more efficient
enterprise-wide common operating environments for business
and
technology, within which more capable and flexible business
services and
systems can be hosted. This in turn makes an enterprise more
agile and
able to respond to internal and external drivers of change, which
promotes
greater levels of competitiveness in the marketplace.
The benefits should outweigh the costs of doing an EA, or the
program
should not be established. In the Case Study example, if an EA
program
helps DMC’s executives find a combined solution to two sets of
business

and technology requirements, then a significant amount of
money can be
saved. Multiply this by several of these situations each year,
and the EA
program may very well pay for itself. Further, EA helps to
identify
existing duplication in functional capability, which can generate
additional
savings. Finally, EA documentation helps to identify current
and future
performance gaps that may not be otherwise realized, which
enables the
enterprise to be more proactive and cost-efficient in addressing
solutions.
Home Architecture Analogy: A set of comprehensive blueprints
for
building a home takes an architect a fair amount of time and
money to
create. Without them though, any construction that occurs is an
uncoordinated activity, and the home that results may not
function properly.

Discussion
Value
The value of EA is that it enhances resource-planning
capabilities and
supports better decision-making. This is accomplished through
communication improvements in respect to current and future
resources.
Ideas are conveyed more rapidly while differences in
interpretations and
misunderstandings are reduced.
The overall value of EA will vary with the size and complexity
of the
enterprise, the type and number of IT-related performance gaps,
duplication within current IT resources, and stakeholder
acceptance. For
those larger, less centralized enterprises that are regional or
global in
nature, EA can be an effective governance process for IT
resources. For
smaller more centralized enterprises, EA can help to ensure that
the

organization remains able to align business requirements with
technology
solutions, and enhance inventory, security, and configuration
management
activities.
Improved Planning
EA enhances both top-down and bottom-up approaches to
planning. Top-
down planning begins with considerations for strategy and
business, which
are enhanced by the holistic perspectives of the enterprise that
EA
provides. Bottom-up planning is also enhanced, as EA
coordinates what
would otherwise be disparate and separate program-level
planning
activities. EA also enhances strategic planning as it helps to
bring together
multiple perspectives of business and technology at various
levels of the
enterprise. Finally, EA supports program and project
management by
providing a baseline of reference documentation for business
alignment,

standards, and configuration management.
Decision-Making
EA improves decision-making by providing comprehensive
views of
current capabilities and resources, as well as a set of plausible
future
operating scenarios that reveal needed changes in processes and
resources
(see Chapter 8 for additional details on future scenarios). By
having an on-
line EA repository of information that is updated at regular
intervals,
decision-makers have real-time access to higher-quality
information at
various levels of detail.
In that the EA program links to other areas of resource
governance (e.g.,
capital planning, project management, and security), decision-

makers can
obtain coordinated information on operations, support, and
development
activities. Chapters 10 and 11 provide additional details on the
relationship between EA, capital planning, project management,
and
security.
Communications
EA improves communication throughout the enterprise by
providing a
regularly updated baseline of integrated information on
strategy, business,
and technology. Also, the EA program and implementation
methodology
bring standardized approaches and terminologies for the
development and
management of enterprise resources. This standard EA
language and
methodology is especially helpful in large, complex enterprises
that are
geographically dispersed, and which may have multiple social
and work
cultures that have promoted different ways of doing things. EA
should not

stifle the creativity that cultural diversity can bring, but should
augment
and enhance that creativity by improving the alignment of
business and
technology to the strategic goals and initiatives of the
enterprise.
The old saying is that “a picture is worth a thousand words.”
Having an
on-line repository of EA information is like having a 24x7
gallery of
electronic documents and drawings that can be useful in a
variety of
activities throughout the enterprise. It is tremendously valuable
if the
members of an enterprise can electronically call-up the same set
of EA
reference materials at financial planning meetings, research and
development seminars, sales and marketing reviews, and daily
operations
and support activities. With an updated repository of EA
materials
available, meetings can convey greater amounts of information
in shorter
periods of time, achieving higher levels of understanding based

on a
common set of EA terms and information.
Managing Risk
Risk is related to uncertainty, and in applied form is the
potential source(s)
for the failure or underperformance of a program or project. The
management of risk involves lowering or eliminating the
uncertainty that
desired outcomes will not be realized. There are several types
of risk that
relate to the implementation and maintenance of an EA
program,
including:
Financial. Implementing an EA involves establishing current
and
future views of enterprise resources, an EA Management Plan,
and
updates to this information at regular intervals. Like any

implementation project, establishing the initial set of EA
information
will require start-up funding that is more than what will be
required for
the periodic updates. Even after the EA is established, cuts in
an EA
maintenance budget can severely affect the program, to the
point of
making the EA information eventually become of little or no use
if it
becomes too out of date.
Lack of Acceptance. EA represents a new way of looking at
enterprise
resources by providing an integrated view of strategy, business,
and
technology that supports the consolidation or re-engineered of
these
resources to produce additional value. Former approaches to
program
management that supported systems level planning will be
replaced
with EA level planning that is promoted through the EA
program. This
will most likely create some tensions between program level

stakeholders, EA stakeholders, and other affected groups.
Loss of Key Personnel. EA is an emerging area of professional
practice
that requires architects, analysts, developers, and programmers.
Each of
these skill sets is important to the program and the loss of
members of
the EA team with those skills can create delays in program
implementation, as well as effect implementation costs.
Schedule Delays. As with all implementation projects, the
documentation of current and future EA views as well as the
creation of
the initial EA Management Plan is approached as a project that
has
milestones and a specific schedule for completion. Delays to the
schedule can come from many sources and depending on the
point at
which a delay occurs during EA implementation, and how long
the
delay is, the effect can go from being negligible to being
catastrophic
for the EA program.

Documentation Tools. One of the greatest challenges for a
Chief
Architect is to develop current and future views of the EA that
are rich
in detail, easy to access, and which can support modeling and
decision-
making types of queries. The capabilities of EA tools and
supporting
applications at present are such that intuitive and informative
“management views” of EA information are difficult to produce
with
these tools. Further, because more than one software application
is
normally required in an EA program, tool integration is an issue
that
must be dealt with. As new commercial tools are introduced a
Chief
Architect has to consider what the effect will be on overall
documentation if that product does not integrate with other
tools.

Mitigating Risk
Risk mitigation plans and activities reduce the likelihood that
sources of
risk will emerge and negatively impact a program such as EA.
Actions
that mitigate risk (lower uncertainty) include strengthening
executive
support for the EA program, solidifying budgets, not being the
first adopter
of EA tools and documentation techniques, ensuring there are
trained
back-ups on the EA team, and using a detailed EA
implementation
methodology to guide the overall program. Additionally, basic
program
management skills address potential problems of key personnel
turnover,
cost and schedule overruns, performance issues, and stakeholder
acceptance. Overcoming issues related to technology
compatibility among
EA products is achieved through the use of commercial tools
that are based
on open standards, and which are mature and have significant
market

share.
Risk identification and mitigation is not a one-time activity, it
is an
ongoing management review item that will assist in making an
EA
program successful.
Quantifying EA Program Value
How to translate value to the bottom line is one of the biggest
questions
executives and Line of Business (LOB) managers have about EA
programs. Building a business case that includes an alternatives
analysis,
cost-benefit analysis, and return on investment calculation is
the primary
measure for evaluating the contribution to profitability and/or
mission
success (see the example Business Case in Appendix A). Many
aspects of
EA value can be quantified, including the following areas:
Shortening Planning Cycles. EA can help shorten planning
cycles by
providing a robust repository of on-line information regarding

current
and future processes and resources. While EA does not replace
strategic
planning or business process improvement activities, it does
enhance
them through contribution of useful information that that would
otherwise be gathered separately.
More Effective Planning Meetings. EA information allows for
the
presentation of a common baseline of planning and reference
information. It reduces ambiguity and increases levels of
common
understanding.
Shorter Decision-Making Cycles. The time it takes to gather and
cross-
walk strategy, business, and technology information is greatly
reduced
by having a repository of EA information that was developed

through
the use of a logical framework and archiving method. Decision-
making
processes can be streamlined to reflect the availability of this
new
resource of integrated baseline information.
Improved Reference Information. By using an EA
documentation
framework and implementation methodology, information on
processes
and resources is gathered in a standardized method using the
same tools
and applications. Additionally, the method for storing the
information
is coordinated through the use of the on-line EA repository,
which
requires the use of standardized data and document formats.
This in
turn creates the ability to perform queries for information across
otherwise disparate activities and resources. It also supports a
more
robust data mining and business analysis capability.
Reduction of Duplicative Resources. One of the greatest

contributions
an EA makes to an enterprise is aiding the visualization of the
value
that current resources provide, where those value areas overlap,
and
where performance gaps exist. For example, duplicative data
represents low-hanging fruit ready for elimination through the
implementation of the future architecture. Subsequent
improvements
might then focus on the introduction of new technologies and
improvements in efficiency.
Reduced Re-work. By approaching the planning and execution
of new
resources in a holistic manner, potential re-work that might
have been
created through individual program level initiatives (containing
duplicative and/or conflicting capabilities) can be avoided.
Also, re-
work is reduced through the use of a step-by-step EA
methodology and
framework (see Chapters 4 and 5), that call for standard
approaches to

documentation that are based on mature modeling and analysis
techniques.
Improved Resource Integration and Performance. EA promotes
integration through the planning and utilization of resources on
an
enterprise-wide basis. EA also helps to compare current and
future
requirements for business and technology, in order to identify
performance gaps and solutions. This result is contrasted with
stovepipe program-level inputs to provide incremental
improvements
within individual LOBs.
Fewer People in a Process. EA supports business process
reengineering
(BPR) and business process improvement (BPI) activities by
encouraging planning in the context of both enterprise-wide
crosscutting requirements and particular LOB requirements.
Quantifying this includes the elimination of parts of a process
that are
repetitive. Also, streamlined processes that use resources more

efficiently can equate to position requirement reductions and
payroll
savings.
Improved Communication. EA helps to promote a common
language
and central approach that can reduce misunderstandings of
resource
requirements and potential solutions. This can reduce re-work.
Whole
processes may require repetition due to misunderstandings of
different
interpretations of requirements and/or solutions.
Reduction in Cycle Time. EA can help an enterprise to reduce
the time
it takes to plan, develop, implement, and retire resources within
its
business and technology operating environment. By using an
EA
methodology and framework (see Chapters 4 and 5), each
resource is
evaluated from the same holistic strategy, business and
technology
viewpoint, and is documented using the same set of EA tools

and
techniques. Further, EA compliments capital planning and
program
management reviews of completed projects (see Chapters 10 and
11) so
that the ‘lessons learned’ can be applied to subsequent efforts.
In this
way, the enterprise can improve efficiency and reduce the
amount of
time it takes to implement similar resources. For example,
using an
integrated enterprise architecture/capital planning/project
management
approach to selecting, controlling, and evaluating investments
in web
sites, the enterprise will be more effective and efficient in
implementing
each subsequent web site, and can avoid creating duplicative
capabilities.
Quantifying EA Program Costs

The cost of EA should be approached from a program lifecycle
view that
centers on phases for implementation, maintenance, and
refreshment. One
way to estimate EA program costs is to look at each area of the
EA
implementation methodology (see Chapter 4), and identify the
direct and
indirect costs to accomplish each of the steps. In general, this
would
include the following:
EA program administration and other enterprise administrative
tie-ins
Salary/benefits for a Chief Architect and EA team staff
Meetings, facilities, materials, and support for stakeholder
planning
sessions
Computers, applications, and web developers to establish the
EA
repository
Interviews and materials to document EA current views
Future scenario planning sessions with stakeholders
Interviews and materials to document EA future views
Development and documentation of the EA Management Plan

Purchase, use, and refreshment of EA modeling applications and
computers
Regular (e.g., annual) updates to EA documentation and the
online
repository
The cost of establishing an initial version of the EA will be
more than the
cost of updating and maintaining it, due to the direct and
indirect costs
associated with establishing new EA processes and capabilities,
and
gaining stakeholder support.
The full lifecycle cost of the EA program should be established
and
presented to the EA program sponsor, so that there is a clear
understanding
of the one-time costs for implementation of the EA and the
ongoing costs
for EA maintenance and refreshment activities. As with any
program, this
budget picture should be baselined relative to the EA program
activities
that are approved by the sponsor, so that any approved changes

to the
scope of those EA activities are accompanied by a change to the
budget. If
this is not done, the EA program may evolve to a position of
being
responsible for too much relative to the resources it has
available.
In that EA is an advanced analytic type of activity, most of the
cost of
developing and maintaining EA documentation will be the cost
of labor for
trained architects. The second largest cost area will be the
supporting
technology (hardware, software, web applications, databases,
EA tools,
etc.). The other major cost area will be the facility costs for the
EA team’s
work area and meetings with stakeholders.
Those who do EA (in total or in part) for a living work under a

variety of
job titles, including Chief Architect,

THIRD EDITIONAn Introduction toEnterprise Archit.docx

More Related Content

Similar to THIRD EDITIONAn Introduction toEnterprise Archit.docx (20)

More from christalgrieg (20)

Recently uploaded (20)

THIRD EDITIONAn Introduction toEnterprise Archit.docx