Management Information Technology
Resume:
United States Government Accountability Office
GAO Executive Guide
August 2010
ORGANIZATIONAL
TRANSFORMATION
A Framework for
Assessing and
Improving Enterprise
Architecture
Management
(Version 2.0)
GAO-10-846G
August 2010
ORGANIZATIONAL TRANSFORMATION
Accountability Integrity Reliability
Highlights A Framework for Assessing and Improving Enterprise
Architecture Management (Version 2.0)
Highlights of GAO-10-846G, an executive
guide
Why GAO Did This Study What GAO Found
Effective use of an enterprise The framework consists of three interrelated components: (1) seven
architecture (EA) is a hallmark of hierarchical stages of management maturity; (2) four representations of
successful organizations and an management attributes that are critical to the success of any program or
essential means to achieving a organizational endeavor; and (3) 59 elements, or building blocks, of EA
desired end: having operations and management that are at the core of an EA program. (See the figure below for a
technology environments that
conceptual view of the framework s components.)
maximize institutional mission
performance and outcomes. Among
other things, this includes realizing Conceptual Depiction of the EAMMF s Interrelated Components
cost savings through consolidation
and reuse of shared services and 7 maturity stages
elimination of antiquated and
redundant mission operations, 4 critic
al
enhancing information sharing succes
s
59 core elements
attribute
through data standardization and represe
ntation
system integration, and optimizing s
service delivery through
Maturation
streamlining and normalization of
Source: GAO.
business processes and mission
operations. Not using an EA can
Each of the seven maturity stages reflects those EA management conditions
result in organizational operations
that an enterprise should meet to logically build on the capability established
and supporting technology
at the preceding stage. As such, the stages provide a road map for
infrastructures and systems that
are duplicative, poorly integrated, systematically maturing or evolving an organization s capacity to manage an
unnecessarily costly to maintain EA. The stages are: Stage 0: Creating EA Awareness; Stage 1: Establishing EA
and interface, and unable to Institutional Commitment and Direction; Stage 2: Creating the Management
respond quickly to shifting Foundation for EA Development and Use; Stage 3: Developing Initial EA
environmental factors. Versions; Stage 4: Completing and Using an Initial EA Version for Targeted
Results; Stage 5: Expanding and Evolving the EA and Its Use for Institutional
To assist organizations in
Transformation; Stage 6: Continuously Improving the EA and Its Use to
successfully developing,
Achieve Corporate Optimization.
maintaining, and using an EA, GAO
is issuing this major update to its
The four critical success attribute representations provide different and
Enterprise Architecture
complementary ways to view and thus understand the 59 core elements. The
Management Maturity Framework.
Its purpose is to provide a flexible four are referred to as the (1) EA Management Action Representation, (2) EA
benchmark against which to plan Functional Area Representation, (3) Office of Management and Budget
for and measure EA program Capability Area Representation, and (4) EA Enabler Representation. Each
maturity. To develop the update, provides a unique perspective on the focus and nature of the framework s
GAO solicited comments from 27 core elements.
federal departments and agencies,
as well as representatives from the
The 59 core elements are collectively the EA practices, structures, activities,
private sector, state governments,
and conditions that, when properly employed based on the unique facts and
and academia, and it leveraged its
circumstances of each organization and the stated purpose of its EA program,
prior experience in applying the
can permit that organization to progress to increasingly higher states of EA
framework.
management maturity and thereby maximize its chances of realizing an EA s
institutional value.
View GAO-10-846G or key components.
For more information, contact Randolph C.
Hite at 202-***-**** or *****@***.***.
United States Government Accountability Office
Contents
Preface 1
Section 1: Introduction 4
Section 2: Overview of EA Management Maturity Framework
Version 2.0 14
Section 3: Uses of EAMMF Version 2.0 40
Appendix I Approach to Developing EAMMF Version 2.0 43
Appendix II Framework Elements 45
Tables
Table 1: OMB EA Assessment Framework Capability Areas 9
Table 2: EA Management Action Representation of the Critical
Success Attributes and the Core Elements 24
Table 3: EA Functional Area Representation of the Critical Success
Attributes and the Core Elements 29
Table 4: OMB Capability Area Representation of the Critical
Success Attributes and the Core Elements 33
Table 5: EA Enabler Representation of the Critical Success
Attributes and the Core Elements 37
Table 6: Categories of Comments and Suggestions Provided for
Update of EAMMF Version 1.1 43
Table 7: Examples of EA Program Management Office Leadership
Positions 53
Table 8: Factors to Consider in Selecting EA Modeling and
Repository Tools 56
Figures
Figure 1: Simplified Three-Dimensional View of EAMMF 15
Figure 2: Conceptual Depiction of the EAMMF s Interrelated
Components 16
Figure 3: Generic EAMMF Matrix 17
Figure 4: EAMMF Overview with Seven Stages of Maturity
Identified 17
GAO-10-846G Executive Guide
Page i
Abbreviations
CIO chief information officer
CMMI Capability Maturity Model Integration
CXO chief X officer
DOD Department of Defense
DODAF Department of Defense Architecture Framework
EA enterprise architecture
EAMMF Enterprise Architecture Management Maturity Framework
ECIMT Executive Council for Information Management and
Technology
FEAF Federal Enterprise Architecture Framework
FEAPMO Federal Enterprise Architecture Program Management Office
IT information technology
ITIM Information Technology Investment Management
NIST National Institute of Standards and Technology
OMB Office of Management and Budget
OPM Office of Personnel Management
This is a work of the U.S. government and is not subject to copyright protection in the
United States. The published product 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 ii GAO-10-846G Executive Guide
United States Government Accountability Office
Washington, DC 20548
Effective use of a well-defined enterprise architecture (EA) is a hallmark
Preface of successful organizations and a basic tenet of organizational
transformation and systems modernization. Since the early 1990s, GAO
has promoted federal department and agency EA adoption as an essential
means to achieving a desired end: having operational and technology
environments that maximize institutional mission performance and
outcomes. 1 Among other things, this includes realizing cost savings
through consolidation and reuse of shared services and elimination of
antiquated and redundant mission operations, enhancing information
sharing through data standardization and system integration, and
optimizing service delivery through streamlining and normalization of
business processes and mission operations. The alternative, as GAO has
reported, is department and agency operations and supporting information
technology (IT) infrastructures and systems that are duplicative, poorly
integrated, unnecessarily costly to maintain and interface, and unable to
respond quickly to shifting environmental factors. 2
Managed properly, an EA can help simplify, streamline, and clarify the
interdependencies and relationships among an organization s diverse
mission and mission-support operations and information needs, including
its associated IT environment. When employed in concert with other
institutional management disciplines, such as strategic planning, portfolio-
based capital planning and investment control, and human capital
management, an EA can greatly increase the chances of configuring an
organization to promote agility and responsiveness, optimize mission
performance and strategic outcomes, and address new federal initiatives
like promoting open and participatory government and leveraging cloud
computing.
1
See, for example, GAO, Strategic Information Planning: Framework for Designing and
Developing System Architectures, GAO/IMTEC-92-51 (Washington, D.C.: June 1992).
2
See, for example, GAO, Homeland Security: Efforts Under Way to Develop Enterprise
Architecture, but Much Work Remains, GAO-04-777 (Washington, D.C.: Aug. 6, 2004); DOD
Business Systems Modernization: Limited Progress in Development of Business
Enterprise Architecture and Oversight of Information Technology Investments,
GAO-04-731R (Washington, D.C.: May 17, 2004); Information Technology: Architecture
Needed to Guide NASA s Financial Management Modernization, GAO-04-43 (Washington,
D.C.: Nov. 21, 2003); DOD Business Systems Modernization: Important Progress Made to
Develop Business Enterprise Architecture, but Much Work Remains, GAO-03-1018
(Washington, D.C.: Sept. 19, 2003); and Information Technology: DLA Should Strengthen
Business Systems Modernization Architecture and Investment Activities, GAO-01-631
(Washington, D.C.: June 29, 2001).
Page 1 GAO-10-846G Executive Guide
To assist federal departments and agencies in their efforts to develop,
maintain, and use an EA, we issued the first version of this framework
(version 1.0) in 2002, followed by a minor update (version 1.1) in 2003. 3 We
offer here the first major revision to the framework (version 2.0). This
update is based on our extensive use of version 1.1 in performing two
governmentwide and numerous department- and agency-specific EA
evaluations, as well as our solicitation of comments from departments and
agencies and other stakeholders on the usability, completeness, and
sufficiency of the framework as a tool to define and measure an
organization s EA management maturity. The update also incorporates
comments received from GAO s Executive Council on Information
Management and Technology (ECIMT) on version 1.1 and a draft of
version 2.0. 4
In summary, version 2.0 builds on the prior version by introducing
considerably more scope and content to accommodate the evolving and
complex nature of EA as one of many enterprise management disciplines
and the practical realities surrounding actual EA development and use. As
such, this version of the framework provides a more current and
pragmatic construct for viewing EA development and use. In this regard, it
provides a flexible benchmark against which to plan for and measure EA
program management maturity that permits thoughtful and reasonable
discretion to be applied in using it. Restated, the framework is not
intended to be a rigidly applied one size fits all checklist, but rather a
flexible frame of reference that should be applied in a manner that makes
sense for each organization s unique facts and circumstances. Moreover,
the framework is not intended to be viewed as the sole benchmarking tool
for informing and understanding an organization s journey toward EA
maturity.
3
GAO, Information Technology: Enterprise Architecture Use across the Federal
Government Can Be Improved, GAO-02-6 (Washington, D.C.: Feb. 19, 2002); Information
Technology: A Framework for Assessing and Improving Enterprise Architecture
Management (version 1.1), GAO-03-584G (Washington, D.C.: April 2003).
4
GAO s Executive Council on Information Management and Technology is composed of
senior-level officials from the public sector, private sector, and academia. Members include
former chief information officers for government agencies, professors of information
technology, presidents of private businesses, information technology consultants, and
representatives of the National Association of State Chief Information Officers.
Page 2 GAO-10-846G Executive Guide
Questions and comments about this framework should be directed to me
at 202-***-**** or at *****@***.***. Key contributors to this framework
were Nabajyoti Barkakati, Nancy Glover, Michael Holland, Neelaxi
Lakhmani (Assistant Director), Anh Le, Emily Longcore, Constantine
Papanastasiou, and Jennifer Stavros-Turner.
Randolph C. Hite
Director, Information Technology Architecture and Systems Issues
Page 3 GAO-10-846G Executive Guide
An EA provides a clear and comprehensive picture of the structure and
Section 1: substance of any purposeful activity, whether it is an organization (e.g., a
Introduction federal department or agency) or a functional or mission area that cuts
across organizational boundaries (e.g., terrorism information sharing or
homeland security). Accordingly, an EA is an essential tool for effectively
and efficiently engineering business or mission processes and for
implementing and evolving supporting systems.
The concept of using an architecture to describe an enterprise first
emerged in the mid-1980s, and over the years various frameworks for
defining the content of EAs have been published. 5 Our research in the
early 1990s identified the use of architectures as critical to an
organization s success in effectively applying 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 federal
departments and 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 a well-defined
architecture as a major management challenge, and we have made
numerous recommendations addressing this important area. 6
EA: A Brief Description An EA can be viewed as a blueprint for organizational transformation and
IT modernization. Generally speaking, it consists of snapshots of the
enterprise s current, or as-is, operational and technological environment
5
A framework can be viewed as a logical structure for classifying and organizing complex
information.
6
See, for example, GAO, Information Technology: HUD Needs to Strengthen Its Capacity
to Manage and Modernize Its Environment, GAO-09-675 (Washington, D.C.: July 31, 2009);
DOD Business Systems Modernization: Military Departments Need to Strengthen
Management of Enterprise Architecture Programs, GAO-08-519 (Washington, D.C., May
12, 2008); Federal Aviation Administration: Stronger Architecture Program Needed to
Guide Systems Modernization Efforts, GAO-05-266 (Washington, D.C.: Apr. 29, 2005);
GAO-04-777; GAO-04-731R; Information Technology: Architecture Needed to Guide
NASA s Financial Management Modernization, GAO-04-43 (Washington, D.C.: Nov. 21,
2003); Information Technology: Leadership Remains Key to Agencies Making Progress
on Enterprise Architecture Efforts, GAO-04-40 (Washington, D.C.: Nov. 17, 2003);
GAO-03-1018; GAO-03-877R; Information Technology: DLA Should Strengthen Business
Systems Modernization Architecture and Investment Activities, GAO-01-631
(Washington, D.C.: June 29, 2001); and Information Technology: INS Needs to Better
Manage the Development of Its Enterprise Architecture, GAO/AIMD-00-212 (Washington,
D.C.: Aug. 1, 2000).
Page 4 GAO-10-846G Executive Guide
and its target, or to-be, environment, and contains a capital investment
road map for transitioning from the current to the target environment.
These snapshots consist of views, which are basically one or more
architecture products that provide conceptual, logical, or physical
representations of the enterprise. Further, these views or representations
are not static, but rather will evolve and change over time, making the EA
a living document.
The genesis of EA as an organizational management discipline can be
traced to the mid-1980s. At that time, John Zachman, widely recognized as
a leader in the EA field, identified the need to use a logical construction
blueprint (i.e., an architecture) for defining and controlling the integration
of systems and their components. 7 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 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
taxonomy for identifying and describing 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 the development of Zachman s EA framework, various approaches
have emerged to develop and implement EAs. For example, the EA
product development methodology outlined by Steven Spewak in 1992
calls for the development of as-is architecture models before the
7
J. A. Zachman, A Framework for Information Systems Architecture, IBM Systems
Journal 26, no. 3 (1987).
Page 5 GAO-10-846G Executive Guide
development of detailed to-be models, followed by the development of a
plan for transitioning from the as-is to the to-be environment. 8
Overview of Federal EA Architecture guidance within the federal government can be traced to a
National Institute of Standards and Technology (NIST) publication in
Guidance and Legislation
1989. 9 Subsequently, we issued a guide 10 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. 11 Since that time, other federal entities have
issued frameworks for defining the content of EAs, including the federal
CIO Council, 12 the Department of the Treasury, 13 and the Department of
Defense (DOD). 14
In September 1999, the federal CIO Council published the Federal
Enterprise Architecture Framework (FEAF), which provided federal
agencies with a common construct for their architectures and thereby
facilitated the coordination of common business processes, technology
insertion, information flows, and system investments among federal
agencies. The FEAF, which has been essentially replaced by the Federal
Enterprise Architecture Program Management Office (FEAPMO) reference
models discussed below, defined a collection of interrelated models for
describing multi-organizational functional segments of the federal
government. Similar to the Zachman framework, the FEAF s models
covered business functions, data necessary to conduct the business
8
Steven H. Spewak with Steven C. Hill, Enterprise Architecture Planning: Developing a
Blueprint for Data, Applications, and Technology (Princeton, N.J.: John Wiley and Sons,
1992).
9
National Institute of Standards and Technology, Information Management Directions:
The Integration Challenge, Special Publication 500-167 (Gaithersburg, MD: September
1989).
10
GAO/IMTEC-92-51.
11
GAO, Executive Guide: Improving Mission Performance through Strategic Information
Management and Technology, GAO/AIMD-94-115 (Washington, D.C.: May 1994).
12
Federal Enterprise Architecture Framework, Version 1.1 (September 1999).
13
Treasury Enterprise Architecture Framework, Version 1.0 (July 3, 2000).
14
DOD, Department of Defense Architecture Framework, Version 2.0, Volumes I-III (May
2009).
Page 6 GAO-10-846G Executive Guide
functions, applications to manage the data, and technology to support the
applications.
In July 2000, the Department of the Treasury published the Treasury EA
Framework, which provides (1) guidance to Treasury bureaus concerning
the development and evolution of an architecture; (2) a unifying concept,
common principles, technologies, and standards for information systems;
and (3) a template for the development of the EA. According to the
department, it is to be used to guide the development and redesign of
bureau business processes. It consists of four architectural views
(functional, information, organizational, and infrastructure) and a set of
notional products to portray these views from four core perspectives
(planner, owner, designer, and builder).
In August 2003, DOD released version 1.0 of its DOD Architecture
Framework (DODAF), which defines the type and content of the
architectural artifacts, as well as the relationships among the artifacts. 15
DODAF version 2.0, released in May 2009, builds on the prior versions and
specifies a set of eight viewpoints all, capability, data and information,
operational, project, services, standards, and systems each of which
includes various architecture models that apply to DOD-, component-, and
program-level system architectures.
In 2002, OMB established the FEAPMO to develop a federal EA 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.
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.
15
DODAF was based on DOD s Command, Control, Communications, Computers, and
Intelligence, Surveillance, and Reconnaissance framework, developed by DOD in response
to the Clinger-Cohen Act of 1996.
Page 7 GAO-10-846G Executive Guide
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.
In addition to these frameworks governing the structure and content of
EAs, OMB, in collaboration with us, developed guidance on the
development and implementation of EAs. 16 Further, the federal CIO
Council collaborated with us in developing EA guidance focused on
assessing an IT investment s compliance with an EA, 17 as well as guidance
that addressed the end-to-end steps associated with developing,
maintaining, and implementing an EA program. 18 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 emergence of federal architecture guidance and frameworks over the
last 15 years is largely owing to the Congress s passage of the Clinger-
Cohen Act in 1996. This act, among other things, requires the CIOs for
major federal departments and agencies to develop, maintain, and
facilitate architectures as a means of integrating business processes and
16
OMB, Information Technology Architectures, Memorandum M-97-16 (June 18, 1997),
rescinded with the update of OMB Circular A-130 (Nov. 30, 2000).
17
Chief Information Officers Council, Architecture Alignment and Assessment Guide
(October 2000).
18
Chief Information Officers Council, A Practical Guide to Federal Enterprise
Architecture, Version 1.0 (February 2001).
Page 8 GAO-10-846G Executive Guide
agency goals with IT. 19 The E-Government Act of 2002 established the
OMB Office of Electronic Government and assigned it, among other things,
responsibilities for overseeing the development of EAs within and across
federal agencies. 20
In April 2004, OMB issued the first version of its EA Assessment
OMB s EA Assessment
Framework, and since then has issued multiple updates. 21 According to the
Framework
latest version of this framework (version 3.1), its purpose is to provide the
measurement areas and criteria for federal agencies to use in realizing EA-
driven performance improvements and outcomes (e.g., improving mission
performance; saving money and avoiding costs; enhancing the quality of
agency investment portfolios; improving the quality, availability and
sharing of data and information; and increasing the transparency of
government operations). To accomplish this, the framework uses key
performance indicators to assess EA maturity or effectiveness relative to
three capability areas completion, use, and results (see table 1 for a
description of these three capability areas).
Table 1: OMB EA Assessment Framework Capability Areas
Capability area Summary
Completion Measures agency completion of the current and target EA in terms of
performance, business, data, services, and technology as well as the
completion of the agency s enterprise transition plan.
Use Measures agency demonstration of EA awareness and establishment
of the necessary management practices, processes, and policies
needed for EA development, maintenance, and oversight. Also
measures agency EA use in strategic planning, information resources
management, IT management, and capital planning and investment
control processes.
Results Measures actual results attributed to the EA, and therefore the
effectiveness and value of its EA activities.
Source: OMB.
19
40 U.S.C. 11315.
20
44 U.S.C 3602(f)(14). The E-Government Act also provided a more detailed definition of
the concept and elements of enterprise architecture. See 44 U.S.C. 3601(4).
21
OMB, Improving Agency Performance Using Information and Information Technology
(Enterprise Architecture Assessment Framework v3.1) (June 2009).
Page 9 GAO-10-846G Executive Guide
Each capability area contains a set of key performance indicators and
associated outcomes, as well as criteria for gauging progress in meeting
the outcomes. For example, the Completion capability area is composed
of four key performance indicators: Target EA and Enterprise Transition
Plan, Architectural Prioritization, Scope of Completion, and Internet
Protocol Version 6. Each key performance indicator is scored on a 1-5
scale. For example, according to the criteria for the Target EA and
Enterprise Transition Plan key performance indicator, an agency at level 1
has a target EA that is a consolidated representation of all agency
segments and has submitted its segment architectures to OMB, but the
agency has yet to begin reusing IT investments. At level 5, all of the
agency s segment architectures are in progress or complete, reuse and/or
information sharing among subunits of the agency and/or other agencies is
demonstrated, and EA segments demonstrate a line-of-sight to agency
performance goals.
Several approaches to structuring an EA exist and can be applied to the
Overview of EA Structural
extent that they are relevant and appropriate for a given enterprise. In
Approaches
general, these approaches provide for decomposing an enterprise into its
logical parts and architecting each of the parts in relation to
enterprisewide needs and the inherent relationships and dependencies
that exist among the parts. As such, the approaches are fundamentally
aligned and consistent with a number of basic EA principles, such as
incremental rather than monolithic architecture development and
implementation, optimization of the whole rather than optimization of the
component parts, and maximization of shared data and services across the
component parts rather than duplication. Moreover, these approaches are
not mutually exclusive, and in fact can all be applied to some degree for a
given enterprise, depending on the characteristics and circumstances of
that enterprise. The approaches, which are briefly described below, are
federated, segmented, service-oriented, and extended architectures.
Federated
Under a federated approach, the architecture consists of a family of
coherent but distinct member architectures that conform to an
overarching corporate or parent architecture. This approach recognizes
that each federation member has unique goals and needs as well as
common roles and responsibilities with the members above and below it.
As such, member architectures (e.g., component, subordinate, or
subsidiary architectures) are substantially autonomous, but they also
inherit certain rules, policies, procedures, and services from the parent
architectures. A federated architecture enables component organization
Page 10 GAO-10-846G Executive Guide
autonomy while ensuring corporate or enterprisewide linkages and
alignment where appropriate.
Segmented
A segmented approach to EA development and use, like a federated
approach, employs a divide and conquer methodology in which
architecture segments are identified, prioritized, developed, and
implemented. In general, segments can be viewed as logical aspects, or
slivers, of the enterprise that can be architected and pursued as separate
initiatives under the overall corporate architecture. As such, the segments
serve as a bridge between the corporate frame of reference captured in the
EA and individual programs within portfolios of system investments. OMB
has issued guidance related to segment architectures. 22 As part of its
guidance, agencies are to group segments into three categories: core
mission areas (e.g., air transportation), business services (e.g., financial
management), and enterprise services (e.g., records management).
Service-Oriented
A service-oriented approach to EA is intended to identify and promote the
shared use of common business capabilities across the enterprise. Under
this approach, functions and applications are defined and designed as
discrete and reusable capabilities or services that may be under the
control of different organizational entities. As such, the capabilities or
services need to be, among other things, (1) self-contained, meaning that
they do not depend on any other functions or applications to execute a
discrete unit of work; (2) published and exposed as self-describing
business capabilities that can be accessed and used; and (3) subscribed to
via well-defined and standardized interfaces. This approach is intended to
reduce redundancy and increase integration, as well as provide the
flexibility needed to support a quicker response to changing and evolving
business requirements and emerging conditions.
22
See, for example, OMB, Improving Agency Performance Using Information and
Information Technology (Enterprise Architecture Assessment Framework v3.1) (June
2009); Federal Segment Architecture Working Group and OMB, Federal Segment
Architecture Methodology, Version 1.0 (December 2008); and OMB, Federal Enterprise
Architecture Practice Guidance (November 2007).
Page 11 GAO-10-846G Executive Guide
Extended
An extended approach to EA looks beyond the enterprise s organizational
boundaries and involves linking the EA to the architectures of its external
partners in order to inform and leverage the information, applications, and
services provided by these external partners. This approach recognizes
that certain organizations, particularly government agencies, share
mission goals and/or operational environments and thus can improve their
mission performance by working together to share information or
services.
Overview of Related In addition to being consistent with key federal EA guidance, version 2.0
of the EA Management Maturity Framework is consistent with other GAO
Management Guidance
and federal guidance associated with other key management activities,
such as strategic planning, human capital management, IT investment
management, and information security management. Principles reflected
in the guidance associated with these four management activities are
described below and, along with guidance related to other institutional
management activities, have been incorporated into the framework.
Effective strategic planning supports organizational transformation by
Strategic Planning
defining outcome-related strategic goals, how those goals are to be
achieved, and risk factors that could significantly affect their
achievement. 23 Accordingly, among other things, a strategic plan should
define performance goals and measures and cascade those goals and
measures to lower organizational levels,
assign accountability for achieving results,
provide a comprehensive view of performance, and
link resource needs to performance.
23
See, for example, the Government Performance and Results Act, P.L. 103-62, section 3,
and GAO, Defense Business Transformation: Status of Department of Defense Efforts to
Develop a Management Approach to Guide Business Transformation, GAO-09-272R
(Washington, D.C., January 2009).
Page 12 GAO-10-846G Executive Guide
As described in this framework, EA activities should be directed toward
achieving the goals and objectives described in an organization s strategic
plan.
A strategic approach to human capital management includes viewing
Strategic Human Capital
people as assets whose value to an organization can be enhanced by
Management
investing in them. Such an approach enables organizations to effectively
use their people and determine how well they integrate human capital
considerations into daily decision making and planning for mission results.
It also helps organizations remain aware of and be prepared for current
and future needs as an organization, ensuring that they have the
knowledge, skills, and abilities needed to pursue their missions. This
framework is consistent with GAO and Office of Personnel Management
(OPM) human capital guidance that includes such key practices as
identifying gaps between human capital needs and existing resources and
developing and implementing plans to address these needs. 24
IT investment management is a process for linking IT investment decisions to
IT Investment Management
an organization s strategic objectives and business plans. It focuses on
selecting, controlling, and evaluating investments in a manner that minimizes
risks while maximizing the return of investment.25 More specifically,
During investment selection, the organization (1) identifies and analyzes
each project s risks and returns before committing significant funds to any
project and (2) selects those IT projects that will best support its mission
needs.
During investment control, the organization ensures that projects are
meeting mission needs at the expected levels of cost, schedule, and risk. If
the project is not meeting expectations or if problems arise, steps are
quickly taken to address the deficiencies.
24
See, for example, GAO, A Model of Strategic Human Capital Management (Exposure
Draft), GAO-02-373SP (Washington, D.C.: March 2002); Human Capital: Key Principles for
Effective Strategic Workforce Planning, GAO-04-39 (Washington, D.C.: Dec. 11, 2003); and
OPM, Human Capital Assessment and Accountability Framework,
http://apps.opm.gov/HumanCapital/tool/index.cfm (accessed June 9, 2010).
25
See, for example, GAO, Information Technology Investment Management: A Framework
for Assessing and Improving Process Maturity, GAO-04-394G (Washington, D.C.: March
2004); GAO/AIMD-10.1.13; and Executive Guide: Improving Mission Performance
Through Strategic Information Management and Technology, GAO/AIMD-94-115.
Page 13 GAO-10-846G Executive Guide
During investment evaluation, actual versus expected results are
compared once a project has been fully implemented. This is done to (1)
assess the project s impact on mission performance, (2) identify any
changes or modifications to the project that may be needed, and (3) revise
the investment management process based on lessons learned.
GAO s IT Investment Management (ITIM) framework embodies each of
these phases in the key practices and activities associated with its five
levels of investment management maturity. 26 These practices and activities
recognize the need for evaluating investment compliance with the EA, and
thus our ITIM and EA maturity frameworks are explicitly aligned.
Managing the security of an organization s information assets is a
Information Security
complex, multifaceted undertaking that requires the involvement of the
Management
entire organization. Accordingly, NIST issued guidance 27 that provides an
approach to understanding and addressing organization-wide exposure to
information security risks by, among other things, defining and prioritizing
parent and subordinate organization core missions and business processes
and defining the types of information needed to execute these missions
and processes, including the associated internal and external information
flows. As such, NIST describes its approach as being tightly coupled with
an organization s EA and its security component.
The ability to effectively manage any activity, including developing,
Section 2: Overview maintaining, and using an EA, depends upon having meaningful measures of
of EA Management that activity in relation to some benchmark or standard. Such measurement
permits progress toward the desired end to be assessed and gauged so that
Maturity Framework corrective actions to address unacceptable deviations can occur.
Version 2.0
In February 2002 and April 2003, we issued versions 1.0 and 1.1 of our EA
Management Maturity Framework (EAMMF). 28 This update of the
framework (version 2.0) is based on our extensive use of version 1.1 in
performing governmentwide and agency-specific EA evaluations, as well
as our solicitation of comments from federal departments and agencies
26
GAO-04-394G.
27
NIST, Guide for Applying the Risk Management Framework to Federal Information
Systems: A Security Life Cycle Approach; Special Publication 800-37, Revision 1; February
2010.
28
GAO-02-6 and GAO-03-584G.
Page 14 GAO-10-846G Executive Guide
and other stakeholders on the usability, completeness, and sufficiency of
the framework as a tool to define and measure an organization s EA
management maturity. The update also incorporates comments received
from GAO s ECIMT on version 1.1 and a draft of version 2.0.
This latest version of the framework builds on the prior version by
retaining and expanding on the EAMMF s three interrelated components.
These three basic components are (1) hierarchical stages of management
maturity, (2) management attributes that are critical to the success of any
program or organizational endeavor, and (3) elements of EA management
that form the core of a successful and mature program. (See fig. 1 for a
simplified three-dimensional view of the EAMMF components.)
Figure 1: Simplified Three-Dimensional View of EAMMF
Stages
Attributes
Elements
Maturation
Source: GAO.
More specifically, version 2.0 consists of seven maturity stages, as compared
with the five stages in version 1.1. In short, each stage reflects those EA
management conditions that an enterprise should meet to logically build on
the EA management capability established at the preceding stage, and to
position it for introducing the EA management capability applicable to the
next stage. As such, the stages provide a road map for systematically
maturing or evolving an organization s capacity to manage an EA.
Further, version 2.0 includes four different ways to represent the attributes
that are critical to the success of any program or organizational endeavor,
and it allocates the core elements of EA management to each of these four
representations of critical success attributes. For purposes of the
framework, we refer to the four representations as the EA Management
Action, EA Functional Area, OMB Capability Area, and EA Enabler
representations. Each provides a unique perspective on the focus and
Page 15 GAO-10-846G Executive Guide
nature of the framework s core elements. In version 1.1 of the framework,
only one of the four representations (EA Management Action) was used.
Finally, version 2.0 consists of 59 key framework elements of EA
management, referred to as core elements, as compared with 31 that were
in version 1.1. (See app. II for a detailed description of each of the 59 core
elements.) Of the 59 core elements, 33 are new, 19 are modifications of the
elements described in version 1.1, and 7 are the same as the elements
described in version 1.1. Simply stated, a core element is an EA practice or
condition that should be performed or met. Like the maturity stages and
the critical success attributes in each of the four representations, the core
elements share relationships and dependencies. Building on figure 1,
figure 2 adds the core elements, maturity stages, and the four
representations of the critical success attributes, and provides a transition
to the EAMMF matrix presented in figure 3.
Figure 2: Conceptual Depiction of the EAMMF s Interrelated Components
7 maturity stages
4 crit
ical
succ
ess
59 core elements
attrib
ute
repre
senta
tions
Maturation
Source: GAO.
Page 16 GAO-10-846G Executive Guide
Figure 3: Generic EAMMF Matrix
Maturity stage 6
Maturity stage 5
Maturity stage 4
Maturity stage 3
Maturity stage 2
This is a work of the U.S. government and is not subject to copyright protection in the
Contact this candidate