Information Technology: A Framework for Assessing and Improving
Enterprise Architecture Management (Version 1.1) (01-APR-03,
GAO-03-584G).
Effective use of enterprise architectures is a recognized
hallmark of successful public and private organizations. For over
a decade, GAO has promoted the use of architectures, recognizing
them as a crucial means to a challenging goal: agency operational
structures that are optimally defined, in both business and
technological environments. The alternative, as GAO's work has
shown, is perpetuation of the kinds of operational environments
that saddle most agencies today, in which lack of integration
among business operations and supporting information technology
(IT) resources leads to inefficiencies and duplication. Why are
enterprise architectures so important? Metaphorically, an
enterprise architecture is to an organization's operations and
systems as a set of blue prints is to a building. That is,
building blueprints provide those who own, construct, and
maintain the building with a clear and understandable picture of
the building's uses, features, functions, and supporting systems,
including relevant building standards. Further, the building
blueprints capture the relationships among building components
and govern the construction process. Enterprise architectures
provide to people at all organizational levels an explicit,
common, and meaningful structural frame of reference that allows
and understanding of (1) what the enterprise does; (2) when,
where, how, and why it does it; and (3) what it uses to do it.
-------------------------Indexing Terms-------------------------
REPORTNUM: GAO-03-584G
ACCNO: A06709
TITLE: Information Technology: A Framework for Assessing and
Improving Enterprise Architecture Management (Version 1.1)
DATE: 04/01/2003
SUBJECT: Information technology
Management information systems
Agency missions
Internal controls
Best practices
******************************************************************
** This file contains an ASCII representation of the text of a **
** GAO Product. **
** **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced. Tables are included, but **
** may not resemble those in the printed version. **
** **
** Please see the PDF (Portable Document Format) file, when **
** available, for a complete electronic file of the printed **
** document's contents. **
** **
******************************************************************
GAO-03-584G
A
Executive Guide
April 2003 INFORMATION TECHNOLOGY A Framework for Assessing and Improving
Enterprise Architecture Management (Version 1.1)
GAO- 03- 584G
a
GAO United States General Accounting Office
Page i GAO- 03- 584G Enterprise Architecture Management Preface Effective
use of enterprise architectures is a recognized hallmark of successful
public and
private organizations. For over a decade, GAO has promoted the use of
architectures, recognizing them as a crucial means to a challenging goal:
agency operational structures that are optimally defined, in both business
and technological environments. The
alternative, as GAO*s work has shown, is perpetuation of the kinds of
operational environments that saddle most agencies today, in which lack of
integration among business operations and supporting information
technology (IT) resources leads to
inefficiencies and duplication. Why are enterprise architectures so
important? Metaphorically, an enterprise architecture is to an
organization*s operations and systems as a set of blueprints is to a
building. That is, building blueprints provide those who own, construct,
and maintain the building with a clear and understandable picture of the
building*s uses, features, functions, and supporting systems, including
relevant building standards. Further, the building blueprints capture the
relationships among building components and govern the
construction process. Enterprise architectures do nothing less, providing
to people at all organizational levels an explicit, common, and meaningful
structural frame of reference that allows an understanding of (1) what the
enterprise does; (2) when, where, how, and why it does it; and (3) what it
uses to do it.
Through our research of best IT management practices and our evaluations
of agency IT management performance, we have identified a set of essential
and complementary management disciplines. These include
IT investment management,
software/ system development and acquisition management,
IT services acquisition management,
IT human capital management,
information security management, and
enterprise architecture management. Using the results of this research and
evaluation, we have developed various IT management frameworks and guides.
The federal Chief Information Officers (CIO) Council, at times in
collaboration with us, has also published such guidance documents.
Page ii GAO- 03- 584G Enterprise Architecture Management In building on
this portfolio of guidance documents, we offer here the first update to
our maturity framework for enterprise architecture management. 1 Its
purpose is to provide
federal agencies with a common benchmarking tool for planning and
measuring their efforts to improve enterprise architecture management, as
well as to provide the Office of Management and Budget with a means for
doing the same governmentwide. This update is based on comments received
on the initial version. Like the initial version, the update extends A
Practical Guide to Federal Enterprise Architecture, Version 1.0, published
by the CIO Council, by arranging the core elements in that guide into a
matrix of five hierarchical stages and four critical success attributes.
Questions and comments about the framework should be directed to me at
(202) 512- 3439. I can also be reached at hiter@ gao. gov. Key
contributors to this report were Naba Barkakati, Mark Bird, Barbara
Collier, Deborah Davis, Neil Doherty, Tamra Goldstein, and Randolph
Tekeley.
Randolph C. Hite Director, Information Technology Architecture and Systems
Issues
1 The first version was introduced in U. S. General Accounting Office,
Information Technology: Enterprise Architecture Use Across the Federal
Government Can Be Improved, GAO- 02- 6 (Washington, D. C.: Feb. 19, 2002).
Page iii GAO- 03- 584G Enterprise Architecture Management Contents
Preface
.............................................................................................................................................
i Section 1.
Introduction..................................................................................................................
1 What Is an Enterprise Architecture?
...............................................................................................
1 A Brief History of EA Management Guidance
..............................................................................
3
Section 2. Description of EAMMF Version 1.1
..........................................................................
5 Maturity Stages
...............................................................................................................................
7 Stage 1: Creating EA
Awareness..............................................................................................
7 Stage 2: Building the EA Management Foundation
................................................................. 7 Stage
3: Developing the
EA......................................................................................................
8 Stage 4: Completing the EA
.....................................................................................................
8
Stage 5: Leveraging the EA to Manage
Change.......................................................................
9 Critical Success
Attributes..............................................................................................................
9
Attribute 1: Demonstrates
Commitment.................................................................................
10 Attribute 2: Provides Capability to Meet
Commitment.......................................................... 10
Attribute 3: Demonstrates Satisfaction of
Commitment......................................................... 10
Attribute 4: Verifies Satisfaction of
Commitment..................................................................
11 Core
Elements...............................................................................................................................
11
Stage 1: Creating EA
Awareness............................................................................................
11 Elements for Stage 2: Building the EA Management
Foundation.......................................... 11 Elements Added for
Stage 3: Developing EA Products
......................................................... 16 Elements
Added for Stage 4: Completing the EA Products
................................................... 19 Elements Added for
Stage 5: Leveraging the EA to Manage
Change.................................... 22 Overall View of EAMMF
Matrix.................................................................................................
26 Section 3. Uses of EAMMF Version 1.1
....................................................................................
28 Tool for Assessing EA Management
Maturity.............................................................................
28
EA Management Improvement Planning
.....................................................................................
29
Appendix. Approach to Developing EAMMF Version
1.1...................................................... 31 Figures
Figure 1: Simplified Three- Dimensional View of
EAMMF........................................................... 5 Figure
2: Transitional View to Two- Dimensional EAMMF
Matrix............................................... 6 Figure 3: Two-
Dimensional EAMMF
Matrix.................................................................................
6 Figure 4: EAMMF Matrix with Five Stages of Maturity Identified
.............................................. 7 Figure 5: EAMMF Matrix
with Critical Success Attributes Added
............................................ 10 Figure 6: Summary of EAMMF
Version 1.1: Maturity Stages, Critical Success Attributes, and
Core Elements
.............................................................................................................
27 Tables
Table 1. Criteria for Selecting Automated EA Development and Maintenance
Tools................. 14 Table 2. Major Categories of Comments and
Suggestions ........................................................... 32
Page iv GAO- 03- 584G Enterprise Architecture Management Abbreviations CIO
chief information officer C4ISR Command, Control, Communications,
Computers, Intelligence,
Surveillance, and Reconnaissance DOD Department of Defense EA enterprise
architecture EAMMF Enterprise Architecture Management Maturity Framework
FEAF Federal Enterprise Architecture Framework IT information technology
ITIM Information Technology Investment Management
OMB Office of Management and Budget TEAF Treasury Enterprise Architecture
Framework
This is a work of the U. S. government and is not subject to copyright
protection in the United States. It may be reproduced and distributed in
its entirety without further permission from GAO. However, because this
work may contain copyrighted images or other material, permission from the
copyright holder may be necessary if you wish to reproduce this material
separately.
Page 1 GAO- 03- 584G Enterprise Architecture Management Section 1.
Introduction An enterprise architecture (EA) provides a clear and
comprehensive picture of the
structure of an entity, whether an organization or a functional or mission
area. It is an essential tool for effectively and efficiently engineering
business processes and for implementing and evolving supporting systems.
The concept of an architecture to describe an enterprise first emerged in
the mid- 1980s, and over the years various frameworks 2 for defining the
content of EAs have been published. Our work in the early 1990s identified
architectures as a critical success factor allowing organizations to
effectively apply information technology (IT) to meet mission goals. Since
then, we have worked with the Congress, the Office of Management and
Budget (OMB), and the federal Chief Information Officers (CIO) Council to
recognize the importance of architectures and assist agencies in
developing, maintaining, and using them. In our reviews of agency IT
management practices and major systems modernization programs, we continue
to identify the lack of an architecture as a major management weakness,
and we have made numerous recommendations addressing this important area.
What Is an Enterprise Architecture? In simple terms, an enterprise can be
viewed as any purposeful activity, and an architecture can be
characterized as the structure (or structural description) of any
activity. Building on this, EAs can be viewed as systematically derived
and captured structural descriptions* in useful models, diagrams, and
narrative* of the mode of operation for a given enterprise, which can be
(1) a single organization or (2) a functional or mission area that
transcends more than one organizational boundary (e. g., financial
management, homeland security).
The concept of EAs dates back to the mid- 1980s. At that time, John
Zachman, widely recognized as a leader in the field of enterprise
architecture, identified the need to use a logical construction blueprint
(i. e., an architecture) for defining and controlling the integration of
systems and their components. 3 Accordingly, Zachman developed a structure
or *framework* for defining and capturing an architecture. In his work,
Zachman drew parallels to the field of classical architecture and later to
the aircraft manufacturing industry, in which different work products (e.
g., architect plans, contractor
plans, shop plans, and bills of lading) represent different views of the
planned building or aircraft. Similarly, Zachman*s framework identified
the kinds of work products needed for people to understand and thus build
a given system or entity. This framework
provides for six windows from which to view the enterprise, which Zachman
terms 2 A framework can be viewed as a logical structure for classifying
and organizing complex information. 3 J. A. Zachman, *A Framework for
Information Systems Architecture,* IBM Systems Journal 26, no. 3 (1987).
Page 2 GAO- 03- 584G Enterprise Architecture Management *perspectives* on
how a given entity operates: those of (1) the strategic planner, (2) the
system user, (3) the system designer, (4) the system developer, (5) the
subcontractor, and
(6) the system itself. Zachman also proposed six abstractions or models
associated with each of these perspectives: these models cover (1) how the
entity operates, (2) what the entity uses to operate, (3) where the entity
operates, (4) who operates the entity, (5) when entity operations occur,
and (6) why the entity operates. Zachman*s framework provides a way to
identify and describe an entity*s existing and planned component parts and
the parts* relationships before one begins the costly and time- consuming
efforts associated with developing or transforming the entity. Since
Zachman introduced his framework, a number of other frameworks have been
proposed. In September 1999, the federal CIO Council published the Federal
Enterprise Architecture Framework (FEAF), which is intended to provide
federal agencies with a common construct for their respective
architectures, thereby facilitating the coordination of common business
processes, technology insertion, information flows, and system investments
among federal agencies. The FEAF describes an approach, including models
and definitions, for developing and documenting architecture descriptions
for multiorganizational functional segments of the federal government.
Similar to the Zachman framework, the FEAF*s proposed models describe an
entity*s business, data necessary to conduct the business, applications to
manage the data, and technology to support the applications.
More recently, OMB established the Federal Enterprise Architecture Program
Management Office to develop a federated enterprise architecture according
to a collection of five *reference models*: The Business Reference Model
is intended to describe the business operations of the
federal government independent of the agencies that perform them,
including defining the services provided to state and local governments.
The Performance Reference Model is to provide a common set of general
performance outputs and measures for agencies to use to achieve business
goals and objectives.
The Data and Information Reference Model is to describe, at an aggregate
level, the type of data and information that support program and business
line operations, and the relationships among these types.
The Service Component Reference Model is to identify and classify IT
service (i. e., application) components that support federal agencies and
promote the reuse of components across agencies.
The Technical Reference Model is to describe how technology is supporting
the delivery of service components, including relevant standards for
implementing the technology. Together, the reference models are intended
to facilitate governmentwide improvement through cross- agency analysis
and the identification of duplicative investments, gaps, and opportunities
for collaboration, interoperability, and integration within and across
government agencies.
These post- Zachman frameworks differ in their nomenclatures and modeling
approach. However, the frameworks consistently provide for defining an
enterprise*s operations in
Page 3 GAO- 03- 584G Enterprise Architecture Management both (1) logical
terms, such as interrelated business processes and business rules,
information needs and flows, and work locations and users, and (2)
technical terms, such
as hardware, software, data, communications, and security attributes and
performance standards. The frameworks also provide for defining these
perspectives both for the enterprise*s current or *as- is* environment and
for its target or *to- be* environment, as well as a transition plan for
moving from the *as- is* to the *to- be* environment.
The importance of developing, implementing, and maintaining an EA is a
basic tenet of both organizational transformation and IT management.
Managed properly, an EA can clarify and help optimize the
interdependencies and relationships among an organization*s business
operations and the underlying IT infrastructure and applications that
support these operations. Employed in concert with other important
management controls, such as portfolio- based capital planning and
investment control practices, architectures can greatly increase the
chances that organizations* operational and IT environments will be
configured so as to optimize mission performance. Our experience with
federal agencies has shown that investing in IT without defining these
investments
in the context of an architecture often results in systems that are
duplicative, not well integrated, and unnecessarily costly to maintain and
interface. 4 A Brief History of EA Management Guidance
Since the late 1980s, architecture guidance has emerged within the federal
government, beginning with the publication of the National Institute of
Standards and Technology guidance in 1989. 5 Subsequently, we issued
architecture guidance 6 and published our
research on successful public- and private- sector organizations* IT
management practices, which identified the use of architectures as a
factor critical to these organizations* success. 7 Since that time, other
federal entities have issued frameworks for defining the content of EAs,
including the Department of Defense, 8 Department of the
Treasury, 9 and the federal CIO Council 10 (some of which were described
earlier). These frameworks are being used today to varying degrees by many
federal agencies.
4 See, for example, U. S. General Accounting Office, DOD Business Systems
Modernization: Improvements to Enterprise Architecture Development and
Implementation Efforts Needed, GAO- 03- 458 (Washington, D. C.: February
2003); Information Technology: DLA Should Strengthen Business Systems
Modernization Architecture and Investment Activities, GAO- 01- 631
(Washington, D. C.: June 2001); and Information Technology: INS Needs to
Better Manage the Development of Its Enterprise Architecture, AIMD- 00-
212 (Washington, D. C.: August 2000). 5 National Institute of Standards
and Technology, Information Management Directions: The Integration
Challenge, Special Publication 500- 167 (September 1989). 6 U. S. General
Accounting Office, Strategic Information Planning: Framework for Designing
and Developing System Architectures, GAO/ IMTEC- 92- 51 (Washington, D.
C.: June 1992). 7 U. S. General Accounting Office, Executive Guide:
Improving Mission Performance through Strategic Information Management and
Technology, GAO/ AIMD- 94- 115 (Washington, D. C.: May 1994). 8 DOD C4ISR
Architecture Framework, Version 2. 0 (Dec. 18, 1997). 9 Treasury
Enterprise Architecture Framework, Version 1.0 (July 3, 2000). 10 Federal
Enterprise Architecture Framework, Version 1.1 (September 1999).
Page 4 GAO- 03- 584G Enterprise Architecture Management The emergence of
federal frameworks and guidance over the last 5 years is largely owing to
the Congress*s passage of the Clinger- Cohen Act in 1996. 11 This act,
among other things, requires the CIOs for major departments and agencies
to develop, maintain, and
facilitate the implementation of architectures as a means of integrating
business processes and agency goals with IT. In response to the act, OMB,
in collaboration with us, issued guidance on the development and
implementation of EAs. 12 More recently, OMB issued additional guidance
directing that agency investments in IT be based on agency architectures.
13 Similarly, the CIO Council, in addition to publishing the FEAF,
recently collaborated
with us in issuing two additional EA guidance documents. The first
addresses enforcement and describes how an organization should go about
assessing whether its proposed IT investments are compliant with its EA.
14 The second addresses development, maintenance, and implementation,
describing in practical terms an end- to- end set of steps for an EA
program. 15 These steps include how to get started and organized, what
kind of management controls are needed, what factors to consider in
formulating an EA development approach, how to go about defining the
current and target architecture and the plan for sequencing from the
current to the target, how to ensure that the architecture is implemented
and enforced, and how to systematically refresh and maintain the
architecture to ensure its currency and relevance. The need for greater
federal agency awareness and use of EAs was also recognized in the E-
Government Act of 2002, 16 which established the OMB Office of Electronic
Government; this office*s responsibilities include overseeing the
development of EAs within and across federal
agencies. 17 11 Clinger- Cohen Act of 1996, Public Law 104- 106, section
5125, 110 Stat. 684 (1996). 12 OMB, Information Technology Architectures,
Memorandum M- 97- 16 (June 18, 1997), rescinded with the update of OMB
Circular A- 130 (Nov. 30, 2000). 13 Office of Management and Budget,
Management of Federal Information Resources, Circular No. A- 130 (Nov. 30,
2000). 14 Chief Information Officers Council, Architecture Alignment and
Assessment Guide (October 2000). 15 Chief Information Officers Council, A
Practical Guide to Federal Enterprise Architecture, Version 1.0
(February 2001). 16 E- Government Act of 2002, Public Law 107- 347 (Dec.
17, 2002). 17 The E- Government Act of 2002 states that the Administrator
of the Office of Electronic Government shall work with the Administrator
of the Office of Information and Regulatory Affairs and with other offices
within the OMB to oversee, among other things, the development of
enterprise architectures.
Page 5 GAO- 03- 584G Enterprise Architecture Management Section 2.
Description of EAMMF Version 1.1 The ability to effectively manage any
activity (e. g., architecture development,
maintenance, and use) depends upon having meaningful measures of that
activity in relation to some standard. Such measurement permits managers
to assess progress toward the desired end and to take corrective action to
address unacceptable deviations. In February 2002, we issued Version 1.0
of the Enterprise Architecture Management
Maturity Framework (EAMMF). 18 The framework consists of three basic
components: (1) hierarchical stages of management maturity, (2) categories
of attributes that are critical to success in managing any endeavor, and
(3) elements of EA management that form the core of the CIO Council
Practical Guide. These three EAMMF components are interrelated, as
depicted in figure 1, and are described in greater detail below.
Figure 1: Simplified Three- Dimensional View of EAMMF Elements, or more
specifically core elements, are descriptions of a practice or condition
that is needed for effective EA management. An example is designating a
chief architect. The version of our framework presented here (Version 1.1)
specifies 31 core elements, each of which is derived from the CIO Council
Practical Guide. Based on the implicit dependencies among these 31 core
elements, the EAMMF associates each element to one of five hierarchical
management stages, referred to as maturity stages. Each stage reflects the
collection of EA management practices and conditions (i. e., core
elements) being undertaken by an enterprise at a given maturity level. An
example of a stage is building the EA management foundation (Stage 2). The
EAMMF also associates each element to one of four types of management
attributes, referred to as critical success attributes. Each
attribute represents a category or type of management practice and
condition (i. e., core element) that is needed to effectively discharge
any function. An example of a critical success attribute is demonstrating
the institutional commitment to perform the function. 18 The first version
was introduced in U. S. General Accounting Office, Information Technology:
Enterprise Architecture Use across the Federal Government Can Be Improved,
GAO- 02- 6 (Washington, D. C.: Feb.
19, 2002).
Page 6 GAO- 03- 584G Enterprise Architecture Management Building on figure
1, figure 2 adds the number of core elements, maturity stages, and
critical success attributes, and provides a transition to the EAMMF matrix
19 presented in
figure 3.
Figure 2: Transitional View to Two- Dimensional EAMMF Matrix Figure 3:
Two- Dimensional EAMMF Matrix The EAMMF is consistent with other maturity
frameworks, such as GAO*s Information Technology Investment Management
(ITIM) framework, 20 in that the EAMMF outlines steps toward achieving a
stable and mature process for managing the development, maintenance, and
implementation of EA. As an organization improves its EA management
capabilities, its EA management maturity increases. By establishing the
current level of maturity of an organization, managers are able to use the
framework to
determine steps needed to improve architecture management. 19 The EAMMF
matrix differs from a classical matrix in that each maturity stage
includes not only the core elements in the column below that stage, but
also the core elements of previous, less mature stages. That is, the core
elements are cumulative: the attainment of a particular stage of maturity
does not involve dropping any core elements, but rather adding more core
elements to the repertoire. 20 U. S. General Accounting Office,
Information Technology Investment Management: A Framework for Assessing
and Improving Process Maturity, Exposure Draft, GAO/ AIMD- 10.1.23 (May
2000).
Page 7 GAO- 03- 584G Enterprise Architecture Management Because the EAMMF
is derived from the CIO Council Practical Guide, the framework should be
viewed as an extension of the Practical Guide and thus used in tandem with
it.
Accordingly, the EAMMF is not intended to repeat the level of guidance
provided in the
Practical Guide, but rather to arrange key aspects (i. e., core elements)
of the guide into a hierarchical model for use either as an evaluation
tool or as a roadmap for EA management improvement. To facilitate this
use, we have included references in the descriptions of the core elements
indicating the corresponding sections in the Practical Guide. Maturity
Stages The EAMMF is made up of five stages of EA maturity, each of which
includes all
elements of previous stages. Each of the five stages is described below.
To the generic EAMMF structure of figure 3, figure 4 adds the specific
names of the five stages.
Figure 4: EAMMF Matrix with Five Stages of Maturity Identified (in bold)
Stage 1: Creating EA awareness
Stage 2: Building the EA management foundation Stage 3:
Developing EA products Stage 4: Completing EA products Stage 5:
Leveraging the EA to manage change critical success attribute 1 core
elements (2) core elements (1) core elements (1) core elements (1)
critical success attribute 2 core elements (3) core elements (1) core
elements (1) core elements (2) critical success attribute 3 core elements
(3) core elements (3) core elements (5) core elements (3) critical success
attribute 4 core elements (1) core elements (1) core elements (1) core
elements (2)
maturation Source: GAO.
Stage 1: Creating EA Awareness At Stage 1, either an organization does not
have plans to develop and use an architecture, or it has plans that do not
demonstrate an awareness of the value of having and using an architecture.
While Stage 1 agencies may have initiated some EA activity, these
agencies* efforts are ad hoc and unstructured, lack institutional
leadership and direction, and do not provide the management foundation
necessary for successful EA development as defined in Stage 2. Stage 2:
Building the EA Management Foundation An organization at Stage 2
recognizes that the EA is a corporate asset by vesting accountability for
it in an executive body that represents the entire enterprise. At this
stage, an organization assigns EA management roles and responsibilities
and establishes plans for developing EA products and for measuring program
progress and product quality; it also commits the resources necessary for
developing an architecture* people,
Page 8 GAO- 03- 584G Enterprise Architecture Management processes, and
tools. Specifically, a Stage 2 organization has designated a chief
architect and established and staffed a program office responsible for EA
development and maintenance. Further, it has established a committee or
group that has responsibility for
EA governance (i. e., directing, overseeing, and approving architecture
development and maintenance). This committee or group is often called a
steering committee, and its membership includes both business and IT
representatives (i. e., the committee has enterprisewide representation).
At Stage 2, the organization either has plans for developing or has
started developing at least some EA products, and it has developed an
enterprisewide awareness of the value of EA and its intended use in
managing its IT investments. The organization has also selected a
framework and a methodology that will
be the basis for developing the EA products and has selected a tool for
automating these activities.
Stage 3: Developing the EA An organization at Stage 3 focuses on
developing architecture products according to the selected framework,
methodology, tool, and established management plans. Roles and
responsibilities assigned in the previous stage are in place, and
resources are being applied to develop actual EA products. Here, the scope
of the architecture has been
defined to encompass the entire enterprise, whether organization- based or
function- based. Although the products may not be complete, they are
intended to describe the organization in business, performance,
information/ data, service/ application, and technology terms (including
security explicitly in each), as provided for in the framework,
methodology, tool, and management plans. Further, the products are to
describe the current (* as- is*) and future (* to- be*) states and the
plan for transitioning from the current to the future state (the
sequencing plan). As the products are developed
and evolve, they are subject to configuration management. Further, through
the established EA management foundation, the organization is tracking and
measuring its progress against plans, identifying and addressing
variances, as appropriate, and then reporting on its progress. Stage 4:
Completing the EA
An organization at Stage 4 has completed its EA products, meaning that the
products have been approved by the EA steering committee (established in
Stage 2) or an investment review board, and by the CIO. The completed
products collectively describe
the enterprise in terms of business, performance, information/ data,
service/ application, and technology for both its current and future
operating states, and the products include a transition plan for
sequencing from the current to the future state. Further, an independent
agent has assessed the quality (i. e., completeness and accuracy) of the
EA products. Additionally, evolution of the approved products is governed
by a written EA maintenance policy approved by the head of the
organization.
Page 9 GAO- 03- 584G Enterprise Architecture Management Stage 5:
Leveraging the EA to Manage Change An organization at Stage 5 has secured
senior leadership approval of the EA products and
a written institutional policy stating that IT investments must comply
with the architecture, unless granted an explicit compliance waiver.
Further, decision- makers are using the architecture to identify and
address ongoing and proposed IT investments that are conflicting,
overlapping, not strategically linked, or redundant. Thus, Stage 5
entities are able to avoid unwarranted overlap across investments and
ensure maximum systems interoperability, which in turn ensures the
selection and funding of IT investments with manageable risks and returns.
Also at Stage 5, the organization tracks and measures EA benefits or
return on investment, and adjustments are continuously made to both the EA
management process and the EA products.
Critical Success Attributes Associated with the maturity stages described
above are characteristics or attributes that are critical to the
successful performance of any management function. These critical success
attributes are (1) showing a commitment to perform the function; (2)
putting in place the capability (people, processes, and technology) needed
to perform the
function; (3) demonstrating, via production and results, that the function
has been performed; and (4) verifying, via quantitative and qualitative
measurement, that the function was
satisfactorily performed. Collectively, these attributes form the basis by
which an organization can institutionalize management of any given
function or program, like EA management. Each of the EAMMF critical
success attributes is described below. Figure 5 presents the four specific
critical success attributes, building on the previous figures.
Page 10 GAO- 03- 584G Enterprise Architecture Management Figure 5: EAMMF
Matrix with Critical Success Attributes Added (in bold)
Stage 1: Creating EA awareness Stage 2: Building the EA management
foundation Stage 3: Developing EA products Stage 4: Completing EA products
Stage 5: Leveraging the EA to manage change Attribute 1:
Demonstrates commitment core elements (2) core elements (1) core elements
(1) core elements (1)
Attribute 2: Provides capability to meet commitment core elements (3) core
elements (1) core elements (1) core elements (2)
Attribute 3: Demonstrates satisfaction of commitment core elements (3)
core elements (3) core elements (5) core elements (3)
Attribute 4: Verifies satisfaction of commitment core elements (1) core
elements (1) core elements (1) core elements (2)
maturation Source: GAO.
Attribute 1: Demonstrates Commitment Because the EA is a corporate asset
for systematically managing institutional change, the support and
sponsorship of the head of the enterprise are essential to the success of
the architecture effort. An approved enterprise policy statement provides
such support and sponsorship, promoting institutional *buy- in* and
encouraging resource commitment from participating components. Equally
important in demonstrating commitment is vesting ownership of the
architecture with an executive body that collectively owns the enterprise.
Attribute 2: Provides Capability to Meet Commitment The success of the EA
effort depends largely on the organization*s capacity to develop,
maintain, and implement the EA. Consistent with any large IT project,
these capabilities include providing adequate resources (i. e., people,
processes, and technology); defining clear roles and responsibilities; and
defining and implementing organizational structures
and process management controls that promote accountability and effective
project execution.
Attribute 3: Demonstrates Satisfaction of Commitment Demonstrating
satisfaction of the organization*s commitment to develop, maintain, and
implement an EA is evidenced by the production of artifacts (e. g., the
plans and products). Such artifacts demonstrate *follow through** actual
EA production. Satisfaction of commitment is further demonstrated by
senior leadership approval of EA
Page 11 GAO- 03- 584G Enterprise Architecture Management documents and
artifacts; this approval communicates institutional endorsement and
ownership of the architecture and the change that it is intended to drive.
Attribute 4: Verifies Satisfaction of Commitment This attribute focuses on
measuring and disclosing the extent to which efforts to develop, maintain,
and implement the EA have fulfilled stated goals or commitments. Measuring
such performance allows for tracking progress that has been made toward
stated goals, allows appropriate actions to be taken when performance
deviates significantly from goals, and creates incentives to influence
both institutional and individual behaviors.
Core Elements At the core of the EAMMF are the EA management elements (i.
e., practices and conditions) described in the CIO Council Practical
Guide. Each of the core elements is briefly described below, along with
references to the Practical Guide, where additional explanation and
guidance can be found. Stage 1: Creating EA Awareness At Stage 1,
organizations are becoming aware of the value of an EA, but have not yet
established the management foundation needed to develop one. Stage 1 has
no core elements; by default, an organization that does not satisfy Stage
2 core elements is at Stage 1. Elements for Stage 2: Building the EA
Management Foundation Stage 2: Building the EA management foundation Stage
1 Attribute 1: Demonstrates commitment Adequate resources exist. Committee
or group representing the enterprise is responsible for directing,
overseeing, or approving EA.
Attribute 2: Provides capability to meet commitment Program office
responsible for EA development and maintenance exists. Chief architect
exists. EA is being developed using a framework, methodology, and
automated tool. Attribute 3: Demonstrates satisfaction of commitment EA
plans call for describing both the *as- is* and the *to- be* environments
of the enterprise, as well as a sequencing plan for transitioning from the
*as- is* to the *to- be.* EA plans call for describing both the *as- is*
and the *to- be* environments in terms of business, performance,
information/ data, application/ service, and technology. EA plans call for
business, performance, information/ data, service, and technology
descriptions to address security. Attribute 4: Verifies satisfaction of
commitment EA plans call for developing metrics for measuring EA progress,
quality, compliance, and return on investment. Source: GAO.
At Stage 2, organizations move from basic awareness to building the
foundation for effectively developing, maintaining, and implementing an
EA.
Page 12 GAO- 03- 584G Enterprise Architecture Management Attribute:
Demonstrates commitment Element: Adequate resources exist. An organization
should have the resources (funding, people, tools, and technology) to
establish and effectively manage its architecture. This includes
identifying and securing adequate funding to support EA activities; hiring
and retaining the right people with the
proper knowledge, skills, and abilities to plan and execute the EA
program; and selecting and acquiring the right tools and technology to
support EA activities.
Reference: CIO Council Practical Guide, Section 3.1.1: Ensure Agency Head
Buy- in and Support; Section 3.1.3: Obtain Support from Senior Executives
and Business Units; Section 3.2: Establish Management Structure and
Control; Section 6.1.1: Train Personnel
Element: Committee or group representing the enterprise is responsible for
directing, overseeing, or approving EA.
An organization should assign responsibility for directing, overseeing,
and approving the architecture not to just one individual, but to a
committee or group with representation from across the enterprise.
Establishing this enterprisewide responsibility and accountability is
important in demonstrating the organization*s commitment to building the
management foundation and obtaining buy- in from across the organization.
Accordingly, this group should include executive- level representatives
from each line of business, and these representatives should have the
authority to commit resources and enforce decisions within their
respective organizational units. Typically, this group, established by the
organization head, serves as a *steering committee* and is responsible for
guiding, directing, and approving EA plans and products, including
significant changes to either.
Reference: CIO Council Practical Guide, Section 3.2.3: Establish an
Executive Steering Committee Attribute: Provides capability to meet
commitment Element: Program office responsible for EA development and
maintenance exists. EA development and maintenance should be managed as a
formal program. Accordingly, responsibility for EA management should be
assigned to an organizational unit and not
simply an individual. Typically in the form of a program office, this
organizational unit should be devoted to the EA program and responsible
for developing a management plan and executing the plan. The plan should
include a detailed work breakdown structure, resource estimates (e. g.,
funding, staffing, and training), performance measures, and management
controls for developing and maintaining the architecture. The program
office should have qualified staff serving as the core team. Examples of
functions performed by the EA program office are risk management,
configuration management, quality assurance, and security management.
Reference: CIO Council Practical Guide, Section 3.2.5: Establish an EA
Program Office
Page 13 GAO- 03- 584G Enterprise Architecture Management Element: Chief
architect exists. An organization should have a chief architect who is
responsible and accountable for the EA, and who is supported by the EA
program office and overseen by the enterprisewide
architecture steering committee. Appointed by the CIO and approved by the
organization head, the chief architect is typically an organization
executive whose background and qualifications span both the business and
technology sides of the organization and who also functions as the EA
program manager. The chief architect is responsible for ensuring the
integrity of the EA development process, as well as the content of the EA
products.
The chief architect should be experienced in, among other things, program
management, capital planning and investment control, and systems
engineering. The chief architect (in collaboration with the CIO, steering
committee, and the organization head) is instrumental in obtaining
organizational buy- in for EA (including support from the business units),
as well as in securing resources to support architecture management
functions, such as risk management, configuration management, quality
assurance, and security management.
Reference: CIO Council Practical Guide, Section 3.2.4: Appoint Chief
Architect
Element: EA is being developed using a framework, methodology, and
automated tool.
To develop the architecture in a consistent and efficient manner, an
organization should use an EA framework, methodology, and automated tool.
Frameworks provide a defined structure and nomenclature for representing
EA information that may come from different parts of the organization.
Methodologies, if implemented effectively, define the
steps necessary to perform the activities associated with capturing the EA
in a coherent, consistent, accountable, and repeatable manner. Automated
tools provide an efficient repository for capturing, updating, and
disseminating the EA across the organization.
Reference: CIO Council Practical Guide, Section 4: Define an Architecture
Process and Approach
Framework. A framework provides a formal structure for representing the
EA, serving as the basis for the nature and content of the specific
products the organization plans to develop, use, and maintain. As such, a
framework helps to ensure the consistent representation of information
from across the organization. For federal agencies, selecting one of the
federal frameworks provides greater interoperability among EAs of various
federal organizations.
Reference: CIO Council Practical Guide, Section 4.5: Evaluate and Select a
Framework Methodology. A methodology provides a common set of procedures
for developing EA products and, if implemented properly, helps to ensure
consistency in the procedures used across the organization for developing
and maintaining the EA. An organization*s methodology or methodologies
should govern how the EA products will be developed, maintained, and
validated. Methodologies need to be documented, understood, and
consistently applied by the EA program team. They should prescribe the
standards, steps, tools, techniques, and measures to be used to provide
reasonable assurance that expected product quality is attained.
Page 14 GAO- 03- 584G Enterprise Architecture Management Automated tool.
An automated tool serves as the repository of architecture artifacts. The
choice of tool is based on the organization*s needs and the size and
complexity of the
architecture. EA tools are typically selected based on explicit criteria,
including but not limited to those listed in table 1.
Reference: CIO Council Practical Guide, Section 4.6: Select an EA Toolset
Table 1. Criteria for Selecting Automated EA Development and Maintenance
Tools Available platforms Configuration management support Cost and
licensing Framework support Integrated and consolidated repository
Interoperability with other tools/ repositories Model size and complexity
Modeling methods and techniques support Risk management and issue tracking
support Quality assurance support Traceability to requirements and other
enterprise engineering artifacts Training schedule, cost, and length
Vendor support Source: CIO Council. Attribute: Demonstrates satisfaction
of commitment Element: EA plans call for describing both the *as- is* and
the *to- be* environments of the
enterprise as well as a sequencing plan for transitioning from the *as-
is* to the *tobe.*
An organization should have a documented EA program management plan and
supporting plans (e. g., configuration management plan and quality
assurance plan). Generally, these plans should describe the steps to be
taken and tasks to be performed in managing the EA program. They should
also provide for development of architectural descriptions of how the
organization currently operates (the *as- is* environment), how it intends
to operate in the future (the *to- be* environment), and how it will
transition from the current *as- is* operating environment to the *to- be*
environment. In short, the *as- is* and * to- be* descriptions should be
enterprisewide in scope, and they can be developed concurrently. Further,
it is expected that the *to- be* descriptions will consume the majority of
the EA program*s resources. The sequencing plan will generally follow
after development of the *as- is* and *to- be* descriptions, and it should
include, for example,
what system capabilities are to be introduced into the organization, when
they are to be introduced (based on their relative value and
dependencies), and when legacy systems are to be phased out. The
sequencing plan should eventually form the basis for the organization*s
annual IT capital investment plan, which is a key component of IT
investment management. Reference: CIO Council Practical Guide, Section
3.3.2: Develop an EA Program
Management Plan
Page 15 GAO- 03- 584G Enterprise Architecture Management Element: EA plans
call for describing both the *as- is* and the *to- be* environments in
terms of business, performance, information/ data, application/ service,
and technology.
The organization*s documented EA management plans should also provide for
defining and normalizing 21 the current and future architectures in terms
relevant to stakeholders from varying organization levels and disciplines.
These terms are the organization*s business operations, performance
measures, information and data needs and definitions, application and
service delivery means, and technology profiles and standards. Moreover,
these terms or enterprise perspectives should be consistent and aligned
with each other. (See Section 1 for more information on these terms of
reference.)
Reference: CIO Council Practical Guide, Section 3.3.2: Develop an EA
Program Management Plan
Element: EA plans call for business, performance, information/ data,
application/ service, and technology descriptions to address security.
An organization*s EA program management plans should define how it will
address security as a distinct area of operational and technology emphasis
within the context of each of the terms of reference: business,
performance, information/ data, application/ service, and technology.
Reference: CIO Council Practical Guide, Section 3.3.2: Develop an EA
Program
Management Plan Attribute: Verifies satisfaction of commitment
Element: EA plans call for developing metrics for measuring EA progress,
quality, compliance, and return on investment.
An organization*s EA management plans should provide for developing
metrics and should describe how these will be used to measure (1) progress
toward EA goals, (2) the quality of architecture products and management
processes, (3) compliance with the architecture, and (4) EA return on
investment.
21 Normalization is a process for minimizing the number of redundancies
among design or architecture groupings or entities. Designs or
architectures that have normalized groupings or entities are better able
to accommodate and minimize the impact of future change.
Page 16 GAO- 03- 584G Enterprise Architecture Management Elements Added
for Stage 3: Developing EA Products Stage 3: Developing EA products Stage
2 Stage 1 Attribute 1: Demonstrates commitment Written and approved
organization policy exists for EA development. Attribute 2: Provides
capability to meet commitment EA products are under configuration
management.
Attribute 3: Demonstrates satisfaction of commitment EA products describe
or will describe both the *as- is* and the *to- be* environments of the
enterprise, as well as a sequencing plan for transitioning from the *as-
is* to the *to- be.* Both the *as- is* and the *to- be* environments are
described or will be described in terms of business, performance,
information/ data, application/ service, and
technology. Business, performance, information/ data, application/
service, and technology descriptions address or will address security.
Attribute 4: Verifies satisfaction of commitment Progress against EA plans
is measured and reported. Source: GAO.
At Stage 3, organizations move from building the EA management foundation
to developing EA products. Stage 3 also includes all elements in Stage 2.
Attribute: Demonstrates commitment Element: Written and approved
organization policy exists for EA development. An organization should have
a documented policy, approved by the organization head, governing the
development of the EA. An organization policy is an important means for
ensuring enterprisewide commitment to developing an EA and for clearly
assigning responsibility for doing so. The architecture policy should
define the scope of the
architecture as including a description of the baseline (* as- is*) and
target (* to- be*) architecture, as well as a sequencing plan that
supports the move between the two. Additionally, the policy should provide
for having processes for EA oversight and control, and EA review,
validation, and refinement.
Further, the policy should identify the major players in the architecture
development process, including the chief architect, program office,
steering committee, project/ system development managers, the organization
head, and CIO; it should also identify their roles, responsibilities, and
relationships. The policy should address the purpose and value of an EA;
its relationship to the organization*s strategic vision and plans; and its
relationship to capital planning, enterprise engineering, and program
management.
Reference: CIO Council Practical Guide, Section 3.1.2: Issue an Executive
Enterprise Architecture Policy
Page 17 GAO- 03- 584G Enterprise Architecture Management Attribute:
Provides capability to meet commitment Element: EA products are under
configuration management.
An organization should ensure the integrity and consistency of the EA
products, throughout their life cycles, by placing them under
configuration management. Effective configuration management is important
for enabling integration among related EA products and for alignment
between architecture artifacts. Ensuring that EA products are under
configuration management is the responsibility of the EA program office.
Typically, an organization will assign a configuration manager to oversee
and control the EA product configurations. Through effective configuration
management, changes to EA
products are identified, tracked, monitored, documented, reported, and
audited.
Reference: CIO Council Practical Guide, Section 7: Maintain the Enterprise
Architecture Attribute: Demonstrates satisfaction of commitment Element:
EA products describe or will describe both the *as- is* and the *to- be*
environments of the enterprise, as well as a sequencing plan for
transitioning from the *as- is* to
the *to- be.*
Consistent with the EA program plans discussed in Stage 2, an organization
should ensure that the EA products being developed are enterprisewide in
scope and describe both the current (* as- is*) environment and the future
or target (* to- be*) environment, as well as a sequencing plan for moving
from the current to the target environment. Reference: CIO Council
Practical Guide, Section 5.2: Generate Products and Populate
EA Repository; Section 5.2.1: Essentials in Building the Baseline
Architecture; Section 5.2.2: Essentials in Building the Target
Architecture; Section 5.3: Develop the Sequencing Plan
Element: Both the *as- is* and the *to- be* environments are described or
will be described in terms of business, performance, information/ data,
application/ service, and technology.
While many details of the EA product may not yet have been defined, the
products being developed/ drafted should begin to address each of the
given terms of reference, or include placeholders for later defining the
enterprise in these terms. These terms of reference are business
operations, performance management, information/ data needs and
definitions, application/ service delivery vehicles, and technology
profiles and standards.
Reference: CIO Council Practical Guide, Section 5.2.1: Essentials in
Building the Baseline Architecture; Section 5.2.2: Essentials in Building
the Target Architecture
Page 18 GAO- 03- 584G Enterprise Architecture Management Element:
Business, performance, information/ data, application/ service, and
technology descriptions address or will address security.
An organization should ensure that each of its EA products (including
those describing the *as- is* and *to- be* environments in terms of
business, performance, information/ data, application/ service, and
technology) explicitly describe how enterprise security is being defined
and will be implemented.
Reference: CIO Council Practical Guide, Section 5.2.1: Essentials in
Building the Baseline Architecture; Section 5.2.2: Essentials in Building
the Target Architecture Attribute: Verifies satisfaction of commitment
Element: Progress against EA plans is measured and reported.
To assist in attaining stated EA program goals and objectives, an
organization should understand and disclose its progress against plans. As
EA products emerge, their content should be assessed against the plans to
ensure that expectations are being met. Based on this assessment, plans
can be updated to reflect experience to date, while products can be
revised to address plan changes. Deviations from expectations contained in
plans should be analyzed to determine cause and impact, and appropriate
action should be taken to address deviations.
Reference: CIO Council Practical Guide, Section 8.2: Identify Where EA
Program Expectations Are Not Being Met; Section 8.3: Take Appropriate
Actions to Address Deviations; Section 8.4: Ensure Continuous Improvement
Page 19 GAO- 03- 584G Enterprise Architecture Management Elements Added
for Stage 4: Completing the EA Products Stage 4: Completing EA products
Stage 1 Stage 2
Stage 3 Attribute 1: Demonstrates commitment Written and approved
organization policy exists for EA maintenance.
Attribute 2: Provides capability to meet commitment EA products and
management processes undergo independent verification and validation.
Attribute 3: Demonstrates satisfaction of commitment EA products describe
both the *as- is* and the *to- be* environments of the enterprise, as well
as a sequencing plan for transitioning from the *as- is* to the *to- be.*
Both the *as- is* and the *to- be* environments are described in terms of
business, performance, information/ data, application/ service, and
technology. Business, performance, information/ data, application/
service, and technology descriptions address security. Organization CIO
has approved current version of EA. Committee or group representing the
enterprise or the investment review
board has approved current version of EA. Attribute 4: Verifies
satisfaction of commitment Quality of EA products is measured and
reported. Source: GAO.
At Stage 4, organizations move from developing to completing EA products.
Stage 4 also includes all elements in Stages 3 and 2. Attribute:
Demonstrates commitment Element: Written and approved organization policy
exists for EA maintenance. Because the architecture is a *living* entity,
influenced continuously by internal and
external change drivers, it needs to be kept current to be relevant.
Accordingly, an organization should have a documented policy, approved by
the organization head, governing the maintenance of the EA. Such a policy
promotes enterprisewide commitment to keeping the EA up to date by, for
example, assigning responsibility and accountability for maintenance. The
EA policy should provide for establishing a process for architecture
maintenance, including oversight and control. Additionally, it should
identify the roles, responsibilities, and relationships of key players in
the maintenance process, including the chief architect, steering
committee, program office, project/ system
development managers, organization head, and CIO. Reference: CIO Council
Practical Guide, Section 3.1.2: Issue an Executive Enterprise Architecture
Policy
Page 20 GAO- 03- 584G Enterprise Architecture Management Attribute:
Provides capability to meet commitment Element: EA products and management
processes undergo independent verification and validation.
An organization should ensure the quality of its architecture by
performing independent verification and validation of both the EA products
and the processes used to develop the products. This independent quality
determination should be performed by a third party, such as the
organization*s internal audit function or a contractor not responsible for
any architecture development activities. The results of these
determinations should be shared with the program office, and reported
directly to the EA steering committee. Reference: CIO Council Practical
Guide, Section 3.2.5. 1: Appoint Key Personnel; Section 5.2.3: Review,
Validate, and Refine Models; Section 8.2: Identify Where EA
Program Expectations Are Not Being Met Attribute: Demonstrates
satisfaction of commitment Element: EA products describe both the *as- is*
and the *to- be* environments of the
enterprise, as well as a sequencing plan for transitioning from the *as-
is* to the *tobe.*
An organization should complete its EA products according to plans defined
in Stage 2. These products should completely and correctly describe both
the *as- is* and the *to- be* environments of the enterprise and include a
sequencing plan for migrating the organization between these two
environments. EA products exhibiting these characteristics and qualities
are a logical output of performing the previously discussed core elements.
This is a consequence of the hierarchical structure of the EAMMF. That is,
if the EA plans developed in Stage 2 and implemented in Stage 3 do not
provide for
having the *as- is* and *to- be* architectures and a sequencing plan, this
core element is unlikely to be satisfied in Stage 4.
Reference: CIO Council Practical Guide, Section 5.2: Generate Products and
Populate EA Repository; Section 5.2.1: Essentials in Building the Baseline
Architecture; Section 5.2.2: Essentials in Building the Target
Architecture; Section 5.3: Develop the Sequencing Plan
Element: Both the *as- is* and the *to- be* environments are described in
terms of business, performance, information/ data, application/ service,
and technology.
An organization*s EA products are defined and normalized in terms
meaningful to a wide variety of stakeholders, ranging from the
organization*s chief executive officer and strategic planners to its
technology implementers and operators. Accordingly, the *as- is* and the
*to- be* architectures need to capture and disclose in meaningful terms
business operations, performance measures, information and data needs and
definitions, application and service delivery vehicles, and technology
profiles and standards. Moreover, these terms set frames of reference that
need to be aligned and
Page 21 GAO- 03- 584G Enterprise Architecture Management consistent with
one another. Again, performance of the core elements in the previous
stages should result in architecture products that satisfy this core
element.
Reference: CIO Council Practical Guide, Section 5.2.1: Essentials in
Building the Baseline Architecture; Section 5.2.2: Essentials in Building
the Target Architecture Element: Business, performance, information/ data,
application/ service, and technology
descriptions address security.
An organization should explicitly and consistently address security in its
business, performance, information/ data, application/ service, and
technology EA products. Because security permeates every aspect of an
organization*s operations, the nature and substance of institutionalized
security requirements, controls, and standards should be captured in the
EA products.
Reference: CIO Council Practical Guide, Section 5.2.1: Essentials in
Building the Baseline Architecture; Section 5.2.2: Essentials in Building
the Target Architecture Element: Organization CIO has approved current
version of EA.
The current version of the organization*s completed EA should be approved
by the CIO. This approval is the first in a series of approvals intended
to establish the EA as an institutionally endorsed change management and
transformation tool.
Reference: CIO Council Practical Guide, Section 5.4: Approve, Publish, and
Disseminate EA Products
Element: Committee or group representing the enterprise or the investment
review board has approved current version of EA.
The current version of the organization*s completed architecture should
also be approved either by the EA steering committee (or comparable body)
or by the investment review board. The approval by one or both of these
bodies denotes institutional buy- in and thus facilitates the
architecture*s acceptance and use at all organizational levels as a change
management and transformation tool.
Reference: CIO Council Practical Guide, Section 5.4: Approve, Publish, and
Disseminate EA Products
Attribute: Verifies satisfaction of commitment Element: Quality of EA
products is measured and reported.
An organization should ensure that the nature and content of the EA
products meet defined quality standards. The ability to demonstrate that
these products are of high quality is critical to gaining CIO and
subsequent EA approvals. This core element entails
developing a set of metrics and assessing the products against those
metrics. Such measurement and disclosure of the results to decision-
makers mean that timely and appropriate actions can be taken to address
deviations from established goals. This
Page 22 GAO- 03- 584G Enterprise Architecture Management measurement and
reporting activity is the responsibility of the EA program, supplemented
by an independent verification and validation agent.
Reference: CIO Council Practical Guide, Section 3.2.5. 1: Appoint Key
Personnel; Section 5.2.3: Review, Validate, and Refine Models; Section
8.2: Identify Where EA Program Expectations Are Not Being Met; Section
8.3: Take Appropriate Actions to Address Deviations; Section 8.4: Ensure
Continuous Improvement
Elements Added for Stage 5: Leveraging the EA to Manage Change
Stage 1 Stage 2
Stage 3 Stage 4
Stage 5: Leveraging the EA to manage change Attribute 1: Demonstrates
commitment Written and approved organization policy exists for IT
investment compliance with EA.
Attribute 2: Provides capability to meet commitment Process exists to
formally manage EA change. EA is integral component of IT investment
management process. Attribute 3: Demonstrates satisfaction of commitment
EA products are periodically updated. IT investments comply with EA.
Organization head has approved current version of EA.
Attribute 4: Verifies satisfaction of commitment Return on EA investment
is measured and reported. Compliance with EA is measured and reported.
Source: GAO. Note: each stage includes all elements of previous stages. At
Stage 5, organizations use the EA products in a manner to most effectively
achieve
results, such as business and systems modernization and organizational
transformation. Stage 5 includes all elements in Stages 4, 3, and 2.
Attribute: Demonstrates commitment Element: Written and approved
organization policy exists for IT investment compliance with
EA.
An organization should have a policy governing the implementation of the
architecture that is approved by the organization head. Such a policy is
important because it is the basis for enforcing the architecture. The EA
policy should augment architecture development and maintenance policies by
providing for an institutional EA implementation process that is aligned
with the organization*s capital planning and investment control process.
At a minimum, the policy should specify that all IT investments must
comply with the architecture unless justified and granted a documented
waiver. The policy should also define the roles and responsibilities of
the major players
Page 23 GAO- 03- 584G Enterprise Architecture Management in architecture
implementation and their relationships. Major players include the
investment review board, architecture assessment team, CIO, and chief
architect.
Reference: CIO Council Practical Guide, Section 3.1.2: Issue an Executive
Enterprise Architecture Policy; Section 6.1.2: Establish Enforcement
Processes and Procedures Attribute: Provides capability to meet commitment
Element: A process exists to formally manage EA change. The EA is not a
static set of products, but rather a living tool that should change to
reflect, for example, new technology opportunities and shifts in
organizational constraints and business drivers. Accordingly, a formal
process should be defined and implemented for introducing changes to the
architecture. This process should recognize both internally and externally
prompted change, and it should provide for continuous capture and
analysis of change proposals and informed decision- making about whether
to make changes.
Reference: CIO Council Practical Guide, Section 7.1.1: Reassess the
Enterprise Architecture Periodically; Section 7.2: Continue to Consider
Proposals for EA Modification
Element: EA is integral component of IT investment management process. An
organization should recognize that the EA is a critical frame of reference
for making IT investment decisions. Using the EA when making investment
decisions is important because the organization should approve only those
investments that move the organization toward the target architecture, as
defined in the sequencing plan.
Our ITIM framework also addresses architecture within the context of
ITIM*s five stages of investment management maturity. 22 For example, at
ITIM stage 2, an organization*s policies and procedures should provide for
identifying the business needs (and the associated users) of each IT
project and for ensuring that each IT project fits within the architecture
(or be waived from this requirement). The business needs are typically
contained in the EA business descriptions.
At ITIM stage 3, an organization*s policies and procedures should provide
for
specifying the relationship of its architecture to its IT decision- making
authority; specifying the link between the EA and IT portfolio selection
criteria, which should take into account the EA so as to (1) avoid
unwarranted overlap across investments and (2) maximize systems
interoperability; and
reconciling differences between the organization*s EA and its IT
investment portfolio. 22 U. S. General Accounting Office, Information
Technology Investment Management: A Framework for Assessing and Improving
Process Maturity, Exposure Draft, GAO/ AIMD- 10.1.23 (May 2000).
Page 24 GAO- 03- 584G Enterprise Architecture Management At ITIM stage 4,
the organization should periodically analyze its IT investment portfolio
to ensure that its investments of IT resources are aligned with the
current version of the
architecture.
Reference: CIO Council Practical Guide, Section 6.1: Integrate the EA with
Capital Planning and Investment Control and System Lifecycle Processes
Attribute: Demonstrates satisfaction of commitment Element: EA products
are periodically updated.
Depending on the volume and degree of approved changes to the EA, an
organization will need to periodically update its EA products. These
updates generally reflect an accumulation of individually minor changes
that (taken as a whole) represent a material change in the products.
Reference: CIO Council Practical Guide, Section 7.1.1: Reassess the
Enterprise Architecture Periodically Element: IT investments comply with
EA.
An organization*s IT investments should be aligned and comply with the
applicable components (e. g., business, information/ data, and technical)
of the current version of the EA, and should not be selected and approved
under the organization*s capital planning and investment control process
unless compliance is documented by the investment
sponsor and substantiated by the architect assessment team. Moreover, this
compliance is not a one- time event, but rather an integral part of the
investment control process and the system life cycle management process.
Exceptions to investments being architecturally compliant should be made
only on the basis of compelling analytical justifications and
should be documented in a waiver to the architecture. These waivers then
form the basis for articulating change requests under the formal process
for introducing change in the EA.
Reference: CIO Council Practical Guide, Section 6.1: Integrate the EA with
Capital Planning and Investment Control and System Lifecycle Processes
Element: Organization head has approved current version of the EA.
The current version of the EA should ultimately be approved by the head of
the organization. Such approval recognizes and endorses the architecture
for what it is intended to be* a corporate tool for managing both business
and technological change and transformation. Reference: CIO Council
Practical Guide, Section 5.4: Approve, Publish, and
Disseminate EA Products
Page 25 GAO- 03- 584G Enterprise Architecture Management Attribute:
Verifies satisfaction of commitment Element: Return on EA investment is
measured and reported.
The EA is a strategic asset and, as such, should be viewed as an
investment in the future. Like any investment, the EA should produce a
return (i. e., a set of benefits), and this return on investment should be
measured and reported in relation to costs. Measuring return on investment
is important to ensure that expected benefits from the EA are
realized and to share this information with executive decision- makers,
who can then take corrective action to address deviations from
expectations. To accomplish this, metrics need to be developed (such as
costs avoided through elimination of duplicative or redundant investments)
and processes need to be established to collect and report these data.
Reference: CIO Council Practical Guide, Section 8.2: Identify Where EA
Program Expectations Are Not Being Met; Section 8.3: Take Appropriate
Actions to Address Deviations; Section 8.4: Ensure Continuous Improvement
Element: Compliance with EA is measured and reported. Unless the EA is
enforced, its value will not be fully realized. Thus, it is not only
important to have a process in place to ensure compliance (as described in
an earlier core element), it is also important to measure and report on
the extent of compliance. To do so effectively, organizations should
define metrics, such as number of compliance waivers requested and number
granted, to track compliance. Through such measurement and reporting,
relevant trends and anomalies can be identified, and corrective action can
be taken. Reference: CIO Council Practical Guide, Section 6.1: Integrate
the EA with Capital
Planning and Investment Control and System Lifecycle Processes
Page 26 GAO- 03- 584G Enterprise Architecture Management Overall View of
EAMMF Matrix Figure 6 depicts all the core elements and relates them to
the applicable stages of maturity and critical success attributes.
Page 27 GAO- 03- 584G Enterprise Architecture Management Figure 6: Summary
of EAMMF Version 1.1: Maturity Stages, Critical Success Attributes, and
Core Elements Stage 1: Creating
EA awareness Stage 2:
Building the EA management foundation Stage 3:
Developing EA products Stage 4: Completing EA products Stage 5:
Leveraging the EA to manage change Attribute 1: Demonstrates commitment
Adequate resources exist. Committee or group representing the enterprise
is responsible for directing, overseeing, or approving EA. Written and
approved
organization policy exists for EA development. Written and approved
organization policy exists for EA maintenance. Written and approved
organization policy exists for IT investment compliance with EA.
Attribute 2: Provides capability to meet commitment
Program office responsible for EA development and maintenance exists.
Chief architect exists. EA is being developed using a framework,
methodology, and
automated tool. EA products are under configuration management. EA
products and management processes undergo independent verification and
validation. Process exists to formally manage EA change. EA is integral
component of IT investment management process. Attribute 3:
Demonstrates satisfaction of commitment
EA plans call for describing both the *as- is* and the *to be*
environments of the enterprise, as well as a sequencing plan for
transitioning from the *as- is*
to the *to- be.* EA plans call for describing both the *as- is* and the
*to be* environments in terms of business, performance, information/ data,
application/ service, and
technology. EA plans call for business, performance, information/ data,
application/ service, and technology descriptions to address security. EA
products describe or
will describe both the *as is* and the *to- be* environments of the
enterprise, as well as a sequencing plan for transitioning from the *as
is* to the *to- be.* Both the *as- is* and the *to- be* environments are
described or will be described in terms of business, performance,
information/ data, application/ service, and
technology. Business, performance, information/ data, application/
service, and technology descriptions address or will address security.
EA products describe both the *as- is* and the *to- be* environments of
the enterprise, as well as a sequencing plan for
transitioning from the *as is* to the *to- be.* Both the *as- is* and the
*to- be* environments are described in terms of business, performance,
information/ data, application/ service, and technology. Business,
performance, information/ data, application/ service, and technology
descriptions address security. Organization CIO has approved current
version
of EA. Committee or group representing the enterprise or the
investment review board has approved current version of EA.
EA products are periodically updated. IT investments
comply with EA. Organization head has approved current version of EA.
Attribute 4:
Verifies satisfaction of commitment
EA plans call for developing metrics for measuring EA progress, quality,
compliance, and return on investment. Progress against EA plans is
measured and reported. Quality of EA products is measured and reported.
Return on EA investment is measured and
reported. Compliance with EA is measured and reported. maturation Source:
GAO. Note: each stage includes all elements of previous stages.
Page 28 GAO- 03- 584G Enterprise Architecture Management Section 3. Uses
of EAMMF Version 1.1 Potential users of the EAMMF include both internal
and external stakeholders of a given
enterprise. For federal agencies, primary internal stakeholders are agency
senior executives, including the agency head, as well as the CIO and chief
architect and their staffs. Primary external stakeholders are those with
agency oversight responsibilities, such as parent departments, OMB, and
congressional committees, as well as independent audit and evaluation
organizations.
As a model defining ascending levels of EA management maturity, the EAMMF
can be used by these stakeholders in two principal ways. First, the
framework can be used to provide a set of benchmarks against which to
determine where the enterprise stands in its progress toward the ultimate
goal: having architecture management capabilities that effectively
facilitate institutional change (maturity Stage 5). Second, the framework
can
be used as the high- level basis for developing specific architecture
management improvement plans, as well as for measuring, reporting, and
overseeing progress in implementing these plans. Tool for Assessing EA
Management Maturity By describing the elements of an effective EA
management program, the EAMMF provides a benchmarking tool for judging an
enterprise*s efforts to manage architecture
development and use. Moreover, because the core elements of this framework
are grounded in the CIO Council*s Practical Guide, a tool that has been
widely accepted across the federal government, some agencies have adopted
the EAMMF as a de facto standard for measuring EA management maturity.
Using the contents of the EAMMF as criteria, internal and external
stakeholders can
assess and consistently represent a given enterprise*s EA management
strengths and weaknesses at a single point in time or over a period of
time. Moreover, groups of enterprises can be assessed, represented, and
compared. As a result, the framework
enables users to identify and understand these strengths and weaknesses in
a range of contexts: not only specific to a particular enterprise, but
also across a group of related enterprises, such as a given department*s
component agencies, all independent federal agencies, or sets of federal
agencies, such as those that are of a particular size or that share a
common mission (e. g., homeland security). When using the EAMMF as an
assessment benchmarking tool, it is important to
remember that achieving a given stage of management maturity requires the
enterprise to satisfy all core elements at that stage, as well as those
for each lower stage. The value of the EAMMF, however, goes beyond merely
grading a given entity as being at a particular stage. It also extends to
identifying the full range of specific strengths and weaknesses of
Page 29 GAO- 03- 584G Enterprise Architecture Management the enterprise*s
EA management practices (i. e., which core elements are satisfied and
which are not). This knowledge allows a given enterprise to build on its
collective
strengths in addressing its recognized weaknesses. Additionally, the EAMMF
allows its users to assess and understand any enterprise, regardless of
whether the enterprise is an entire organization (e. g., a federal
department) or a component organization (e. g., a branch, bureau, or
agency). That is, the EAMMF, like the CIO Council Practical Guide, is
enterprise independent. The key consideration, however, is that the unit
or scope of assessment needs to be clearly understood and defined before
an EAMMF- based assessment is conducted.
The amount and depth of the assessment against the EAMMF can vary,
depending on the purpose of the assessment and the needs of its users.
Accordingly, the EAMMF does not include a methodology or approach for
applying the framework; for example, it leaves up to the users the extent
to which they verify and validate that each core element is satisfied.
EA Management Improvement Planning The progressive stages of the EAMMF
provide a roadmap for incremental improvement of architecture management.
In using this roadmap for planning, it is important to recognize that
certain core elements are inherently dependent on others, requiring an
ordered approach, whereas others do not exhibit such dependencies, so that
the timing of their implementation is more flexible.
Generally, lower EAMMF maturity stages provide the foundation for higher
maturity stages. Some lower stage core elements serve as prerequisites for
higher stage core elements. For example, EA plans established in Stage 2
serve as a prerequisite for measuring progress against those plans in
Stage 3. However, certain higher stage core elements can be addressed,
even though lower stage
core elements have not been completely addressed. For example, an
organization may have satisfied the Stage 5 core element of having a
written and approved policy for EA maintenance without satisfying lower
level core elements. Our use of the EAMMF has shown that it is not unusual
for federal departments and agencies to have satisfied some core elements
at multiple stages, even though not all have been addressed. Additionally,
in using the EAMMF for improvement planning, it is important to
remember that the framework, like the CIO Council Practical Guide,
describes what needs to be done, not how it needs to be done. Thus, when
the EAMMF is used for management improvement, the framework remains just
that: a framework within which to plan specific EA management steps,
activities, processes, authorities, etc., and to subsequently measure,
report, and oversee progress on each. To develop an EA management
improvement plan that can be actually implemented, an enterprise needs to
augment the framework with more detailed criteria, addressing, for
example, the appropriate scope of work of an independent verification and
validation agent or the attributes of an effective process for assessing a
given investment*s architectural compliance.
Page 30 GAO- 03- 584G Enterprise Architecture Management Further, in using
the EAMMF for improvement planning, it is also important to remember that
effective EA management is generally not achieved until an enterprise has
a completed and approved architecture that is being effectively maintained
and is being used to leverage organization change and support investment
decision- making; having an architecture with these characteristics is
equivalent to having satisfied many Stage 4 and 5 core elements. At this
point in the organization*s EA management maturation, management controls
and structures are in place for using an approved architecture to guide
and constrain its investments in IT. Even if an enterprise is at Stage 4,
it is not fully exploiting an architecture unless it is also achieving
certain Stage 5 core elements, such as having processes that use the EA in
managing the IT investment portfolio and that
ensure that IT investments comply with the EA. If these core elements are
not in place, the EA will not be a tool for managing IT for institutional
results.
Page 31 GAO- 03- 584G Enterprise Architecture Management Appendix.
Approach to Developing EAMMF Version 1.1 Our primary goal in developing
EAMMF Version 1.1 was to improve the content and
usability of Version 1.0. To do this, we solicited comments and
suggestions on Version 1.0 from the 116 federal departments and agencies
that participated in our 2001 survey of the state of the government*s use
of enterprise architectures, 23 as well as various other internal and
external EA stakeholders, such as members of a GAO- sponsored IT
management advisory group composed of IT executives from private industry,
academia, and state governments.
In our 2001 survey of federal departments and agencies, we solicited
responses to a questionnaire addressing various EA management topics, and
we compared these responses to EAMMF Version 1.0. This comparison showed
that 84 percent of the departments and agencies were at maturity stage 1
or 2. Therefore, as a secondary goal in developing Version 1.1, we wanted
to avoid invalidating the baseline data obtained in the 2001 survey on the
state of EA management in the federal government. Accordingly, in
soliciting comments and suggestions from the 116 departments and agencies
and various other EA stakeholders, we were mindful to balance the need to
introduce missing core elements with the need not to significantly raise
the bar for being at Stage 2. To this end,
we asked that comments and suggestions for adding core elements be focused
on Stages 4 and 5, but we did not restrict any comments and suggestions
for the framework. Other areas that we sought respondents* input on were
experience with using the framework; strengths and/ or weaknesses of the
framework; and
ways to improve the framework:
to make it more useful as a tool to define and measure an organization*s
EA management maturity,
to ensure that the staged structure (and the corresponding core elements)
of the framework is not unreasonably demanding, and
to explain the core elements sufficiently so that they are useful in
assessing an agency*s enterprise architecture maturity.
Of the 116 departments and agencies we contacted, 63 responded.
Collectively, they provided about 300 comments and suggestions that we
have incorporated as appropriate in Version 1.1. We categorized these
comments and suggestions into the eight groups shown in table 2. 23 U. S.
General Accounting Office, Information Technology: Enterprise Architecture
Use Across the Federal Government Can Be Improved, GAO- 02- 6 (Washington,
D. C.: February 2002).
Page 32 GAO- 03- 584G Enterprise Architecture Management Table 2. Major
Categories of Comments and Suggestions 1. Link core elements to other
relevant guidance (e. g., CIO Council Practical Guide, EA Frameworks) 2.
Include EA development, maintenance, and implementation 3. Include EA
return on investment 4. Add core elements for measuring EA progress 5.
Include security 6. Include maturity half- stages based on number of core
elements satisfied (e. g., Stage
1.5 for satisfying more than half but less than all of the core elements
in Stage 2) 7. Better define EAMMF 8. Comments requiring no change Source:
GAO.
(310240)
*** End of document. ***