This is the accessible text file for GAO report number GAO-10-846G 
entitled 'Organizational Transformation: A Framework for Assessing and 
Improving Enterprise Architecture Management (Version 2.0)' which was 
released on August 5, 2010. 

This text file was formatted by the U.S. Government Accountability 
Office (GAO) to be accessible to users with visual impairments, as 
part of a longer term project to improve GAO products' accessibility. 
Every attempt has been made to maintain the structural and data 
integrity of the original printed product. Accessibility features, 
such as text descriptions of tables, consecutively numbered footnotes 
placed at the end of the file, and the text of agency comment letters, 
are provided but may not exactly duplicate the presentation or format 
of the printed version. The portable document format (PDF) file is an 
exact electronic replica of the printed version. We welcome your 
feedback. Please E-mail your comments regarding the contents or 
accessibility features of this document to Webmaster@gao.gov. 

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. 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. 

Executive Guide: 

United States Government Accountability Office: 
GAO: 

August 2010: 

Organizational Transformation: 

A Framework for Assessing and Improving Enterprise Architecture 
Management (Version 2.0): 

GAO-10-846G: 

GAO Highlights: 

Highlights of GAO-10-846G, an executive guide. 

Why GAO Did This Study: 

Effective use of an enterprise architecture (EA) is a hallmark of 
successful organizations and an essential means to achieving a desired 
end: having operations and technology environments that maximize 
institutional mission performance and outcomes. 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. Not using an EA can result in organizational operations 
and supporting technology infrastructures and systems that are 
duplicative, poorly integrated, unnecessarily costly to maintain and 
interface, and unable to respond quickly to shifting environmental 
factors. 

To assist organizations in successfully developing, maintaining, and 
using an EA, GAO is issuing this major update to its Enterprise 
Architecture Management Maturity Framework. Its purpose is to provide 
a flexible benchmark against which to plan for and measure EA program 
maturity. To develop the update, GAO solicited comments from 27 
federal departments and agencies, as well as representatives from the 
private sector, state governments, and academia, and it leveraged its 
prior experience in applying the framework. 

What GAO Found: 

The framework consists of three interrelated components: (1) seven 
hierarchical stages of management maturity; (2) four representations 
of management attributes that are critical to the success of any 
program or organizational endeavor; and (3) 59 elements, or building 
blocks, of EA management that are at the core of an EA program. (See 
the figure below for a conceptual view of the framework’s components.) 

Figure: Conceptual Depiction of the EAMMF’s Interrelated Components: 

[Refer to PDF for image: illustration] 

Maturation is depicted as increasing: 
4 critical success attribute representations: plotted against: 
7 maturity stages: representing: 59 core elements. 

Source: GAO. 

[End of figure] 

Each of the seven maturity stages reflects those EA management 
conditions that an enterprise should meet to logically build on the 
capability established at the preceding stage. As such, the stages 
provide a road map for systematically maturing or evolving an 
organization’s capacity to manage an EA. The stages are: Stage 0: 
Creating EA Awareness; Stage 1: Establishing EA Institutional 
Commitment and Direction; Stage 2: Creating the Management Foundation 
for EA Development and Use; Stage 3: Developing Initial EA 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 Transformation; Stage 6: Continuously Improving the EA 
and Its Use to Achieve Corporate Optimization. 

The four critical success attribute representations provide different 
and complementary ways to view and thus understand the 59 core 
elements. The four are referred to as the (1) EA Management Action 
Representation, (2) EA Functional Area Representation, (3) Office of 
Management and Budget Capability Area Representation, and (4) EA 
Enabler Representation. Each provides a unique perspective on the 
focus and nature of the framework’s core elements. 

The 59 core elements are collectively the EA practices, structures, 
activities, and conditions that, when properly employed based on the 
unique facts and circumstances of each organization and the stated 
purpose of its EA program, can permit that organization to progress to 
increasingly higher states of EA management maturity and thereby 
maximize its chances of realizing an EA’s institutional value. 

View [hyperlink, http://www.gao.gov/products/GAO-10-846G] or key 
components. For more information, contact Randolph C. Hite at (202) 
512-3439 or hiter@gao.gov. 

[End of section] 

Contents: 

Preface: 

Section 1: Introduction: 

Section 2: Overview of EA Management Maturity Framework Version 2.0: 

Section 3: Uses of EAMMF Version 2.0: 

Appendix I: Approach to Developing EAMMF Version 2.0: 

Appendix II: Framework Elements: 

Tables: 

Table 1: OMB EA Assessment Framework Capability Areas: 

Table 2: EA Management Action Representation of the Critical Success 
Attributes and the Core Elements: 

Table 3: EA Functional Area Representation of the Critical Success 
Attributes and the Core Elements: 

Table 4: OMB Capability Area Representation of the Critical Success 
Attributes and the Core Elements: 

Table 5: EA Enabler Representation of the Critical Success Attributes 
and the Core Elements: 

Table 6: Categories of Comments and Suggestions Provided for Update of 
EAMMF Version 1.1: 

Table 7: Examples of EA Program Management Office Leadership Positions: 

Table 8: Factors to Consider in Selecting EA Modeling and Repository 
Tools: 

Figures: 

Figure 1: Simplified Three-Dimensional View of EAMMF: 

Figure 2: Conceptual Depiction of the EAMMF's Interrelated Components: 

Figure 3: Generic EAMMF Matrix: 

Figure 4: EAMMF Overview with Seven Stages of Maturity Identified: 

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: 

[End of section] 

United States Government Accountability Office:
Washington, DC 20548: 

Preface: 

Effective use of a well-defined enterprise architecture (EA) is a 
hallmark 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.[Footnote 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.[Footnote 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. 

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.[Footnote 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.[Footnote 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. 

Questions and comments about this framework should be directed to me 
at (202) 512-3439 or at hiter@gao.gov. 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. 

Signed by: 

Randolph C. Hite: 
Director, Information Technology Architecture and Systems Issues: 

[End of section] 

Section 1: Introduction: 

An EA provides a clear and comprehensive picture of the structure and 
substance of any purposeful activity, whether it is an organization 
(e.g., a 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.[Footnote 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.[Footnote 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 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.[Footnote 
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 development 
of detailed "to-be" models, followed by the development of a plan for 
transitioning from the "as-is" to the "to-be" environment.[Footnote 8] 

Overview of Federal EA Guidance and Legislation: 

Architecture guidance within the federal government can be traced to a 
National Institute of Standards and Technology (NIST) publication in 
1989.[Footnote 9] Subsequently, we issued a guide[Footnote 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. 
[Footnote 11] Since that time, other federal entities have issued 
frameworks for defining the content of EAs, including the federal CIO 
Council,[Footnote 12] the Department of the Treasury,[Footnote 13] and 
the Department of Defense (DOD).[Footnote 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 
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.[Footnote 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. 

* 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.[Footnote 16] Further, the 
federal CIO Council collaborated with us in developing EA guidance 
focused on assessing an IT investment's compliance with an EA, 
[Footnote 17] as well as guidance that addressed the end-to-end steps 
associated with developing, maintaining, and implementing an EA 
program.[Footnote 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 agency goals with IT.[Footnote 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.[Footnote 20] 

OMB's EA Assessment Framework: 

In April 2004, OMB issued the first version of its EA Assessment 
Framework, and since then has issued multiple updates.[Footnote 21] 
According to the 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: Completion; 
Summary: 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. 

Capability area: Use; 
Summary: 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. 

Capability area: Results; 
Summary: Measures actual results attributed to the EA, and therefore 
the effectiveness and value of its EA activities. 

Source: OMB. 

[End of table] 

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. 

Overview of EA Structural Approaches: 

Several approaches to structuring an EA exist and can be applied to 
the extent that they are relevant and appropriate for a given 
enterprise. In 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 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.[Footnote 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. 

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 Management Guidance: 

In addition to being consistent with key federal EA guidance, version 
2.0 of the EA Management Maturity Framework is consistent with other 
GAO 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. 

Strategic Planning: 

Effective strategic planning supports organizational transformation by 
defining outcome-related strategic goals, how those goals are to be 
achieved, and risk factors that could significantly affect their 
achievement.[Footnote 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. 

As described in this framework, EA activities should be directed 
toward achieving the goals and objectives described in an 
organization's strategic plan. 

Strategic Human Capital Management: 

A strategic approach to human capital management includes viewing 
people as assets whose value to an organization can be enhanced by 
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.[Footnote 24] 

IT Investment Management: 

IT investment management is a process for linking IT investment 
decisions to 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.[Footnote 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. 

* 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.[Footnote 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. 

Information Security Management: 

Managing the security of an organization's information assets is a 
complex, multifaceted undertaking that requires the involvement of the 
entire organization. Accordingly, NIST issued guidance[Footnote 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. 

[End of section] 

Section 2: Overview of EA Management Maturity Framework Version 2.0: 

The ability to effectively manage any activity, including developing, 
maintaining, and using an EA, depends upon having meaningful measures 
of that activity in relation to some benchmark or standard. Such 
measurement permits progress toward the desired end to be assessed and 
gauged so that corrective actions to address unacceptable deviations 
can occur. 

In February 2002 and April 2003, we issued versions 1.0 and 1.1 of our 
EA Management Maturity Framework (EAMMF).[Footnote 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 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 
figure 1 for a simplified three-dimensional view of the EAMMF 
components.) 

Figure 1: Simplified Three-Dimensional View of EAMMF: 

[Refer to PDF for image: illustration] 

Depicted is a three-dimensional rectangular box of the maturation 
process: 
Attributes; 
Stages; 
Elements. 

Source: GAO. 

[End of figure] 

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 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: 

[Refer to PDF for image: illustration] 

Maturation is depicted as increasing: 
4 critical success attribute representations: plotted against: 
7 maturity stages: representing: 59 core elements. 

Source: GAO. 

[End of figure] 

Figure 3: Generic EAMMF Matrix: 

[Refer to PDF for image: illustration] 

Maturity stage 0: 
Critical success attribute: No elements. 

Maturity stage 1: 
Critical success attribute: Core elements. 

Maturity stage 2: 
Critical success attribute: Core elements. 

Maturity stage 3: 
Critical success attribute: Core elements. 

Maturity stage 4: 
Critical success attribute: Core elements. 

Maturity stage 5: 
Critical success attribute: Core elements. 

Maturity stage 6: 
Critical success attribute: Core elements. 

Source: GAO. 

[End of figure] 

Maturity Stages: 

Version 2.0 is made up of seven stages of EA management maturity, each 
of which includes all the core elements that are resident in previous 
stages. To the generic EAMMF structure of figure 3, figure 4 adds the 
specific names of the seven stages. Each of the stages is described in 
detail below. 

Figure 4: EAMMF Overview with Seven Stages of Maturity Identified: 

[Refer to PDF for image: illustration] 

Stage 0: Creating EA awareness; 
Critical success attribute: No elements. 

Stage 1: Establishing EA institutional commitment and direction; 
Critical success attribute: Core elements. 

Stage 2: Creating the management foundation for EA development and use; 
Critical success attribute: Core elements. 

Stage 3: Developing initial EA versions; 
Critical success attribute: Core elements. 

Stage 4: Completing and using an initial EA version for targeted 
results; 
Critical success attribute: Core elements. 

Stage 5: Expanding and evolving the EA and its use for institutional
transformation; 
Critical success attribute: Core elements. 

Stage 6: Continuously improving the EA and its use to achieve
corporate optimization; 
Critical success attribute: Core elements. 

Source: GAO. 

[End of figure] 

Stage 0: Creating EA Awareness: 

At this stage, either an organization does not have plans to develop 
and use an EA or it has plans that do not demonstrate an awareness of 
the management discipline needed to successfully develop, maintain, 
and use an EA. While Stage 0 organizations may have initiated some EA 
activity, their efforts are largely ad hoc and unstructured and lack 
the institutional leadership necessary for successful EA development, 
maintenance, and use as defined in Stage 1. Therefore, Stage 0 has no 
associated core elements. 

Stage 1: Establishing EA Institutional Commitment and Direction: 

At this stage, an organization puts in place the foundational pillars 
for treating its EA program as an institutional imperative and for 
overcoming traditional barriers to its success. In particular, the 
organization grounds EA development and compliance in policy and 
recognizes it as a corporate asset by vesting ownership of the 
architecture with top executives (i.e., lines of business owners and 
chief "X" officers (CXO)[Footnote 29] as members of a chartered 
architecture executive committee who are provided with the knowledge 
and understanding of the architecture concepts and governance 
principles needed to lead and direct the EA effort. Through the EA 
executive committee (hereafter referred to as the executive 
committee), leadership is provided in the form of approved EA goals 
and objectives and key aspects of the architecture's construct, such 
as the framework(s) to be used and the approach for establishing the 
hierarchy and structure of organization components (e.g., federation 
members, segments, etc.). Leadership is also provided at this stage 
through the executive committee members' proactive outreach to their 
respective parts of the organization to facilitate a shift toward a 
more holistic and less parochial and change-resistant culture. 

Also during this stage, the central figure in managing the program, 
the chief architect, is appointed and empowered, and the integral and 
relative role of the EA vis-à-vis other corporate governance 
disciplines is recognized in corporate policy. In addition, the 
construct for measuring program performance and holding the executive 
committee, chief architect, and subordinate architects accountable for 
results is established. Organizations that achieve this maturity stage 
have demonstrated EA leadership through an institutional commitment to 
developing and using the EA and a strategic basis for directing its 
development, maintenance, and use. 

Stage 2: Creating the Management Foundation for EA Development and Use: 

This stage builds on the strategic leadership foundation established 
in Stage 1 by creating the managerial means to the ends--an initial 
version of the EA (Stages 3 and 4) and an evolving and continuously 
improving EA (Stages 5 and 6) that can be used to help guide and 
direct investments and achieve the architecture's stated purpose. More 
specifically, at this stage the organization establishes operational 
EA program offices, including a corporate program office that is 
headed by the chief architect, who reports to the executive committee. 
Also at this stage, the executive committee continues to exercise 
leadership by ensuring that the chief architect and subordinate 
architects have the funding and human capital needed to "stand up" 
their respective program offices and have acquired the requisite 
architecture tools (development and maintenance methodologies, 
modeling tools, and repository). 

Leveraging these resources, the corporate program office develops the 
core plans and processes needed to manage and execute the EA program, 
such as a human capital plan, a work breakdown structure and schedule 
defining the timing and sequencing of key work steps and events 
(integrated master schedule), a quality assurance plan, a 
configuration management plan, and a risk management plan. Among other 
things, these plans build on the executive committee's EA strategy by, 
for example, identifying federation or extended enterprise members and 
defining and prioritizing segments. At the same time, the corporate 
and subordinate architecture program offices work with owners of 
related institutional management disciplines (e.g., strategic 
planning, human capital management, capital planning and investment 
control, and system life cycle management) to explicitly integrate EA 
management processes into each discipline's policy and guidance 
documents. Also during this stage, progress in establishing corporate 
and subordinate program office EA management capacity and readiness is 
measured and reported to the executive committee. Organizations that 
achieve this stage have largely established the program management 
capability needed to develop initial versions of an EA.[Footnote 30] 

Stage 3: Developing Initial EA Versions: 

At this stage, an organization is focused on strengthening the ability 
of its program office(s) to develop initial versions of the EA while 
also actually developing one or more of these versions. Among other 
things, steps are taken to engage stakeholders in the process and 
implement human capital plans, to include hiring and training staff 
and acquiring contractor expertise. During this stage, these resources 
are combined with earlier acquired tools (e.g., framework(s), 
methodologies, modeling tools, repositories) to execute EA management 
plans and schedules aimed at delivering an initial corporate version 
of the architecture that includes current "as-is" and target "to-be" 
views of the performance, business, data, services, technology, and 
security architectures, as well as an initial version of a plan for 
transitioning from the "as-is" to the "to-be" views. 

Also during this stage, one or more segment architectures or 
federation member architectures are being developed using available 
tools and defined plans and schedules, and progress in developing 
initial architecture versions is measured by the chief architect and 
reported to the executive committee. The organization also begins to 
lay the foundation for using its EA as a corporate decision-making 
tool by establishing investment compliance and subordinate 
architecture alignment methodologies that are criteria-based and that 
are supported by evaluation tools that treat areas of noncompliance 
and misalignment as risks to be proactively mitigated. Additionally, 
EA development risks are being proactively identified and addressed. 
Although an organization at this maturity stage does not yet have a 
version of an EA that is ready for implementation, it is well on its 
way to defining an EA of sufficient scope and content that can be used 
to guide and constrain investments in a way that can produce targeted 
results.[Footnote 31] 

Stage 4: Completing and Using an Initial EA Version for Targeted 
Results: 

At this stage, an organization has developed a version of its 
corporate EA that has been approved by the executive committee, to 
include "as-is" and "to-be" views of the performance, business, data, 
services, technology, and security architectures, as well as an 
initial version of a plan for transitioning from the "as-is" to the 
"to-be" views. In addition, one or more segment and/or federation 
member architectures have been developed, according to established 
priorities, and approved. Moreover, the approved corporate and 
subordinate architectures are being used to guide and constrain 
capital investment selection and control decisions and system life 
cycle definition and design decisions. Also during this stage, a range 
of factors are measured and reported to the executive committee, such 
as EA product quality, investment compliance, subordinate architecture 
alignment, and results and outcomes. Organizations that achieve this 
stage of maturity have a foundational set of corporate and subordinate 
EA products that provide a meaningful basis for informing selected 
investments and building greater EA scope, content, use, and results. 
[Footnote 32] 

Stage 5: Expanding and Evolving the EA and Its Use for Institutional 
Transformation: 

At this stage, the EA's scope is extended to the entire organization, 
and it is supported by a full complement of segment and federation 
member architectures, all of which include "as-is" and "to-be" views 
of the performance, business, data, services, technology, and security 
architectures, as well as well-defined plans for transitioning from 
the "as-is" to the "to-be" views. Moreover, this suite of architecture 
products is governed by a common EA framework, methodology, and 
repository, thus permitting the products to be appropriately 
integrated. Also at this stage, the architecture products are 
continuously maintained, and major updates of the corporate EA are 
approved by the head of the organization, while subordinate 
architecture product updates are approved by their corresponding 
organization heads or segment owners. In addition, architecture 
product quality (i.e., completeness, consistency, usability, and 
utility) as well as EA management process integrity are assessed by an 
independent agent, and the results are reported to the chief architect 
and the executive committee. An organization that achieves this level 
of maturity has established a full suite of architecture products that 
can be employed as a featured decision-support tool when considering 
and planning large-scale organizational restructuring or 
transformation initiatives.[Footnote 33] 

Stage 6: Continuously Improving the EA and Its Use to Achieve 
Corporate Optimization: 

At this stage, an organization is focused on continuously improving 
the quality of its suite of EA products and the people, processes, and 
tools used to govern their development, maintenance, and use. By 
achieving this stage of maturity, the organization has established a 
truly enterprisewide blueprint to inform both "board room" strategic 
planning and decision making and "on-the-ground" implementation of 
these changes through a range of capital investment and maintenance 
projects and other corporate initiatives.[Footnote 34] 

Critical Success Attributes and Core Elements: 

Version 2.0 also consists of four sets of characteristics or 
attributes that are critical to the successful performance of program 
and organizational management. Each of the sets provides a unique way 
to represent (i.e., group and view) the framework's 59 core elements, 
which are the basic building blocks of the framework and are described 
in appendix II. Accordingly, the four are referred to as 
representations. They are the (1) EA Management Action Representation, 
(2) EA Functional Area Representation, (3) OMB Capability Area 
Representation, and the (4) EA Enabler Representation. 

EA Management Action Representation of Core Elements: 

This representation reflects four characteristics or attributes that 
are recognized in other models as critical to successfully performing 
any management function, initiative, or program. Restated, these 
attributes collectively form the basis by which an organization can 
institutionally manage a given function, initiative, or program, like 
EA. Both version 1.0 and 1.1 of the framework were centered on this 
representation. (See table 2 for a presentation of the version 2.0 
core elements using this representation.) The four attributes are as 
follows: 

* Demonstrates commitment: Efforts and activities to show 
organizationwide commitment to perform the function, initiative, or 
program by, for example, establishing policies, providing resources, 
and involving organizational leaders. 

* Provides capability to meet commitment: Efforts and activities to 
put in place the capability (people, processes, and tools) needed to 
execute the function, initiative, or program. 

* Demonstrates satisfaction of commitment: Products, results, and 
outcomes that demonstrate that the function, initiative, or program is 
being performed. 

* Verifies satisfaction of commitment: Efforts and activities to 
verify, via quantitative and qualitative measurement, that the 
function, initiative, or program has been satisfactorily performed. 

Table 2: EA Management Action Representation of the Critical Success 
Attributes and the Core Elements: 

Attribute 1: Demonstrates commitment: 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (1) 
Written and approved organization policy exists for EA development, 
maintenance, and use; (2) Executive committee representing the 
enterprise exists and is responsible and accountable for EA; (3) 
Executive committee is taking proactive steps to address EA cultural 
barriers; 
Stage 2: Creating the management foundation for EA development and 
use: (9) EA budgetary needs are justified and funded; 
Stage 3: Developing initial EA versions: (19) Organization business 
owner and CXO representatives are actively engaged in architecture 
development; 
Stage 4: Completing and using an initial EA version for targeted 
results: (33) Executive committee has approved the initial version of 
corporate EA; (34) Key stakeholders have approved the current version 
of subordinate architectures; (35) EA is integral to the execution of 
other institutional management disciplines; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (44) Organization head has approved current version of 
the corporate EA; (45) Organization component heads or segment owners 
have approved current version of their respective subordinate 
architectures; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (53) EA is used by executive leadership to 
inform organization strategic planning and policy formulation. 

Attribute 2: Provides capability to meet commitment; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (4) 
Executive committee members are trained in EA principles and concepts; 
(5) Chief architect exists; (7) EA; framework(s) is adopted; 
Stage 2: Creating the management foundation for EA development and 
use: (10) EA program office(s) exists; (11) Key program office 
leadership positions are filled; (12) Program office human capital 
plans exist; (13) EA development and maintenance methodology exists; 
(14) Automated EA tools exist; 
Stage 3: Developing initial EA versions: (20) EA human capital plans 
are being implemented; (21) Program office contractor support needs 
are being met; (22) Program office staff are trained in EA framework, 
methodology, and tools; (23) Methodologies and tools exist to 
determine investment compliance with corporate and subordinate 
architectures; (24) Methodologies and tools exist to determine 
subordinate architecture alignment with the corporate EA; (25) EA-
related risks are proactively identified, reported, and mitigated; 
Stage 4: Completing and using an initial EA version for targeted 
results: (36) Program office human capital needs are met; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (46) Integrated repository tools and common EA 
framework and methodology are used across the enterprise; 
(47) Corporate and subordinate architecture program offices operate as 
a single virtual office that shares resources enterprisewide; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (54) EA human capital capabilities are 
continuously improved; (55) EA methodologies and tools are 
continuously improved; (56) EA management processes are continuously 
improved and reflect the results of external assessments. 

Attribute 3: Demonstrates satisfaction of commitment; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (6) 
EA purpose is clearly stated; 
Stage 2: Creating the management foundation for EA development and 
use: (15) EA program management plan exists and reflects relationships 
with other management disciplines; (16) Work breakdown structure and 
schedule to develop EA exist; (17) EA segments, federation members, 
and/or extended members have been identified and prioritized; 
Stage 3: Developing initial EA versions: (26) Initial versions of 
corporate "as-is" and "to-be" EA and sequencing plan are being 
developed; (27) Initial version of corporate EA describing the 
enterprise in terms of performance, business, data, services, 
technology, and security is being developed; (28) One or more segment 
and/or federation member architectures is being developed; (29) 
Architecture products are being developed according to the EA content 
framework; (30) Architecture products are being developed according to 
a defined EA methodology; (31) Architecture products are being 
developed using EA tools; 
Stage 4: Completing and using an initial EA version for targeted 
results: (37) Initial versions of corporate "as-is" and "to-be" EA and 
sequencing plan exist; (38) Initial version of corporate EA captures 
performance, business, data, services, technology, and security views; 
(39) One or more segment and/or federation member architectures exists 
and is being implemented; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (48) Corporate EA and sequencing plan are 
enterprisewide in scope; (49) Corporate EA and sequencing plan are 
aligned with subordinate architectures; (50) All segment and/or 
federated architectures exist and are horizontally and vertically 
integrated; (51) Corporate and subordinate architectures are extended 
to align with external partner architectures; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (57) EA products are continuously improved and 
updated. 

Attribute 4: Verifies satisfaction of commitment; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (8) 
EA performance and accountability framework is established; 
Stage 2: Creating the management foundation for EA development and 
use: (18) Program office readiness is measured and reported; 
Stage 3: Developing initial EA versions: (32) Architecture development 
progress is measured and reported; 
Stage 4: Completing and using an initial EA version for targeted 
results: (40) EA product quality is measured and reported; (41) EA 
results and outcomes are measured and reported; (42) Investment 
compliance with corporate and subordinate architectures is measured 
and reported; (43) Subordinate architecture alignment with the 
corporate EA is measured and reported; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (52) EA products and management processes are subject 
to independent assessment; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (58) EA quality and results measurement 
methods are continuously improved; (59) EA continuous improvement 
efforts reflect the results of external assessments. 

Source: GAO. 

[End of table] 

EA Functional Area Representation of Core Elements: 

This representation reflects four major groups of core elements that 
can be viewed as the functions associated with developing and 
implementing a well-defined EA. We first discussed how the substance 
of the core elements could be viewed according to these functional 
areas or groupings in our August 2006 report on the state of EA 
maturity across the federal government.[Footnote 35] At that time, we 
derived the functional areas based on the inherent purpose, focus, and 
substance of the core elements. Thus, this representation of critical 
success attributes, in contrast to the other three representations, is 
not grounded in existing management models, frameworks, and 
principles. (See table 3 for a presentation of the version 2.0 core 
elements using this representation.) The four groupings are as follows: 

* Governance: The group of core elements that provides the means by 
which the EA program is managed. 

* Content: The group of core elements that defines the actual 
substance and makeup of all of the EA artifacts as well as how these 
artifacts are derived, captured, maintained, and made accessible. 

* Use: The group of core elements that provides for the actual 
implementation of the EA and treats it as an authoritative frame of 
reference for informed transformation, modernization, and investment 
decision making. 

* Measurement: The group of core elements that verifies the quality of 
EA products and management processes and ensures that EA outcomes and 
results are achieved. 

Table 3: EA Functional Area Representation of the Critical Success 
Attributes and the Core Elements: 

Attribute 1: Governance; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (1) 
Written and approved organization policy exists for EA development, 
maintenance, and use; (2) Executive committee representing the 
enterprise exists and is responsible and accountable for EA; (3) 
Executive committee is taking proactive steps to address EA cultural 
barriers; (4) Executive committee members are trained in EA principles 
and concepts; (5) Chief architect exists; 
Stage 2: Creating the management foundation for EA development and 
use: (9) EA budgetary needs are justified and funded; (10) EA program 
office(s) exists; (11) Key program office leadership positions are 
filled; (12) Program office human capital plans exist; (15) EA program 
management plan exists and reflects relationships with other 
management disciplines; (16) Work breakdown structure and schedule to 
develop EA exist; 
Stage 3: Developing initial EA versions: (19) Organization business 
owner and CXO representatives are actively engaged in architecture 
development; (20) EA human capital plans are being implemented; 
(21) Program office contractor support needs are being met; (22) 
Program office staff are trained in EA framework, methodology, and 
tools; (25) EA-related risks are proactively identified, reported, and 
mitigated; 
Stage 4: Completing and using an initial EA version for targeted 
results: (33) Executive committee has approved the initial version of 
corporate EA; (34) Key stakeholders have approved the current version 
of subordinate architectures; (36) Program office human capital needs 
are met; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (44) Organization head has approved current version of 
the corporate EA; (45) Organization component heads or segment owners 
have approved current version of their respective subordinate 
architectures; (47) Corporate and subordinate architecture program 
offices operate as a single virtual office that shares resources 
enterprisewide; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (54) EA human capital capabilities are 
continuously improved. 

Attribute 2: Content; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (6) 
EA purpose is clearly stated; (7) EA framework(s) is adopted; 
Stage 2: Creating the management foundation for EA development and 
use: (13) EA development and maintenance methodology exists; 
(14) Automated EA tools exist; (17) EA segments, federation members, 
and/or extended members have been identified and prioritized; 
Stage 3: Developing initial EA versions: (24) Methodologies and tools 
exist to determine subordinate architecture alignment with the 
corporate EA; (26) Initial versions of corporate "as-is" and "to-be" 
EA and sequencing plan are being developed; (27) Initial version of 
corporate EA describing the enterprise in terms of performance, 
business, data, services, technology, and security is being developed; 
(28) One or more segment and/or federation member architectures is 
being developed; (29) Architecture products are being developed 
according to the EA content framework; (30) Architecture products are 
being developed according to a defined EA methodology; (31) 
Architecture products are being developed using EA tools; 
Stage 4: Completing and using an initial EA version for targeted 
results: (37) Initial versions of corporate "as-is" and "to-be" EA and 
sequencing plan exist; (38) Initial version of corporate EA captures 
performance, business, data, services, technology, and security views; 
(39) One or more segment and/or federation member architectures exists 
and is being implemented; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (46) Integrated repository tools and common EA 
framework and methodology are used across the enterprise; 
(48) Corporate EA and sequencing plan are enterprisewide in scope; 
(49) Corporate EA and sequencing plan are aligned with subordinate 
architectures; (50) All segment and/or federated architectures exist 
and are horizontally and vertically integrated; (51) Corporate and 
subordinate architectures are extended to align with external partner 
architectures; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (55) EA methodologies and tools are 
continuously improved; (56) EA management processes are continuously 
improved and reflect the results of external assessments; (57) EA 
products are continuously improved and updated. 

Attribute 3: Use; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: 
[Empty]; 
Stage 2: Creating the management foundation for EA development and 
use: [Empty]; 
Stage 3: Developing initial EA versions: (23) Methodologies and tools 
exist to determine investment compliance with corporate and 
subordinate architectures; 
Stage 4: Completing and using an initial EA version for targeted 
results: (35) EA is integral to the execution of other institutional 
management disciplines; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: [Empty]; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (53) EA is used by executive leadership to 
inform organization strategic planning and policy formulation. 

Attribute 4: Measurement; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (8) 
EA performance and accountability framework is established; 
Stage 2: Creating the management foundation for EA development and 
use: (18) Program office readiness is measured and reported; 
Stage 3: Developing initial EA versions: (32) Architecture development 
progress is measured and reported; 
Stage 4: Completing and using an initial EA version for targeted 
results: (40) EA product quality is measured and reported; (41) EA 
results and outcomes are measured and reported; (42) Investment 
compliance with corporate and subordinate architectures is measured 
and reported; (43) Subordinate architecture alignment with the 
corporate EA is measured and reported; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (52) EA products and management processes are subject 
to independent assessment; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (58) EA quality and results measurement 
methods are continuously improved; (59) EA continuous improvement 
efforts reflect the results of external assessments. 

Source: GAO. 

[End of table] 

OMB Capability Area Representation of Core Elements: 

This representation reflects the three capability areas that are 
provided for in OMB's EA Assessment Framework. As such, this 
representation demonstrates how the GAO and OMB EA frameworks, albeit 
different, are fundamentally aligned and substantially consistent. 
(See table 4 for a presentation of the version 2.0 core elements using 
this representation.) The three capability areas and OMB's definition 
of each are as follows: 

* Completion: The extent to which an agency has developed an 
integrated, organizationwide architecture, in terms of business, 
performance, data, services, technology, and security, as well as a 
comprehensive enterprise transition plan. 

* Use: The extent to which the agency has established key management 
practices, processes, and policies needed for developing, maintaining, 
and overseeing its architecture, and for demonstrating both the 
importance of architecture awareness and the value of employing 
architecture practices; it also assesses the extent of the agency's 
use of its architecture to inform strategic planning, program 
performance improvement planning, information resources management, IT 
management, and capital planning and investment control processes. 

* Results: The extent to which the agency is measuring the 
effectiveness and value of its architecture activities by assigning 
performance measurements to its architecture and related processes, 
and reporting on actual results to demonstrate architecture success. 

Table 4: OMB Capability Area Representation of the Critical Success 
Attributes and the Core Elements: 

Attribute 1: Completion; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: 
[Empty]; 
Stage 2: Creating the management foundation for EA development and 
use: (17) EA segments, federation members, and/or extended members 
have been identified and prioritized; 
Stage 3: Developing initial EA versions: (26) Initial versions of 
corporate "as-is" and "to-be" EA and sequencing plan are being 
developed; (27) Initial version of corporate EA describing the 
enterprise in terms of performance, business, data, services, 
technology, and security is being developed; (28) One or more segment 
and/or federation member architectures is being developed; (29) 
Architecture products are being developed according to the EA content 
framework; (30) Architecture products are being developed according to 
a defined EA methodology; (31) Architecture products are being 
developed using EA tools; 
Stage 4: Completing and using an initial EA version for targeted 
results: (37) Initial versions of corporate "as-is" and "to-be" EA and 
sequencing plan exist; (38) Initial version of corporate EA captures 
performance, business, data, services, technology, and security views; 
(39) One or more segment and/or federation member architectures exists 
and is being implemented; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (48) Corporate EA and sequencing plan are 
enterprisewide in scope; (49) Corporate EA and sequencing plan are 
aligned with subordinate architectures; (50) All segment and/or 
federated architectures exist and are horizontally and vertically 
integrated; (51) Corporate and subordinate architectures are extended 
to align with external partner architectures; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (57) EA products are continuously improved and 
updated. 

Attribute 2: Use; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (1) 
Written and approved organization policy exists for EA development, 
maintenance, and use; (2) Executive committee representing the 
enterprise exists and is responsible and accountable for EA; (3) 
Executive committee is taking proactive steps to address EA cultural 
barriers; (4) Executive committee members are trained in EA principles 
and concepts; (5) Chief architect exists; (6) EA purpose is clearly 
stated; (7) EA framework(s) is adopted; 
Stage 2: Creating the management foundation for EA development and 
use: (9) EA budgetary needs are justified and funded; (10) EA program 
office(s) exists; (11) Key program office leadership positions are 
filled; (12) Program office human capital plans exist; (13) EA 
development and maintenance methodology exists; (14) Automated EA 
tools exist; (15) EA program management plan exists and reflects 
relationships with other management disciplines; (16) Work breakdown 
structure and schedule to develop EA exist; 
Stage 3: Developing initial EA versions: (19) Organization business 
owner and CXO representatives are actively engaged in architecture 
development; (20) EA human capital plans are being implemented; (21) 
Program office contractor support needs are being met; (22) Program 
office staff are trained in EA framework, methodology, and tools; 
(23) Methodologies and tools exist to determine investment compliance 
with corporate and subordinate architectures; (24) Methodologies and 
tools exist to determine subordinate architecture alignment with the 
corporate EA; (25) EA-related risks are proactively identified, 
reported, and mitigated; 
Stage 4: Completing and using an initial EA version for targeted 
results: (33) Executive committee has approved the initial version of 
corporate EA; (34) Key stakeholders have approved the current version 
of subordinate architectures; (35) EA is integral to the execution of 
other institutional management disciplines; (36) Program office human 
capital needs are met; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (44) Organization head has approved current version of 
the corporate EA; (45) Organization component heads or segment owners 
have approved current version of their respective subordinate 
architectures; (46) Integrated repository tools and common EA 
framework and methodology are used across the enterprise; (47) 
Corporate and subordinate architecture program offices operate as a 
single virtual office that shares resources enterprisewide; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (53) EA is used by executive leadership to 
inform organization strategic planning and policy formulation; (54) EA 
human capital capabilities are continuously improved; (55) EA 
methodologies and tools are continuously improved; (56) EA management 
processes are continuously improved and reflect the results of 
external assessments. 

Attribute 3: Results; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (8) 
EA performance and accountability framework is established; 
Stage 2: Creating the management foundation for EA development and 
use: (18) Program office readiness is measured and reported; 
Stage 3: Developing initial EA versions: (32) Architecture development 
progress is measured and reported; 
Stage 4: Completing and using an initial EA version for targeted 
results: (40) EA product quality is measured and reported; (41) EA 
results and outcomes are measured and reported; (42) Investment 
compliance with corporate and subordinate architectures is measured 
and reported; (43) Subordinate architecture alignment with the 
corporate EA is measured and reported; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (52) EA products and management processes are subject 
to independent assessment; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (58) EA quality and results measurement 
methods are continuously improved; (59) EA continuous improvement 
efforts reflect the results of external assessments. 

Source: GAO. 

[End of table] 

EA Enabler Representation of Core Elements: 

This representation reflects four critical enablers (i.e., resources) 
within any organization that can be leveraged to effect change, 
produce outcomes, and accomplish desired goals and objectives. This 
representation is integral to other models and frameworks and has been 
used extensively by GAO in its analysis of a range of programs, such 
as our nation's elections system.[Footnote 36] (See table 5 for a 
presentation of the version 2.0 core elements using this 
representation.) The four organizational dimensions are as follows: 

* Leadership: Efforts and activities to assign senior executives 
responsibility and accountability for a given function, initiative, or 
program, including these executives' coordinated actions to guide, 
direct, oversee, and otherwise demonstrate their collective and 
individual ownership of the function, initiative, or program. 

* People: Efforts and activities to ensure that the function, 
initiative, or program has sufficient human capital, including 
individuals with the necessary knowledge, skills, and abilities. 

* Processes: Plans, policies, and procedures that govern how people 
are to execute the given function, initiative, or program. This 
organizational dimension also includes outputs of these plans, 
policies, and procedures, such as EA content. 

* Tools: Frameworks, methodologies, and repository and analytical 
tools used to assist people in executing processes. 

Table 5: EA Enabler Representation of the Critical Success Attributes 
and the Core Elements: 

Attribute 1: Leadership; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (1) 
Written and approved organization policy exists for EA development, 
maintenance, and use; (2) Executive committee representing the 
enterprise exists and is responsible and accountable for EA; (3) 
Executive committee is taking proactive steps to address EA cultural 
barriers; (4) Executive committee members are trained in EA principles 
and concepts; 
Stage 2: Creating the management foundation for EA development and 
use: (9) EA budgetary needs are justified and funded; 
Stage 3: Developing initial EA versions: (19) Organization business 
owner and CXO representatives are actively engaged in architecture 
development; 
Stage 4: Completing and using an initial EA version for targeted 
results: (33) Executive committee has approved the initial version of 
corporate EA; (34) Key stakeholders have approved the current version 
of subordinate architectures; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (44) Organization head has approved current version of 
the corporate EA; (45) Organization component heads or segment owners 
have approved current version of their respective subordinate 
architectures; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (53) EA is used by executive leadership to 
inform organization strategic planning and policy formulation. 

Attribute 2: People; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (5) 
Chief architect exists; 
Stage 2: Creating the management foundation for EA development and 
use: (10) EA program office(s) exists; (11) Key program office 
leadership positions are filled; (12) Program office human capital 
plans exist; 
Stage 3: Developing initial EA versions: (20) EA human capital plans 
are being implemented; (21) Program office contractor support needs 
are being met; (22) Program office staff are trained in EA framework, 
methodology, and tools; 
Stage 4: Completing and using an initial EA version for targeted 
results: (36) Program office human capital needs are met; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (47) Corporate and subordinate architecture program 
offices operate as a single virtual office that shares resources 
enterprisewide; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (54) EA human capital capabilities are 
continuously improved. 

Attribute 3: Processes; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (6) 
EA purpose is clearly stated; (8) EA performance and accountability 
framework is established; 
Stage 2: Creating the management foundation for EA development and 
use: (15) EA program management plan exists and reflects relationships 
with other management disciplines; (16) Work breakdown structure and 
schedule to develop EA exist; (17) EA segments, federation members, 
and/or extended members have been identified and prioritized; (18) 
Program office readiness is measured and reported; 
Stage 3: Developing initial EA versions: (25) EA-related risks are 
proactively identified, reported, and mitigated; (26) Initial versions 
of corporate "as-is" and "to-be" EA and sequencing plan are being 
developed; (27) Initial version of corporate EA describing the 
enterprise in terms of performance, business, data, services, 
technology, and security is being developed; (28) One or more segment 
and/or federation member architectures is being developed; (32) 
Architecture development progress is measured and reported; 
Stage 4: Completing and using an initial EA version for targeted 
results: (35) EA is integral to the execution of other institutional 
management disciplines; (37) Initial versions of corporate "as-is" and 
"to-be" EA and sequencing plan exist; (38) Initial version of 
corporate EA captures performance, business, data, services, 
technology, and security views; (39) One or more segment and/or 
federation member architectures exists and is being implemented; (40) 
EA product quality is measured and reported; (41) EA results and 
outcomes are measured and reported; (42) Investment compliance with 
corporate and subordinate architectures is measured and reported; 
(43) Subordinate architecture alignment with the corporate EA is 
measured and reported; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (48) Corporate EA and sequencing plan are 
enterprisewide in scope; (49) Corporate EA and sequencing plan are 
aligned with subordinate architectures; (50) All segment and/or 
federated architectures exist and are horizontally and vertically 
integrated; (51) Corporate and subordinate architectures are extended 
to align with external partner architectures; (52) EA products and 
management processes are subject to independent assessment; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (56) EA management processes are continuously 
improved and reflect the results of external assessments; (57) EA 
products are continuously improved and updated; (58) EA quality and 
results measurement methods are continuously improved; (59) EA 
continuous improvement efforts reflect the results of external 
assessments. 

Attribute 4: Tools; 
Stage 0: Creating EA awareness: [Empty]; 
Stage 1: Establishing EA institutional commitment and direction: (7) 
EA framework(s) is adopted; 
Stage 2: Creating the management foundation for EA development and 
use: (13) EA development and maintenance methodology exists; (14) 
Automated EA tools exist; 
Stage 3: Developing initial EA versions: (23) Methodologies and tools 
exist to determine investment compliance with corporate and 
subordinate architectures; (24) Methodologies and tools exist to 
determine subordinate architecture alignment with the corporate EA; 
(29) Architecture products are being developed according to the EA 
content framework; (30) Architecture products are being developed 
according to a defined EA methodology; (31) Architecture products are 
being developed using EA tools; 
Stage 4: Completing and using an initial EA version for targeted 
results: [Empty]; 
Stage 5: Expanding and evolving the EA and its use for institutional 
transformation: (46) Integrated repository tools and common EA 
framework and methodology are used across the enterprise; 
Stage 6: Continuously improving the EA and its use to achieve 
corporate optimization: (55) EA methodologies and tools are 
continuously improved. 

Source: GAO. 

[End of table] 

[End of section] 

Section 3: Uses of EAMMF Version 2.0: 

The EAMMF is intended to serve a wide range of stakeholders. For 
federal agencies, primary internal stakeholders are agency senior 
executives, including the agency head, business owners, and CXOs. 
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, 
such as inspectors general. 

As a model defining ascending levels of EA management maturity, the 
framework can be used by these stakeholders in two principal ways. 
First, it can provide a standard yet flexible benchmark against which 
to determine where the enterprise stands in its progress toward the 
ultimate goal: having a continuously improving EA program that can 
serve as a featured decision support tool when considering and 
planning large-scale organizational restructuring or transformation 
initiatives (maturity Stages 5 and 6). Second, it can provide a basis 
for developing architecture management improvement plans, as well as 
for measuring, reporting, and overseeing progress in implementing 
these plans. In either capacity, the EAMMF should not be viewed as 
either a rigidly applied checklist or as the only relevant benchmark 
for assessing and planning an EA program. Instead, it is intended to 
be applied flexibly with discretion in light of each organization's 
unique facts and circumstances, and it is intended to complement and 
augment other frameworks, such as OMB's EA Assessment Framework. 

Tool for Assessing EA Management Maturity: 

By describing the elements of an effective EA management program 
according to both a hierarchy of phases and accepted attributes of 
program and organizational success, the EAMMF provides a simplified 
and structured way to answer a very complex question--Where does an 
organization stand in its walk toward its EA destination? In so doing, 
it allows for the answer to be presented in terms of EA management 
strengths and weaknesses at both a single point in time and over a 
period of time, and for groups of enterprises to be assessed, 
represented, and compared. Further, it enables users to identify and 
understand these strengths and weaknesses in a range of contexts, such 
as in relation to other agencies in the same department, or other 
agencies of a similar size or that share a common mission (e.g., 
homeland security). 

In addition, the framework allows for this answer to be viewed in the 
context of hierarchical stages of progression. In doing so, however, 
it is not intended to prescribe rigid criteria governing what is 
needed to view a given program as having advanced to a given maturity 
stage. Rather, it allows the user to apply his or her own set of 
criteria, or to use multiple sets of criteria. In this regard, our 
reports have represented the application of the framework in three 
different ways: (1) requiring all core elements at a given stage to be 
met in order to achieve that stage of maturity; (2) requiring all core 
elements at a given stage to be at least partially met to achieve that 
stage of maturity; and (3) not using the maturity stages, and instead 
describing what portion of the core elements was met or partially met 
across all stages or within one or more critical success attributes. 
Thus, the value of the EAMMF goes beyond merely "grading" a given 
enterprise and extends to identifying the full range of specific EA 
program strengths and weaknesses (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 a cross- 
organization function (e.g., border security), an entire organization 
(e.g., a federal department), or a component organization (e.g., a 
branch, bureau, or agency). That is, the EAMMF is enterprise 
independent. The key consideration is to clearly understand and define 
the unit of assessment (i.e., the enterprise). Equally important is to 
understand and define the scope and depth of the assessment. This is 
because the purpose of the assessment and the needs of the framework's 
users can vary. As a result, not every EAMMF core element may be 
equally applicable to every enterprise, not every assessment has to 
consider every element, and not every assessment has to consider every 
element in the same level of detail. For example, a large and complex 
organization that is developing corporate, federated member, and 
segment architecture components, such as DOD or the Department of 
Homeland Security, might apply this entire framework, whereas a small 
organization developing a corporate architecture supplemented by 
several small segment architectures might apply a subset of the core 
elements. Moreover, the extent to which the framework is applied to 
subordinate architectures could also vary depending on the type of 
subordinate architecture (e.g., federated member or segment); the 
size, scope, and complexity of the subordinate organization; and needs 
of the framework user. Accordingly, the EAMMF does not presume a one-
size-fits-all application methodology or approach, and instead allows 
the framework users to decide how it will be applied and how the 
results will be interpreted, represented, and used. 

EA Management Improvement Planning: 

The EAMMF's seven stages of maturity provide a road map for 
incremental improvement. In using this road map for planning, it is 
important to recognize that certain core elements are inherently 
dependent on others, requiring an ordered approach, whereas others do 
not share such direct relationships, and thus the timing of their 
implementation is more flexible. It is also important to recognize 
that not every element will be applicable to every enterprise. 

Generally speaking, the core elements in the lower maturity stages 
provide the foundation for those at higher maturity stages. In fact, 
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 subjecting EA products and management processes to an 
independent assessment 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 they may not have satisfied all core 
elements at any one particular stage. 

Additionally, in using the EAMMF for improvement planning, it is 
important to remember that the framework describes what needs to be 
done, and not the details surrounding 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 is "implementable," an 
enterprise would need to augment the EAMMF with other guidance and 
frameworks that address, for example, the appropriate scope of work of 
an independent assessment agent or the attributes of an effective 
process for assessing a given investment's architectural compliance. 
In particular, implementing the EAMMF core elements related to 
architecture content need to be based on an EA content framework and 
associated methodology for developing architecture products and 
artifacts. 

[End of section] 

Appendix I: Approach to Developing EAMMF Version 2.0: 

This update of the Enterprise Architecture Management Maturity 
Framework (EAMMF) is based on our extensive experience in using 
version 1.1 in performing two governmentwide and numerous department-
and agency-specific enterprise architecture (EA) evaluations and our 
research of the evolving EA discipline. In addition, it is based on 
our solicitation of the comments and views of EA practitioners and 
related experts within all levels of government, academia, and the 
private sector. More specifically, we solicited comments and 
suggestions on version 1.1 from the 27 federal departments and 
agencies that participated in our 2006 governmentwide review of the 
state of the government's use of EA,[Footnote 37] and we obtained 
comments and suggestions on version 1.1 and a draft of version 2.0 
from members of GAO's Executive Council on Information Management and 
Technology (ECIMT).[Footnote 38] Collectively, we obtained about 175 
comments and suggestions that we have incorporated, as appropriate, in 
version 2.0. These comments and suggestions generally fall into six 
categories, as shown in table 6. 

Table 6: Categories of Comments and Suggestions Provided for Update of 
EAMMF Version 1.1: 

Category of comment or suggestion: 
Align with other frameworks (e.g., Information Technology Investment 
Management [ITIM] framework). 

Category of comment or suggestion: 
Align with other EA frameworks. 

Category of comment or suggestion: 
Incorporate federation, service orientation, and segmentation concepts. 

Category of comment or suggestion: 
Add, modify, or delete stages, attributes, or core elements. 

Category of comment or suggestion: 
Clarify expectations and add examples of deliverables. 

Category of comment or suggestion: 
Revise criteria for satisfying a given stage. 

Source: GAO. 

[End of table] 

Many of these comments and suggestions reflect new developments in the 
field of EA since we released version 1.1 of our EAMMF. For example, 
since 2003, many departments and agencies have adopted federated, 
segmented, and service-oriented approaches to developing their EAs, 
and both the Office of Management and Budget (OMB) and the Federal CIO 
Council have issued guidance on these approaches.[Footnote 39] 

Using these various inputs, we followed an evolutionary and agile 
approach to simultaneously redefining the framework's stages, core 
elements, and critical success attributes. In doing so, we developed a 
series of versions of the framework and analyzed each in the series 
for internal consistency and satisfaction of the comments and 
suggestions that we received, the experience that we gained from using 
the framework, and the research that we conducted around EA 
management. We then developed drafts of version 2.0 that we shared 
with GAO ECIMT members for comment, which we have incorporated as 
appropriate. 

[End of section] 

Appendix II: Framework Elements: 

The framework's core elements are the basic building blocks of the 
EAMMF. Each of the core elements is briefly described here, along with 
references to related guidance and frameworks. 

Core Elements: 

Core Element 1: Written and approved organization policy exists for EA 
development, maintenance, and use. 

An organization should have a documented policy, approved by the 
organization head, to institutionalize the architecture's importance, 
role, and relationship to other corporate management disciplines. 
Among other things, the policy should define the EA as consisting of 
the current ("as-is") and target ("to-be") architecture, as well as 
the transition plan for migrating from the current to the target 
architecture, and it should provide for EA development, maintenance, 
and use. The policy should also identify the major players associated 
with EA development, maintenance, and use, including the chief 
architect, program office(s), executive committee, investment review 
board(s), and CIO. It should provide for developing a performance and 
accountability framework that identifies each player's roles, 
responsibilities, and relationships and describes the results and 
outcomes for which each player is responsible and accountable. The 
policy should also acknowledge the interdependencies and relationships 
among the EA program and other related institutional management 
disciplines, such as strategic planning, human capital management, 
information security management, privacy, records management, and 
capital planning and investment control. 

Selected references: 

* CIO Council Practical Guide, section 3.1.2: "Issue an Executive 
Enterprise Architecture Policy." 

* GAO EAMMF, version 1.1: "Written and approved organization policy 
exists for EA development"; "Written and approved organization policy 
exists for EA maintenance"; and "Written and approved organization 
policy exists for IT investment compliance with EA." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 2: Executive committee representing the enterprise exists 
and is responsible and accountable for EA. 

An organization should assign responsibility and accountability for 
directing, overseeing, and approving the architecture not to just one 
individual, but to a formally chartered executive committee with 
active representation from across the enterprise. Establishing 
enterprisewide responsibility and accountability is important for 
demonstrating the organization's institutional commitment to EA and 
for obtaining buy-in from across the organization. Accordingly, this 
committee should be composed of 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. If the EA extends beyond traditional 
organizational boundaries (e.g., across multiple departments or 
agencies), this executive committee should also include executive 
representation from other related organizations. 

This committee, which is typically chartered by the head of the 
organization (e.g., the department or agency head), should be 
responsible for establishing the EA's purpose, goals, strategy, and 
performance and accountability framework, and for ensuring that EA 
plans, management processes, products, and results are achieved. To 
augment the executive committee, subordinate committees may also exist 
for federation, segment, and extended enterprise members. Such 
subcommittees should also define their respective roles, 
responsibility, authority, accountability, and relationship to other 
executive bodies. 

Selected references: 

* CIO Council Practical Guide, section 3.2.3: "Establish an EA 
Executive Steering Committee." 

* GAO EAMMF, version 1.1: "Committee or group representing the 
enterprise is responsible for directing, overseeing, and approving EA." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 3: Executive committee is taking proactive steps to 
address EA cultural barriers. 

Parochialism and cultural resistance to change are significant 
barriers to organizations having a mature EA. Accordingly, we have 
previously reported on the need for sustained executive leadership to 
overcome these and other barriers.[Footnote 40] Among other things, 
this can include proactive steps by the executive committee and its 
members to promote and reward EA-related collaboration across 
organizational boundaries, commit component organization resources to 
EA activities, and encourage the disclosure and adoption of EA shared 
services. Similarly, subordinate committees and their members should 
also take proactive steps to address cultural barriers. 

Selected reference: 

* CIO Council Practical Guide, section 3.2.3: "Establish an EA 
Executive Steering Committee." 

Core Element 4: Executive committee members are trained in EA 
principles and concepts. 

Executive committee members need to understand basic EA principles, 
structures, and concepts in order to effectively execute the 
committee's roles and responsibilities. Therefore, each committee 
member should complete sufficient training to provide the member with 
a basic understanding of the fundamentals of EA management, 
development, maintenance, and use. If applicable, such training should 
also provide committee members with a basic understanding of the 
organization's approach to identifying and developing subordinate 
architectures. If training is acquired commercially, steps should be 
taken to ensure that the training is appropriately tailored to the 
needs of organizational executives. Similarly, subordinate committee 
members should also receive targeted EA-related training. 

Selected references: 

* CIO Council Practical Guide, section 3.2.3: "Establish an EA 
Executive Steering Committee." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Capability Maturity Model® Integration (CMMI) for Development, 
version 1.2:[Footnote 41] "Organizational training process area." 

* GAO ITIM Framework, version 1.1: "Instituting the Investment Board." 

Core Element 5: Chief architect exists. 

A successful EA program should be led by an individual who is well 
versed and knowledgeable about all aspects of architecture 
development, maintenance, and use and who can serve as the interface 
between the organization's business and IT communities. Accordingly, 
an organization should have a chief architect who leads the corporate 
EA program office and who is responsible for EA development and 
maintenance and accountable to the executive committee. The chief 
architect is typically an organization executive whose background and 
qualifications span both the business and technology sides of the 
organization. Because the chief architect also typically serves as the 
EA program manager, this person should be knowledgeable about program 
management as well as capital planning and investment control, systems 
engineering, and organization and data modeling. The chief architect 
(in collaboration with the CIO, executive committee, and the 
organization head) is instrumental in obtaining organizational buy-in 
for the EA (including support from the business units) and in securing 
resources to support architecture management functions, such as risk 
management, configuration management, and quality assurance. As such, 
the chief architect acts as the corporate spokesperson and advocate 
for EA adoption. When federation and segmentation approaches are used, 
lead architects should also be designated for these component efforts 
and, like the chief architect, these lead architects should similarly 
be knowledgeable about and skilled in EA promotion, development, and 
use. 

Selected references: 

* CIO Council Practical Guide, section 3.2.4: "Appoint Chief 
Architect." 

* GAO EAMMF, version 1.1: "Chief architect exists." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Federal Segment Architecture Methodology, step 1: "Determine 
participants." 

Core Element 6: EA purpose is clearly stated. 

The purpose of the organization's EA drives virtually all aspects of 
how the EA program will be planned and executed, including the EA 
framework, methodology, plans, products, and tools. The purpose of an 
EA can range from consolidating the organization's IT infrastructure, 
to normalizing and integrating its data and promoting information 
sharing, to reengineering core business/mission functions and 
processes, to modernizing applications and sharing services, to 
modernizing the entire IT environment, and to transforming how the 
organization operates. Regardless of the purpose, which will in turn 
drive the expected value to be realized from the EA's implementation 
(e.g., reduced operating costs, enhanced ability to quickly and less 
expensively change to meet shifting external environment and new 
business demands/opportunities, improved alignment between operations 
and strategic goals and operations, etc.), it needs to be clearly 
defined by the executive committee and be communicated to and 
understood by all stakeholders and corporate and subordinate 
architecture staff. In addition, the purpose needs to be aligned with 
and supportive of the organization's overall strategic plan's goals, 
objectives, and outcomes, and it needs to be used to help establish 
the purpose of each subordinate architecture. 

Selected references: 

* CIO Council Practical Guide, section 4.1: "Define the Intended Use 
of the Architecture." 

* GAO EAMMF, version 1.1: "Written and approved organization policy 
exists for EA development." 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan"; section 
6.3.4: "Measuring EA Program Value." 

* Federal Segment Architecture Methodology, activity 1.2: "Develop the 
purpose statement for the segment." 

Core Element 7: EA framework(s) is adopted. 

To effectively and efficiently develop an EA, an organization should 
use an architecture framework, which can be viewed as an EA content 
taxonomy, to define the specification of the suite of EA products and 
artifacts to be developed, used, and maintained, and the relationships 
among them. As such, the framework is instrumental in promoting 
consistent and collaborative representations of architectural 
information across the organization. 

Our prior work has shown that organizations have experienced various 
levels of satisfaction in using a range of frameworks.[Footnote 42] 
Consequently, organizations need to carefully evaluate framework 
options to ensure that they effectively support achievement of the 
EA's stated purpose. 

Selected references: 

* CIO Council Practical Guide, section 4.5: "Evaluate and Select a 
Framework." 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 8: EA performance and accountability framework is 
established. 

Successfully managing any program, including an EA program, depends in 
part on establishing clear commitments and putting in place the means 
by which to determine progress against these commitments and hold 
responsible parties accountable for the results. Because the EA is a 
corporate asset, and its development and use are corporate endeavors 
involving a host of organizational players, a corporate approach for 
measuring EA progress, management capacity, quality, use, and results 
should be established that extends to all levels of the organization 
involved in the EA. In particular, it should recognize the critical 
roles and responsibilities of key stakeholders, including the 
executive committee, the CIO, the chief architect, investment review 
board(s), and all subordinate committees and architects, and it should 
provide the metrics and means for ensuring that these roles and 
responsibilities are fulfilled and any deviations from expectations 
are documented and disclosed. 

Selected 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." 

Core Element 9: EA budgetary needs are justified and funded. 

An organization should have sufficient resources to establish and 
execute its EA program. Accordingly, program plans and activities 
should be appropriately justified and adequately funded. Among other 
things, funding requests should be based on reliable program cost 
estimates and justified based on expected EA program benefits, such as 
improvements to organization efficiency, better product and/or service 
delivery, and reduced investment and/or operating costs. In so doing, 
the organization should recognize that its EA is an investment in its 
future, and thus the EA should be viewed as a capital asset whose cost 
is not solely a current period expense. By funding EA as a capital 
investment, an organization's leadership demonstrates its long-term 
commitment to having and using an EA to inform investment decision 
making and optimize mission-facing and mission-supporting operations. 

Selected references: 

* 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." 

* GAO EAMMF, version 1.1: "Adequate resources exist." 

* GAO, Cost Estimating and Assessment Guide: Best Practices for 
Developing and Managing Capital Program Costs, GAO-09-3SP, March 2009. 

Core Element 10: EA program office(s) exists. 

EA development and maintenance should be managed as a formal program. 
Accordingly, a corporate EA program management office should be 
chartered. While the program office is typically within the Office of 
the CIO, another organizational option is to place it under the 
purview of the organization's chief operating officer or chief 
management officer, and to align it closely with the organization's 
strategic planning or continuous process improvement functions. 
Regardless, the program office should be responsible to the EA 
executive committee for ensuring that those core elements that are 
within its span of authority and control, as discussed throughout this 
framework, are met. Among other things, this includes EA program 
planning and performance monitoring, EA development and maintenance 
using supporting tools, and EA quality assurance, configuration 
management, and risk management. The corporate program office can be 
augmented by subordinate architecture program offices or core teams 
responsible for their respective subordinate architecture programs, 
processes, and products. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5: "Establish an Enterprise 
Architecture Program Management Office." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Federal Segment Architecture Methodology, activity 1.3: "Solicit 
core team members." 

Core Element 11: Key program office leadership positions are filled. 

The chief architect designated in Stage 1 typically serves as the EA 
program office manager, and should be supported by a range of program 
office leadership positions (see table 7). 

Table 7: Examples of EA Program Management Office Leadership Positions: 

Position: Product-specific architects; 
Description: Develop architecture products such as business process 
models, data models, and technical reference models. 

Position: Risk manager; 
Description: Identifies, monitors, controls, and mitigates EA program 
risks in light of internal and external environmental factors (e.g., 
external business constraints and technical constraints). 

Position: Configuration manager; 
Description: Establishes and maintains the integrity of work products 
using configuration identification, configuration control, 
configuration status accounting, and configuration audits. 

Position: Quality assurance manager; 
Description: Defines, monitors, and enforces EA product quality 
standards, such as standards for completeness, usability, consistency, 
and accuracy. 

Source: GAO. 

[End of table] 

In filling these positions, the chief architect should leverage the 
program office's human capital management capabilities discussed in 
the next core element. Consistent with the corporate EA program 
office, subordinate architecture program offices or core teams should 
be led by their respective lead architects, all of whom should also 
ensure that their key leadership positions are filled. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5.1: "Appoint Key 
Personnel"; section 3.2.5.2. "Establish Enterprise Architecture Core 
Team." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO, A Model of Strategic Human Capital Management, GAO-02-373SP, 
March 2002; Human Capital: Key Principles for Effective Strategic 
Workforce Planning, GAO-04-39, December 2003. 

* Federal Segment Architecture Methodology, activity 1.3: "Solicit 
core team members." 

Core Element 12: Program office human capital plans exist. 

Having sufficient human capital to successfully develop and maintain 
the corporate EA is the responsibility of the chief architect, and it 
begins with identifying human capital needs and developing a plan for 
acquiring, developing, and retaining qualified staff with the 
requisite knowledge, skills, and abilities. The process of identifying 
program office human capital needs and developing a plan to address 
them should be governed by human capital management best practices, as 
defined in relevant guidance, such as GAO's Model of Strategic Human 
Capital Management and the Office of Personnel Management's (OPM) 
Human Capital Assessment Accountability Framework. This guidance can 
be applied to individual programs such as an EA program. In short, it 
provides for assessing existing human capital capabilities, defining 
needed capabilities, and performing a gap analysis to identify the 
positions that need to be filled and their required qualifications. 
The EA human capital plan is the vehicle for addressing identified 
gaps by, for example, training existing staff, hiring new staff, and 
using contract staff, and should also address staff retention, 
development, and recognition and reward. For organizations that have 
adopted, for example, a federated architecture approach, human capital 
planning for each subordinate architecture should also be performed. 
While the formality of these planning efforts will vary depending on 
the size, scope, and complexity of the respective architecture 
efforts, it is important that this planning reflect the basic tenets 
of effective human capital management provided in GAO and OPM guidance. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5.1: "Appoint Key 
Personnel"; section 3.2.5.2. "Establish Enterprise Architecture Core 
Team." 

* CMMI for Development, version 1.2: "Establish an Organizational 
Training Capability." 

* GAO, A Model of Strategic Human Capital Management, GAO-02-373SP, 
March 2002; Human Capital: Key Principles for Effective Strategic 
Workforce Planning, GAO-04-39, December 2003. 

* OPM, Human Capital Assessment and Accountability Framework. 

Core Element 13: EA development and maintenance methodology exists. 

An EA methodology defines the steps to be followed to generate and 
sustain the desired set of architecture artifacts, as identified in 
the EA framework(s). As such, the methodology or methodologies that 
corporate and subordinate program offices select and employ should 
address how the architecture products provided for in the selected EA 
content framework will be developed and maintained to ensure that they 
are, among other things, consistent, complete, aligned, integrated, 
and usable. Because of its pivotal role, the methodology should be 
documented, understood, and consistently applied, and should provide 
the standards, tasks, tools, techniques, and measures to be followed 
in developing and maintaining the architecture products. 

One example of an architecture methodology is the Federal Segment 
Architecture Methodology. According to OMB and the CIO Council, this 
methodology provides steps for developing a core mission area segment 
architecture and includes guidance for tailoring the approach to 
develop business service and enterprise service segment adaptations. 

Selected references: 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 14: Automated EA tools exist. 

Information about how the enterprise operates is captured and 
maintained in a variety of sources, such as the business vision 
statement, business strategy, performance and accountability plans and 
reports, policies, procedures, and guidance. Assimilating this 
information to support organizational transformation by creating a 
holistic view of the current and future state of the enterprise can be 
a challenging endeavor. Automated tools support this endeavor by 
assisting in the process of extracting, assimilating, relating, and 
presenting this organizational information. Automated EA tools can be 
used to graphically and textually capture information described by the 
framework, such as information or activity models, and can assist in 
developing, communicating, storing, structuring, relating, accessing, 
and maintaining the architecture products described in the EA 
framework and methodology (e.g., business process models and data 
models). 

Our prior work has shown that federal agencies have experienced 
various levels of satisfaction in using a variety of EA tools. 
[Footnote 43] As a result, organizations should carefully consider 
their options when selecting EA modeling and/or repository tools. 
Table 8 lists a number of factors to consider in selecting tools. 

Table 8: Factors to Consider in Selecting EA Modeling and Repository 
Tools: 

Factors: 

Ability to import existing models.
Ability to tailor EA information to stakeholder needs.
Analytical needs and capabilities.
Available platforms.
Configuration management support.
Cost and licensing.
Degree of customization required.
EA program maturity.
Framework support.
Integrated and consolidated repository.
Interoperability with other tools/repositories.
Model size and complexity.
Modeling methods and techniques support.
Quality assurance support.
Risk management and issue tracking support.
Traceability to requirements and other enterprise engineering artifacts.
Training schedule, cost, and length.
Vendor support. 

Source: CIO Council. 

[End of table] 

Selected references: 

* CIO Council Practical Guide, section 4.6: "Select an EA Toolset." 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 15: EA program management plan exists and reflects 
relationships with other management disciplines. 

An EA program management plan should describe the means by which the 
corporate EA program will be managed. As such, this plan defines the 
range of management structures, controls, disciplines, roles, and 
accountability mechanisms discussed throughout the EAMMF. Moreover, 
the plan should describe, at least notionally, the major EA releases 
or increments to be developed, and in doing so, should be aligned with 
the EA frameworks and methodologies to be employed. In addition, the 
plan should be approved by the chief architect and the executive 
committee, and it should address how EA program management will be 
performed in concert with other institutional management disciplines, 
such as organizational strategic planning, strategic human capital 
management, performance management, information security management, 
and capital planning and investment control. While the program 
management plan can be self-contained, it can also be supported by 
subordinate plans that more specifically address key EA management 
areas, such as an organization communication plan, a human capital 
management plan, a configuration management plan, a risk management 
plan, and a quality assurance plan. 

Selected references: 

* CIO Council Practical Guide, section 3.3.2: "Develop an EA Program 
Management Plan." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists"; "EA products are under 
configuration management"; "Progress against EA plans is measured and 
reported"; "Process exists to formally manage EA change." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Federal Segment Architecture Methodology, activity task 1.4.2: 
"Create project plan for segment architecture development." 

Core Element 16: Work breakdown structure and schedule to develop EA 
exist. 

Each program management plan should be supplemented by a work 
breakdown structure that decomposes the specific tasks, activities, 
and events needed to execute the program, as well as a reliable 
schedule that defines the timing, sequencing, and duration of the 
tasks, activities, and events. Among other things, the selected EA 
framework and methodologies as well as the program management plan 
should help to inform the work breakdown structure and schedule. 

Because the EA program is a major organizational undertaking, both in 
terms of significance and of resources, the work breakdown structure 
and schedule should be derived in accordance with best practices, as 
provided in GAO's Cost Estimating and Assessment Guide.[Footnote 44] 
According to this guidance, the work breakdown structure is to provide 
a clear picture of what needs to be accomplished to develop a program 
and provide a basis for identifying resources and tasks for developing 
a cost estimate. In addition, the success of any program depends in 
part on having a reliable schedule that defines, among other things, 
when work activities will occur, how long they will take, and how they 
are related to one another. As such, the schedule not only provides a 
road map for the systematic execution of a program, but also provides 
the means by which to gauge progress, identify and address potential 
problems, and promote accountability. 

Selected references: 

* CIO Council Practical Guide, section 3.3.2: "Develop an EA Program 
Management Plan." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Federal Segment Architecture Methodology, activity task 1.4.2: 
"Create project plan for segment architecture development." 

* GAO, Cost Estimating and Assessment Guide: Best Practices for 
Developing and Managing Capital Program Costs, GAO-09-3SP, March 2009. 

Core Element 17: EA segments, federation members, and/or extended 
members have been identified and prioritized. 

Organizations that adopt segmented or federated architecture 
approaches should identify and prioritize their subordinate or member 
architecture components. The initial identification and prioritization 
of components should be performed by the corporate EA program office 
and approved by the executive committee. Factors that should be 
considered in identifying, prioritizing, and approving segments and 
federation members include strategic improvement opportunities, needs 
and performance gaps, organizational structures and boundaries, 
relevant legislation and executive orders, and key component 
organizational and program dependencies. Consistent with the EA 
communication plan, organizations should ensure that these priorities 
are communicated throughout the organization. 

Selected reference: 

* OMB Federal Enterprise Architecture Practice Guidance, "Initiating 
Segment Architecture." 

Core Element 18: Program office readiness is measured and reported. 

The capacity of the corporate and subordinate EA program offices to 
manage their respective EA programs will largely be determined by the 
organization's satisfaction of the Stage 2 core elements. Thus, it is 
important to measure and understand the extent to which the 
framework's people, processes, and tools enablers have been put in 
place and to share this readiness information with the executive 
committee, chief architect, and subordinate architects. 

Core Element 19: Organization business owner and CXO representatives 
are actively engaged in architecture development. 

Because the scope of the EA is organizationwide, its stakeholders 
include all business owners and chief "X" officers (CXO).[Footnote 45] 
While many of these senior executives will be engaged in the EA 
program as members of the executive committee, it is equally important 
that their representatives, as subject matter experts, be actively 
engaged with EA program staff in developing the corporate and 
subordinate architecture products, particularly those products that 
capture information that is best known and understood by the subject 
matter experts. As such, these representatives should be assigned to 
the appropriate corporate and subordinate program offices and should 
work with the architecture staff in developing EA products. For an 
organization whose EA scope extends to other external organizations, 
the chief architect should work with his or her counterpart in these 
other organizations to ensure interorganizational EA alignment. 

Selected references: 

* CIO Council Practical Guide, section 3.1.3: "Obtain Support from 
Senior Executives and Business Units"; section 3.3.1: "Develop an EA 
Marketing Strategy and Communications Plan." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* Federal Segment Architecture Methodology, activity 1.3: "Solicit 
core team members"; task 2.1.3: "Identify stakeholders"; task 2.2.2: 
"Determine stakeholders' needs." 

Core Element 20: EA human capital plans are being implemented. 

Corporate and subordinate EA program offices should be staffed with 
employees with the knowledge, skills, and abilities needed to manage 
the EA program, including the means by which to oversee and manage 
contractors that are tasked with delivering EA product content or 
supporting EA management functions. To accomplish this, the program 
office(s) should have begun to implement the human capital plans 
developed in Stage 2, to include hiring and training staff in a manner 
consistent with the approved plan. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5: "Establish an Enterprise 
Architecture Program Management Office." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO, A Model of Strategic Human Capital Management, GAO-02-373SP, 
March 2002; Human Capital: Key Principles for Effective Strategic 
Workforce Planning, GAO-04-39, December 2003. 

Core Element 21: Program office contractor support needs are being met. 

Contractor support is an integral component of program office human 
capital capacity. For example, all federal departments and agencies 
included in our 2006 EA management survey reported developing their 
EAs using contractor support, which accounted for the majority of the 
agencies' EA development costs.[Footnote 46] Accordingly, the 
corporate and subordinate program offices need to ensure that the 
human capital plan's provisions for contractor support are implemented 
so that the appropriate degrees of contractor expertise, skills, and 
competencies are acquired and assimilated into the program office. 

As we have previously reported,agencies should use performance-based 
contracting to the maximum extent practicable when acquiring EA 
contract support.[Footnote 47] Further, agencies should follow 
relevant acquisition management guidance pertaining to contractor 
tracking and oversight, to include, among other things, 

* establishing a written policy for contract tracking and oversight, 

* designating responsibility for contract tracking and oversight 
activities, 

* establishing a group that is responsible for managing contract 
tracking and oversight activities, and: 

* using approved contractor planning documents as a basis for tracking 
and overseeing the contractor. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5: "Establish an Enterprise 
Architecture Program Management Office." 

* GAO, A Model of Strategic Human Capital Management, GAO-02-373SP, 
March 2002; Human Capital: Key Principles for Effective Strategic 
Workforce Planning, GAO-04-39, December 2003. 

* Federal Acquisition Regulation, section 37.102(a) and part 46, 
"Quality Assurance." 

Core Element 22: Program office staff are trained in EA framework, 
methodology, and tools. 

Corporate and subordinate program office staff, including support 
contractor staff, should understand the framework, methodology, and 
automated tools that are to be used to develop and maintain the EA 
products. Consequently, consistent with the program's human capital 
management plan, steps should be taken to define and deliver training 
to meet these needs. Such training, whether provided by program office 
staff, a contractor, or both, should be customized to the program's 
selected EA framework, methodology, and tools, and should include a 
means for ensuring that sufficient staff understanding has been 
achieved. Further, the training should be tailored to specific staff 
roles and responsibilities. 

Selected references: 

* CIO Council Practical Guide, section 6.1.1: "Train Personnel." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 23: Methodologies and tools exist to determine investment 
compliance with corporate and subordinate architectures. 

An organization's investments should be aligned with and comply with 
the applicable components (e.g., business, information/data, 
technical) of the current version of the corporate and subordinate 
architectures and should not be selected and approved under the 
organization's capital planning and investment control (i.e., 
investment management) approach unless such compliance is documented 
by the investment sponsor, substantiated by the architecture 
assessment team, and approved by the investment review board(s). 
Accordingly, organizations should document and consistently apply a 
methodology and supporting tools for assessing investments' 
architectural compliance. Among other things, the methodology should 
focus on the relevant architecture artifacts in the current versions 
of both the corporate and subordinate EAs, as applicable. Further, 
architectural compliance should be integrated with and reflected in 
the investment management and system life cycle management processes. 
As we have previously reported, investment compliance with the EA is 
not a onetime event, but rather is a key decision consideration at 
each major investment milestone, and the EA artifacts that apply will 
vary as the investment proceeds through its life cycle. In addition, 
the methodology and tool should not treat alignment as a binary--yes 
or no--determination, but rather should treat areas of noncompliance 
and misalignment as individual areas of risk, which collectively form 
a composite architecture compliance risk that should be disclosed to 
investment decision makers and proactively managed. The methodology 
should allow exceptions to architecture compliance only on the basis 
of compelling analytical justification and should state that such 
exceptions are captured in documented EA waivers that are in turn used 
to update the EA. 

Selected references: 

* CIO Council Practical Guide, section 6.1: "Integrate the EA with 
Capital Planning and Investment Control and System Lifecycle 
Processes"; section 6.1.2: "Establish Enforcement Processes and 
Procedures." 

* GAO EAMMF, version 1.1: "IT investments comply with EA." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO ITIM Framework, version 1.1: "Selecting an Investment"; 
"Defining the Portfolio Criteria"; "Creating the Portfolio." 

Core Element 24: Methodologies and tools exist to determine 
subordinate architecture alignment with the corporate EA. 

An organization's subordinate architectures should be aligned with the 
corresponding components (e.g., business, information/data, technical) 
of the current version of its corporate EA. Such alignment will help 
in identifying the linkages between the subordinate architectures and 
the corporate EA, provide for sharing common applications and systems 
across the organization, and promote interoperability and data sharing 
among related programs. Accordingly, organizations should document and 
consistently apply a methodology and supporting tools to assess 
subordinate architecture alignment with the corporate EA. As is the 
case with investment compliance with the EA, the methodology and tools 
should recognize that alignment among architectures is a continuous 
risk-based determination that needs to be mitigated and disclosed to, 
among others, the executive committee. 

Selected reference: 

* GAO, Business Systems Modernization: Strategy for Evolving DOD's 
Business Enterprise Architecture Offers a Conceptual Approach, but 
Execution Details Are Needed, GAO-07-451, April 2007. 

Core Element 25: EA-related risks are proactively identified, 
reported, and mitigated. 

Like any program that involves the development and maintenance of an 
enterprise asset, an EA program is intended to deliver specific 
capabilities and expected mission benefits for an estimated cost 
according to a defined schedule. Accordingly, an EA program will face 
a myriad of risks that might affect the accomplishment of these 
commitments and thus should be proactively managed. These risks should 
be formally managed in accordance with relevant risk management 
guidance.[Footnote 48] 

To the extent that any of the core elements in this framework are not 
being satisfied, a risk to the program will exist, although the 
severity of the risk may vary depending on the specific core element. 
For example, an organization that has developed an EA compliance 
methodology and associated tools, but lacks important information, 
data, or technology content in its EA, risks developing systems that 
are not defined and designed in a manner that promotes 
interoperability. 

Selected references: 

* CMMI for Development, version 1.2: "Risk Management Process Area." 

* Federal Segment Architecture Methodology, task 2.2.3: "Identify 
segment risks and impacts." 

* GAO EAMMF, version 1.1: "Program office responsible for EA 
development and maintenance exists." 

Core Element 26: Initial versions of corporate "as-is" and "to-be" EA 
and sequencing plan are being developed. 

As we have previously reported, EA development typically occurs in an 
incremental fashion, whereby an initial version is developed as the 
foundation upon which to evolve and build increasingly more 
comprehensive, detailed, and complete versions.[Footnote 49] To create 
this initial version, the corporate EA program office should leverage 
the range of people, process, and tool enablers discussed in the Stage 
2 and 3 core elements (e.g., human capital frameworks, methodologies, 
modeling tools, repositories), and it should do so in accordance with 
the management plans, budgets, and schedules also discussed as part of 
these Stage 2 and 3 core elements. Further, it is imperative that the 
initial version of the corporate EA be enterprisewide in scope, and 
that it describe both the current ("as-is") environment and the future 
("to-be") environment, as well as a plan for moving from the current 
to the target environment. (See later core elements for further 
details on the content of these descriptions and this plan.) 

Selected references: 

* 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"; 
section 5.3.1: "Identify Gaps; Section 5.3.2: Define and Differentiate 
Legacy, Migration, and New Systems"; section 5.3.3: "Planning the 
Migration." 

* GAO EAMMF, version 1.1: "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." " 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan." 

Core Element 27: Initial version of corporate EA describing the 
enterprise in terms of performance, business, data, services, 
technology, and security is being developed. 

In Stage 3, development of the initial version of the corporate EA 
should begin in earnest and should include the full range of 
conceptual models that are provided for in the selected EA content 
framework(s). At a minimum, this content should address the following 
key aspects of the enterprise: corporate performance, operations, 
information/data, applications/services, technology, and security. As 
a general rule, the corporate EA need only contain that thin layer of 
corporate outcomes, policies, rules, standards, and protocols that all 
component parts or slices will be expected to adopt and reflect. 

Selected references: 

* CIO Council Practical Guide, section 5.2.1: "Essentials in Building 
the Baseline Architecture"; section 5.2.2: "Essentials in Building the 
Target Architecture." 

* GAO EAMMF, version 1.1: "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." 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan." 

Core Element 28: One or more segment and/or federation member 
architectures is being developed. 

As we have previously reported, successful EA development for large, 
complex federal agencies does not involve an "all-or-nothing," 
monolithic approach.[Footnote 50] Rather, EA development typically 
follows a "divide and conquer" strategy in which the level of 
architectural detail needed to guide and constrain individual 
investments is created for distinct organizational components or 
functional slices of the enterprise (i.e., "children") and in a way 
that ensures that the distinct parts or slices are architecturally 
aligned with the organization's corporate (i.e., "parent") EA. In 
general, these children can be viewed as either enterprise segments or 
federated members.[Footnote 51] In taking one or both of these 
approaches, the EA is developed incrementally through segmented and/or 
federated architectures that are consistent and aligned with an 
overall corporate EA and developed according to the priorities defined 
in Stage 2. In so doing, the level of architectural content that needs 
to be defined to sufficiently inform high-priority, near-term system 
investments can be established relatively quickly, thus allowing the 
benefits of the EA to be realized sooner rather than later. 

Selected references: 

* OMB Federal Enterprise Architecture Practice Guidance, "Initiating 
Segment Architecture." 

* CIO Council, "Federal Segment Architecture Methodology," Dec. 2008. 

Core Element 29: Architecture products are being developed according 
to the EA content framework. 

To varying degrees, EA content frameworks identify the collection of 
architecture artifacts that are to be developed as well as the 
relationships and dependencies that exist among these artifacts. For 
example, a framework may include an artifact that describes 
information exchanges among operational activities, and the 
information being exchanged in this artifact may link to data elements 
described in a conceptual data model artifact. Accordingly, the 
initial version of the corporate and subordinate EAs developed during 
this stage should consist of the set of products that are provided for 
in the selected content framework(s) being used. By doing so, 
architecture content across the organization can be transparent to and 
understood by those responsible for using it, thereby increasing the 
chances that the products will meet key quality attributes (i.e., 
consistency, usability, etc.). 

Selected references: 

* CIO Council Practical Guide, section 4.5: "Evaluate and Select a 
Framework." 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 30: Architecture products are being developed according 
to a defined EA methodology. 

The purpose of the EA methodology is to provide architecture players 
and stakeholders with a shared understanding of the architecture 
development approach, including defined steps, tasks, standards, 
tools, techniques, and measures that are to be used to create the 
specified EA products. Through such an understanding, a repeatable and 
consistent process to product development can result. To accomplish 
this, the initial versions of the corporate and subordinate EAs being 
developed during this stage should be developed in accordance with the 
selected methodology or methodologies. 

Selected references: 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 31: Architecture products are being developed using EA 
tools: 

Developing the corporate and subordinate EA products specified in the 
selected content framework and executing the methodology for 
developing these products is a complex and resource-intensive 
undertaking. To assist in meeting this challenge, EA development tools 
should be effectively leveraged to help capture and relate defined 
corporate and subordinate architecture product content and to help 
ensure the content's completeness, accuracy, usability, and 
consistency. A range of automated modeling and repository tools, as 
discussed earlier, exists to perform these functions. Steps should be 
taken to ensure the full and necessary utilization of these tools. 

Selected references: 

* CIO Council Practical Guide, section 4.6: "Select an EA Toolset." 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 32: Architecture development progress is measured and 
reported. 

A key aspect of managing the range of activities under way during this 
stage is to track and disclose the progress being made in completing 
them. To accomplish this, execution and completion of corporate and 
subordinate architecture tasks defined in the EA program plan, work 
breakdown structure, and schedule, as well as their associated costs, 
should be measured relative to existing commitments, and this progress 
should be reported through the chief architect to the executive 
committee. Through such progress measurement and reporting, deviations 
from expectations can be identified, corrective action to address the 
root cause of any deviations can be taken, and responsible persons can 
be held accountable for achieving approved commitments. 

Selected references: 

* 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." 

* GAO EAMMF, version 1.1: "Progress against EA plans is measured and 
reported." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 33: Executive committee has approved the initial version 
of corporate EA. 

As we have previously reported, a corporate EA represents the thin 
layer of policies, capabilities, and standards that apply across an 
organization and need to be adopted by and reflected in all 
subordinate architectures. As the entity ultimately accountable for EA 
development and maintenance, the executive committee should review and 
approve the initial release of the corporate EA and all subsequent 
major releases. Such approval demonstrates institutional buy-in and 
commitment to the architecture, and thus facilitates organizationwide 
acceptance and use of the EA. 

Selected references: 

* CIO Council Practical Guide, section 5.4: "Approve, Publish, and 
Disseminate the EA Products." 

* GAO EAMMF, version 1.1: "Committee or group representing the 
enterprise or the investment review board has approved current version 
of EA." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 34: Key stakeholders have approved the current version of 
subordinate architectures. 

As the entities who will be ultimately accountable for implementing 
solutions associated with the subordinate architectures, each 
subordinate architecture's core team and key stakeholders, such as the 
affected business owners and/or executive sponsors, should review and 
approve the initial release of the subordinate architecture and all 
subsequent major releases. Such approval denotes buy-in of affected 
organizational entities, and thus facilitates acceptance and use of 
the subordinate architectures. 

Selected references: 

* CIO Council Practical Guide, section 5.4: "Approve, Publish, and 
Disseminate the EA Products." 

* Federal Segment Architecture Methodology, activity 5.4: "Brief core 
team and obtain approval." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 35: EA is integral to the execution of other 
institutional management disciplines. 

EA is one of several interrelated institutional management disciplines 
that collectively provide the means for an organization to be 
successful in meeting its mission goals and target outcomes. Among 
others, these disciplines include strategic planning, human capital 
management, capital planning and investment control, system 
development and acquisition management, enterprise risk management, 
and performance management. EA is a contributor to many of these 
disciplines. In particular, it provides the bridge between strategic 
planning and program implementation, it informs human capital 
strategic planning and capital planning and investment control 
decision making, and it provides a critical underpinning to 
institutional performance management. As a result, the EA should be an 
integral input into the execution of each of these management 
disciplines. 

Selected references: 

* CIO Council Practical Guide, section 2.5: "The Enterprise Life 
Cycle"; section 6.1: "Integrate the EA with Capital Planning and 
Investment Control and Systems Life Cycle Processes." 

* GAO EAMMF, version 1.1: "EA is integral component of IT investment 
management process." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO ITIM Framework, version 1.1: "Providing Investment Oversight." 

Core Element 36: Program office human capital needs are met. 

Having filled its key leadership positions and developed and 
implemented its human capital plans, the corporate and subordinate EA 
program offices have now acquired, either through training, direct 
hiring, organizational transfer, or contracting, the people that they 
need to execute the organization's EA program plans and schedules. 
Collectively, these people should possess the knowledge, skills, and 
abilities required to execute the functions and associated roles and 
responsibilities that formed the basis for the capability gap analysis 
in the human capital strategic plan developed during Stage 2. 

Selected references: 

* CIO Council Practical Guide, section 3.2.5: "Establish an Enterprise 
Architecture Program Management Office." 

* GAO EAMMF, version 1.1: "Adequate resources exist." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO, Human Capital: Key Principles for Effective Strategic Workforce 
Planning, GAO-04-39, December 2003. 

Core Element 37: Initial versions of corporate "as-is" and "to-be" EA 
and sequencing plan exist. 

As noted earlier, EA development typically occurs on an incremental 
basis. Consequently, a commonly practiced approach to developing and 
using an EA is to produce progressively more content-rich EA versions. 
The initial version of the EA is perhaps the most difficult and 
important step in this progression because it is in developing this 
version that the range of EA development enablers (people, processes, 
and tools) are first utilized, and it is this initial version that 
forms the basis for both developing the subordinate architectures of 
the EA and initial implementation of modernization and transformation 
solutions. As a result, it is extremely important that this initial 
version either be enterprisewide in scope and contain sufficient 
detail surrounding the principles, goals, measures, policies, rules, 
standards, protocols, etc. that will apply across the enterprise, or 
that it clearly disclose what scope and details are missing and in 
which subsequent version this content is expected to be added. As 
such, the initial version should not be viewed as a finished product 
but rather it should be viewed as a foundation upon which to 
architecturally build and evolve while also guiding and directing 
targeted initial subordinate EAs and solution development. The initial 
version, as with most long-term plans, will evolve and change over 
time (mature) as more is learned about near-term investments and 
initiatives, and as priorities funding availability change. 

An organization should complete the initial version of its corporate 
EA products according to defined plans and schedules and using 
acquired people, processes, and tools. These products should, at a 
minimum, include artifacts applicable to both the "as-is" and the "to-
be" environments of the enterprise, as well an initial version of a 
sequencing plan that provides a high-level investment road map for 
migrating between the two environments. While this sequencing plan 
should also not be viewed as a finished product, it should 
nevertheless provide a solid basis upon which to build and should 
reflect, among other things, governmentwide and agency-specific 
priorities (e.g., open and transparent government), notional 
dependencies among investments, conceptual expectations about 
investment costs and benefits, and emerging and available 
technological opportunities (e.g., cloud computing). 

Selected references: 

* 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; 
section 5.3.1: Identify Gaps"; section 5.3.2: "Define and 
Differentiate Legacy, Migration, and New Systems"; section 5.3.3: 
"Planning the Migration." 

* GAO EAMMF, version 1.1: "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."" 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan." 

Core Element 38: Initial version of corporate EA captures performance, 
business, data, services, technology, and security views.[Footnote 52] 

While the initial version of the corporate EA is not expected to be 
fully defined at this juncture, it nevertheless should capture and 
disclose EA information within the context of models and associated 
narrative. While the specific models will vary depending on the EA 
content framework being used, these models should nevertheless provide 
one or more interrelated representations and varying levels of 
abstraction of the enterprise's business operations, performance 
measurement approach, information and data needs and definitions, 
application and service delivery vehicles, technology profiles and 
standards, and security characteristics. Among other things, these 
models or architectural artifacts will establish the authoritative 
frames of reference that are not only interrelated with one another, 
but also aligned with and consistent with the subordinate 
architectures. 

Selected references: 

* CIO Council Practical Guide, section 5.2.1: "Essentials in Building 
the Baseline Architecture"; section 5.2.2: "Essentials in Building the 
Target Architecture." 

* GAO EAMMF, version 1.1: "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." 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan." 

Core Element 39: One or more segment and/or federation member 
architectures exists and is being implemented. 

As discussed in the preceding elements, an organization's corporate EA 
captures key information about the current and future state of the 
enterprise as a whole and should provide the basis for informing the 
enterprise's subordinate architectures and related solution 
implementations. These subordinate architectures, such as segment 
architectures or federated member architectures, should, in turn, 
capture architectural information that is relevant to that specific 
segment or organizational components, such as a business mission or 
function (e.g., financial management) or a subagency or bureau that is 
needed to guide and constrain investment solutions that apply to that 
specific mission area or organizational component. Accordingly, in 
Stage 4, the organization should have developed and begun implementing 
one or more segment and/or federation member architectures on a 
targeted and prioritized basis in order to begin achieving its 
modernization and transformation goals and outcomes. 

Selected reference: 

* OMB Federal Enterprise Architecture Practice Guidance, "Initiating 
Segment Architecture." 

Core Element 40: EA product quality is measured and reported. 

Realizing an EA's value depends in large part on the quality of the 
products or artifacts that compose it. As a result, an organization 
should ensure that corporate and subordinate architecture content is 
measured against the quality standards (i.e., metrics) that should be 
defined in the EA development and maintenance methodology. Generally, 
these quality standards should address, at a minimum, product 
completeness, usability, consistency, and accuracy. Moreover, the 
results of EA product quality measurement activities should be 
disclosed to the appropriate officials to inform decision making and 
permit timely corrective action. For example, these metrics should be 
shared with the executive committee when it is being asked to approve 
the initial version of the EA or a subsequent update. 

Selected references: 

* 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." 

* GAO EAMMF, version 1.1: "Quality of EA products is measured and 
reported." 

Core Element 41: EA results and outcomes are measured and reported. 

The EA is a strategic asset that represents an investment in the 
organization's future. Restated, an EA is a corporate investment that 
is to produce strategic mission value (results and outcomes). As a 
result, measuring the extent to which this expected value is actually 
being realized is important to identifying what, if any, EA program 
changes are warranted. Moreover, examples of positive results and 
outcomes can be used to economically justify expanded EA development 
and use.[Footnote 53] As a result, corporate and subordinate EA 
results and outcomes should be periodically measured and reported to, 
among others, the executive committee. Examples of results and 
outcomes to be measured include costs avoided through eliminating 
duplicative investments or by reusing common services and applications 
and improved mission performance through reengineered business 
processes and modernized supporting systems. 

Selected references: 

* 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." 

* GAO EAMMF, version 1.1: "Return on EA investment is measured and 
reported." 

* OMB EA Assessment Framework, version 3.1, section 6.3.1: "Mission 
Performance"; section 6.3.2: "Cost Savings and Cost Avoidance"; 
section 6.3.4: "Measuring EA Program Value." 

Core Element 42: Investment compliance with corporate and subordinate 
architectures is measured and reported. 

Realization of an EA's strategic value depends on its use. This use is 
achieved by, among other things, requiring that investments comply 
with EA products or that they receive an explicit waiver from such 
compliance. Given the importance of EA investment compliance, 
organizations should develop metrics for measuring the extent to which 
this occurs and periodically report these metrics to, among others, 
the executive committee and the organization's investment review 
board(s). Examples of such metrics for a given reporting period 
include the number of new and ongoing investments that have been 
assessed for architecture compliance, the results of these 
assessments, and the number of compliance waivers requested versus the 
number granted. By measuring and reporting investment compliance, an 
organization can be positioned to identify relevant trends and 
anomalies and take corrective action, if warranted. 

Selected references: 

* CIO Council Practical Guide, section 6.1: "Integrate the EA with 
Capital Planning and Investment Control and System Lifecycle 
Processes"; section 6.2: "Execute the Integrated Process." 

* GAO EAMMF, version 1.1: "IT investments comply with EA"; "Compliance 
with EA is measured and reported." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

* GAO ITIM Framework, version 1.1: "Selecting an Investment." 

Core Element 43: Subordinate architecture alignment with the corporate 
EA is measured and reported. 

Successful EA development typically follows an approach in which the 
level of architectural detail needed to guide and constrain individual 
investments is created for distinct parts of the organization (i.e., 
children) and in a way that ensures that the distinct organizational 
parts are architecturally aligned with the organization's corporate 
(i.e., parent) EA. These children can be viewed as the earlier 
discussed subordinate architectures, which include the enterprise 
segments or federation members. Consequently, subordinate architecture 
alignment with the corporate EA is key to ensuring that architecture 
benefits, such as improving interoperability and reducing overlaps and 
gaps, are achieved across the enterprise. To ensure that this is 
accomplished, subordinate (child) architecture alignment with the 
corporate (parent) EA should be periodically measured and reported to, 
among others, the executive committee and the organization's 
investment review boards. Examples of metrics that can be used for 
determining subordinate architecture alignment include the percentage 
of relevant entities (e.g., operational activities, mission or 
business functions, data elements) in a subordinate architecture that 
are aligned with strategic missions and goals described in the 
corporate EA and the status of efforts to develop those subordinate 
architectures that have been identified as high priority in the 
corporate EA. As a byproduct of implementing segmented or federated 
architectures and steps taken to ensure alignment, an organization may 
also identify areas at the subordinate level that are different from 
the corporate architecture and may require a waiver. Thus, situations 
may arise where those responsible for the corporate architecture need 
to be petitioned for changes to the content of the corporate EA. 

Selected reference: 

* GAO, Business Systems Modernization: Strategy for Evolving DOD's 
Business Enterprise Architecture Offers a Conceptual Approach, but 
Execution Details Are Needed, GAO-07-451, April 2007. 

Core Element 44: Organization head has approved current version of the 
corporate EA. 

The current version of the corporate EA should ultimately be approved 
by the head of the organization. Among other things, this approval 
should be based on a recommendation from the executive committee that 
is grounded in evidence that EA quality measures have been met. Such 
approval recognizes and endorses the corporate architecture for what 
it is intended to be--an institutional tool for managing both business 
and technological change and transformation. 

Selected references: 

* CIO Council Practical Guide, section 5.4: "Approve, Publish, and 
Disseminate the EA Products." 

* GAO EAMMF, version 1.1: "Organization head has approved current 
version of EA." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 45: Organization component heads or segment owners have 
approved current version of their respective subordinate architectures. 

For the same reasons that the corporate EA should be approved by the 
organization head, the latest version of each subordinate architecture 
should be approved by its corresponding organization head or segment 
owner. The evidentiary basis for such approvals should also be 
grounded in quality measures that are provided to the approving 
executive, along with a recommendation for approval by any designated 
subordinate architecture governance bodies and/or accountable 
officials (e.g., component organization CIO). 

Selected references: 

* CIO Council Practical Guide, section 5.4: "Approve, Publish, and 
Disseminate the EA Products." 

* Federal Segment Architecture Methodology, task 5.4.2: "Conduct 
review and obtain approval." 

Core Element 46: Integrated repository tools and common EA framework 
and methodology are used across the enterprise. 

To the extent that the family of corporate and subordinate 
architectures is developed, maintained, and managed using either a 
common set of repositories, frameworks, and tools or, at a minimum, a 
set that is integrated and compatible, then the utility and usefulness 
of the collective family of architectural products will be enhanced, 
and the efficiencies in doing so will be increased. While early stages 
of this framework provide for the use of tools, frameworks, and 
methodologies by all organizational entities, their selection as part 
of these earlier stages was left to the discretion of their respective 
users. As an organization matures in its development and maintenance 
of an EA, it should adopt a more homogeneous approach to frameworks, 
tools, and methodologies. 

Selected references: 

* CIO Council Practical Guide, section 4.6: "Select an EA Toolset." 

* GAO EAMMF, version 1.1: "EA is being developed using a framework, 
methodology, and automated tool." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 47: Corporate and subordinate architecture program 
offices operate as a single virtual office that shares resources 
enterprisewide. 

Consistent with efforts described in the previous element to moving 
toward greater homogeneity in the tools, frameworks, and methodologies 
used to develop and maintain corporate and subordinate architectures, 
a maturing EA organization should also evolve to the point that its 
corporate EA and subordinate architecture program offices operate 
closely and seamlessly, and in a manner in which EA management 
resources are shared. While these program offices may be physically 
and organizationally separate and distinct and include a variety of 
reporting relationships, they should operate as a single virtual 
office. As such, these offices should follow common policies and 
procedures, and they should share limited resources, such as EA 
repository and analysis tools, contractor support, and people with 
critical EA knowledge, skills, abilities, and tools. 

Core Element 48: Corporate EA and sequencing plan are enterprisewide 
in scope. 

As discussed earlier, development of the corporate EA typically occurs 
incrementally. However, the ultimate goal is to have a version that 
fully reflects both the "as-is" and "to-be" environments of an 
organization on an enterprisewide basis. Thus, while initial versions 
of the corporate EA and sequencing plan need not yet extend to all 
parts of the parent enterprise or organization, the scope of a fully 
mature EA should ultimately do so. Relatedly, a fully mature corporate 
sequencing plan should document how the entire organization or 
enterprise intends to achieve the proposed "to-be" operational and 
technological state. In large part, achieving this core element is a 
byproduct of having employed the EA people-, process-, and tool-
related core elements discussed earlier in this framework. 

Selected references: 

* 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"; 
section 5.3.1: "Identify Gaps"; section 5.3.2: "Define and 
Differentiate Legacy, Migration, and New Systems"; section 5.3.3: 
"Planning the Migration." 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan"; section 
6.1.3: "Scope of Completion." 

Core Element 49: Corporate EA and sequencing plan are aligned with 
subordinate architectures. 

A mature EA program should ensure that each federated member and 
segment architecture is aligned with the corporate EA and sequencing 
plan. Establishing such alignment is essential to achieving the goals 
of the EA program, including optimized and rationalized enterprise 
operations and supporting technology solutions that are appropriately 
integrated and compatible. In large part, achieving this core element 
is a byproduct of having met many of the previously discussed core 
elements related to, for example, adopting one or more EA approaches 
(e.g., federation, segmentation, etc.) and employing EA management 
rigor and discipline. 

Selected references: 

* 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"; 
section 5.3.1: "Identify Gaps"; section 5.3.2: "Define and 
Differentiate Legacy, Migration, and New Systems"; section 5.3.3: 
"Planning the Migration." 

* OMB EA Assessment Framework, version 3.1, section 6.1.1: "Target 
Enterprise Architecture and Enterprise Transition Plan"; section 
6.1.3: "Scope of Completion." 

Core Element 50: All segment and/or federated architectures exist and 
are horizontally and vertically integrated. 

While development of subordinate architectures, as discussed earlier, 
typically occurs incrementally based on institutional needs and 
priorities, the ultimate goal remains to develop each of the 
subordinate architectures and to ensure that they collectively form a 
coherent "family of parent and child" architectures that are 
integrated both horizontally and vertically. In large part, achieving 
this core element is a byproduct of having met many of the previously 
discussed core elements related to, for example, adopting one or more 
EA approaches (e.g., federation, segmentation, etc.) and employing EA 
development, maintenance, and management rigor and discipline. 

Selected reference: 

* GAO, Business Systems Modernization: Strategy for Evolving DOD's 
Business Enterprise Architecture Offers a Conceptual Approach, but 
Execution Details Are Needed, GAO-07-451, April 2007. 

Core Element 51: Corporate and subordinate architectures are extended 
to align with external partner architectures. 

For organizations that support or depend on external organizations to 
accomplish their respective missions, such as many federal agencies, 
it is important to be architecturally connected to and aligned with 
their mission partners through an extended EA. In the case of some 
federal agencies, like the Department of Homeland Security, the number 
of these external organizations can be extensive and can span all 
levels of government. Thus, defining, understanding, and rationalizing 
these relationships through the kind of rigorous and disciplined EA 
management practices discussed in this framework can increase these 
organizations' potential for optimizing interorganizational 
performance. Accordingly, it is important that the corporate and 
subordinate architectures be extended and aligned with those of key 
external mission partners. Such alignment can assist organizations in 
leveraging external systems and services and promote information 
sharing to the benefit of all stakeholder organizations. 

Core Element 52: EA products and management processes are subject to 
independent assessment. 

An organization should take steps to ensure the quality of its 
corporate and subordinate architectures. One such step is to provide 
for subjecting its EA products, and the processes used to develop 
these products, to some type of independent assessment. To be 
independent, the assessment should be performed by a party that is 
outside the EA program office and is not otherwise accountable for 
meeting EA program commitments, such as the organization's internal 
audit function or a contractor not responsible for any architecture 
development, maintenance, or management activities. This third party 
should be accountable to, and thus report directly to, the executive 
committee. Consequently, the results of any assessments should be 
reported to the executive committee either before or at the same time 
as they are shared with the applicable parent and/or subordinate EA 
program office. 

Selected references: 

* 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." 

* GAO EAMMF, version 1.1: "EA products and management processes 
undergo independent verification and validation." 

Core Element 53: EA is used by executive leadership to inform 
organization strategic planning and policy formulation. 

As noted earlier, the EA provides the information needed to bridge the 
gap between an organization's strategic plans and the programs it 
implements. As such, the EA has traditionally been informed and 
constrained by these plans and the institutional policies that govern 
the plans' implementation. As an EA program fully matures, however, a 
bidirectional relationship should exist whereby the EA helps to inform 
the same strategic plans and institutional policies to which it is 
integral to implementing. In particular, the EA can identify the 
organizational business process-, performance-, information-, service-
, technology-, and security-related strengths, weaknesses, and 
opportunity gaps that should be considered for inclusion in strategic 
plans and institutional policies. For example, emerging technologies 
that are reflected in the EA's "to-be" view can serve as the catalyst 
for introducing new, or modifying existing, strategic goals and 
objectives, and/or the timelines for achieving them.[Footnote 54] 

Selected references: 

* CIO Council Practical Guide, section 2.5: "The Enterprise Life 
Cycle." 

* GAO ITIM Framework, version 1.1: "Using IT to Drive Strategic 
Business Change." 

* OMB EA Assessment Framework, version 3.1, section 6.2.5: "EA 
Governance, Program Management, Change Management, and Deployment." 

Core Element 54: EA human capital capabilities are continuously 
improved. 

An organization should periodically reevaluate its existing corporate 
and subordinate EA human capital capabilities relative to its future 
needs so that it continues to update its understanding of gaps that 
need to be filled. Using such a gap analysis, those responsible for 
the EA program can take proactive steps to fill any knowledge and 
skill gaps through training, hiring, and contracting. As an 
organization engages in such continuous improvement, care should be 
taken to do so in coordination with other EA-related program 
improvement efforts, and in a manner that reflects established 
continuous improvement guidance.[Footnote 55] 

Selected references: 

* CIO Council Practical Guide, section 3.2.5.1: "Appoint Key 
Personnel"; section 3.2.5.2: "Establish Enterprise Architecture Core 
Team"; section 6.1.1: "Train Personnel"; section 8.4: "Ensure 
Continuous Improvement." 

* GAO, A Model of Strategic Human Capital Management, GAO-02-373SP, 
March 2002; Human Capital: Key Principles for Effective Strategic 
Workforce Planning, GAO-04-39, December 2003. 

* CMMI for Development, version 1.2: "Establish an Organizational 
Training Capability." 

Core Element 55: EA methodologies and tools are continuously improved. 

An organization should periodically reevaluate its corporate and 
subordinate EA methodologies and tools to ensure that they continue to 
support its needs. Among other things, this reevaluation should 
consider user satisfaction with the currently employed methodologies 
and tools (e.g., usability, supportability, etc.), the commercial 
availability of alternative products, and the costs associated with 
transitioning to alternative methods and tools, including licensing, 
training, and conversion costs. As an organization engages in these 
continuous improvement efforts, care should be taken to do so in 
coordination with other EA program improvement efforts and in a manner 
that reflects established continuous improvement guidance.[Footnote 56] 

Selected references: 

* 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." 

* GAO ITIM Framework, version 1.1: "Selecting an Investment." 

* CMMI for Development, version 1.2: "Ensure Continuous Process 
Improvement." 

Core Element 56: EA management processes are continuously improved and 
reflect the results of external assessments. 

An organization should periodically reevaluate its corporate and 
subordinate EA management processes to ensure that they are effective. 
Among other things, the reevaluation should compare existing processes 
with relevant benchmarks and guidance, such as this framework, and 
identify any gaps that need to be addressed. As an organization 
engages in this continuous improvement activity, care should be taken 
to do so in coordination with other EA program improvement efforts, 
and in a manner that reflects established continuous improvement 
guidance.[Footnote 57] 

Selected references: 

* CIO Council Practical Guide, section 8.4: "Ensure Continuous 
Improvement." 

* CMMI for Development, version 1.2: "Ensure Continuous Process 
Improvement." 

* GAO EAMMF, version 1.1: "EA products and management processes 
undergo independent verification and validation." 

Core Element 57: EA products are continuously improved and updated. 

An EA needs to be continuously maintained to reflect, among other 
things, shifts in legal requirements, emerging threats and 
opportunities, shifting priorities, emerging technologies, and 
governmentwide priorities. Such maintenance also involves introducing 
changes that are aimed at increasing the EA product quality (i.e., 
currency, consistency, understandability, usability, accuracy, and 
completeness). As individual changes are made that collectively 
represent a significant modification to the products, these changes 
should be packaged as part of a new version of the corporate and 
subordinate architecture products. Such continuous improvement to the 
content of the EA and its products should be formally controlled using 
a formal configuration management process, as discussed earlier. 

Selected references: 

* CIO Council Practical Guide, section 7.1: "Maintain the Enterprise 
Architecture as the Enterprise Evolves"; section 7.1.1: "Reassess the 
Enterprise Architecture Periodically"; section 7.2: "Continue to 
Consider Proposals for EA Modifications"; section 8.4: "Ensure 
Continuous Improvement." 

* GAO EAMMF, version 1.1: "EA products are periodically updated." 

Core Element 58: EA quality and results measurement methods are 
continuously improved. 

An organization should periodically reevaluate its methods for 
assessing corporate and subordinate architecture quality and program 
results. If opportunities for improvement exist, actions should be 
identified and undertaken to exploit these opportunities. Among other 
things, this reevaluation should address the extent to which program 
measures and metrics are sufficiently measurable, meaningful, 
repeatable, consistent, and actionable and aligned with the EA 
program's strategic goals and the EA's intended purpose. When 
planning, implementing, tracking, and reporting on improvements to EA 
quality and results measurement methods, care should be taken to do so 
in coordination with other EA program continuous improvement efforts, 
and in a manner that reflects established continuous improvement 
guidance.[Footnote 58] 

Selected references: 

* CIO Council Practical Guide, section 8.4: "Ensure Continuous 
Improvement." 

* CMMI for Development, version 1.2: "Ensure Continuous Process 
Improvement." 

Core Element 59: EA continuous improvement efforts reflect the results 
of external assessments. 

All efforts to continuously improve the EA program capabilities and 
products should leverage the results of external assessments performed 
by organizations external to the program, including assessments 
periodically performed by GAO, OMB, and others. Our work in following 
up with agencies to determine the status of recommendations that we 
have made to address EA limitations and weaknesses shows that, over 
time, agency actions have increased the quality of EA products and 
management processes and resulted in measurable accomplishments. 

Selected references: 

* GAO EAMMF, version 1.1. 

* OMB EA Assessment Framework, version 3.1. 

[End of section] 

Footnotes: 

[1] See, for example, GAO, Strategic Information Planning: Framework 
for Designing and Developing System Architectures, [hyperlink, 
http://www.gao.gov/products/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, [hyperlink, 
http://www.gao.gov/products/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, [hyperlink, 
http://www.gao.gov/products/GAO-04-731R] (Washington, D.C.: May 17, 
2004); Information Technology: Architecture Needed to Guide NASA's 
Financial Management Modernization, [hyperlink, 
http://www.gao.gov/products/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, 
[hyperlink, http://www.gao.gov/products/GAO-03-1018] (Washington, 
D.C.: Sept. 19, 2003); and Information Technology: DLA Should 
Strengthen Business Systems Modernization Architecture and Investment 
Activities, [hyperlink, http://www.gao.gov/products/GAO-01-631] 
(Washington, D.C.: June 29, 2001). 

[3] GAO, Information Technology: Enterprise Architecture Use across 
the Federal Government Can Be Improved, [hyperlink, 
http://www.gao.gov/products/GAO-02-6] (Washington, D.C.: Feb. 19, 
2002); Information Technology: A Framework for Assessing and Improving 
Enterprise Architecture Management (version 1.1), [hyperlink, 
http://www.gao.gov/products/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. 

[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, 
[hyperlink, http://www.gao.gov/products/GAO-09-675] (Washington, D.C.: 
July 31, 2009); DOD Business Systems Modernization: Military 
Departments Need to Strengthen Management of Enterprise Architecture 
Programs, [hyperlink, http://www.gao.gov/products/GAO-08-519] 
(Washington, D.C., May 12, 2008); Federal Aviation Administration: 
Stronger Architecture Program Needed to Guide Systems Modernization 
Efforts, [hyperlink, http://www.gao.gov/products/GAO-05-266] 
(Washington, D.C.: Apr. 29, 2005); [hyperlink, 
http://www.gao.gov/products/GAO-04-777]; [hyperlink, 
http://www.gao.gov/products/GAO-04-731R]; Information Technology: 
Architecture Needed to Guide NASA's Financial Management 
Modernization, [hyperlink, http://www.gao.gov/products/GAO-04-43] 
(Washington, D.C.: Nov. 21, 2003); Information Technology: Leadership 
Remains Key to Agencies Making Progress on Enterprise Architecture 
Efforts, [hyperlink, http://www.gao.gov/products/GAO-04-40] 
(Washington, D.C.: Nov. 17, 2003); [hyperlink, 
http://www.gao.gov/products/GAO-03-1018]; [hyperlink, 
http://www.gao.gov/products/GAO-03-877R]; Information Technology: DLA 
Should Strengthen Business Systems Modernization Architecture and 
Investment Activities, [hyperlink, 
http://www.gao.gov/products/GAO-01-631] (Washington, D.C.: June 29, 
2001); and Information Technology: INS Needs to Better Manage the 
Development of Its Enterprise Architecture, [hyperlink, 
http://www.gao.gov/products/GAO/AIMD-00-212] (Washington, D.C.: Aug. 
1, 2000). 

[7] J. A. Zachman, "A Framework for Information Systems Architecture," 
IBM Systems Journal 26, no. 3 (1987). 

[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] [hyperlink, http://www.gao.gov/products/GAO/IMTEC-92-51]. 

[11] GAO, Executive Guide: Improving Mission Performance through 
Strategic Information Management and Technology, [hyperlink, 
http://www.gao.gov/products/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). 

[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. 

[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). 

[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). 

[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). 

[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, [hyperlink, 
http://www.gao.gov/products/GAO-09-272R] (Washington, D.C., January 
2009). 

[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, [hyperlink, 
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, 
[hyperlink, http://www.gao.gov/products/GAO-04-394G] (Washington, 
D.C.: March 2004); [hyperlink, 
http://www.gao.gov/products/GAO/AIMD-10.1.13]; and Executive Guide: 
Improving Mission Performance Through Strategic Information Management 
and Technology, GAO/AIMD-94-115. 

[26] [hyperlink, http://www.gao.gov/products/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] [hyperlink, http://www.gao.gov/products/GAO-02-6] and [hyperlink, 
http://www.gao.gov/products/GAO-03-584G]. 

[29] CXO, or chief "X" officer, is a generic term for job titles where 
"X" represents a specific specialized position that serves the entire 
organization, such as the chief information officer, chief financial 
officer, chief human capital officer, chief procurement officer, chief 
performance officer, chief technology officer, chief information 
security officer, or chief management officer. 

[30] Stage 2 includes all Stage 1 core elements. 

[31] Stage 3 includes all elements in Stages 1 and 2. 

[32] Stage 4 includes all elements in Stages 1 through 3. 

[33] Stage 5 includes all elements in Stages 1 through 4. 

[34] Stage 6 includes all elements in Stages 1 through 5. 

[35] GAO, Enterprise Architecture: Leadership Remains Key to 
Establishing and Leveraging Architectures for Organizational 
Transformation, [hyperlink, http://www.gao.gov/products/GAO-06-831] 
(Washington, D.C.: Aug. 14, 2006). 

[36] See, for example, GAO, Elections: The Nation's Evolving Election 
System as Reflected in the November 2004 General Election, [hyperlink, 
http://www.gao.gov/products/GAO-06-450] (Washington, D.C., June 6, 
2006). 

[37] [hyperlink, http://www.gao.gov/products/GAO-06-831]. 

[38] As described previously in this report, GAO's ECIMT is composed 
of senior-level officials from the public sector, private sector, and 
academia. Members include former chief information officers (CIO) for 
government agencies, professors of information technology (IT), 
presidents of private businesses, IT consultants, and representatives 
of the National Association of State CIOs. 

[39] See, for example, OMB, Federal Enterprise Architecture Practice 
Guidance (November 2007); Federal Segment Architecture Working Group 
and OMB, Federal Segment Architecture Methodology (December 2008); and 
Federal Chief Information Officers Council, A Practical Guide to 
Federal Service Oriented Architecture (June 2008). 

[40] [hyperlink, http://www.gao.gov/products/GAO-06-831], [hyperlink, 
http://www.gao.gov/products/GAO-04-40], and [hyperlink, 
http://www.gao.gov/products/GAO-02-6]. 

[41] Carnegie Mellon Software Engineering Institute, Capability 
Maturity Model® Integration (CMMI) for Development, version 1.2, CMU/ 
SEI-2006-TR-008 (Pittsburgh, Pa.: August 2006). 

[42] See [hyperlink, http://www.gao.gov/products/GAO-06-831]. The 
frameworks most frequently cited by departments and agencies in this 
report were the Federal Enterprise Architecture Program Management 
Office Reference Models, the Federal Enterprise Architecture 
Framework, and the Zachman Framework. 

[43] See [hyperlink, http://www.gao.gov/products/GAO-06-831]. The most 
frequently cited tools were System Architect, Visio, and Metis. 

[44] GAO, Cost Estimating and Assessment Guide: Best Practices for 
Developing and Managing Capital Program Costs, [hyperlink, 
http://www.gao.gov/products/GAO-09-3SP] (Washington, D.C.: Mar. 2, 
2009). 

[45] CXO, or chief "X" officer, is a generic term for job titles where 
"X" represents a specific specialized position that serves the entire 
organization, such as the CIO, chief financial officer, chief human 
capital officer, chief procurement officer, chief performance officer, 
chief technology officer, chief information security officer, or chief 
management officer. 

[46] [hyperlink, http://www.gao.gov/products/GAO-06-831. 

[47] GAO, Information Technology: FBI Is Taking Steps to Develop an 
Enterprise Architecture, but Much Remains to Be Accomplished, 
[hyperlink, http://www.gao.gov/products/GAO-05-363] (Washington, D.C.: 
Sept. 9, 2005). 

[48] See, for example, Department of Defense, Risk Management Guide 
for DOD Acquisition, 6th Edition, version 1.0, [hyperlink, 
http://www.acq.osd.mil/sse/ed/docs/2006-RM-Guide-4Aug06-final-
version.pdf] (accessed March 13, 2008); and Carnegie Mellon Software 
Engineering Institute, CMMI for Acquisition, version 1.2, CMU/SEI-2007-
TR-017 (Pittsburgh, Pa.: November 2007). 

[49] See, for example, GAO, DOD Business Systems Modernization: Recent 
Slowdown in Institutionalizing Key Management Controls Needs to Be 
Addressed, [hyperlink, http://www.gao.gov/products/GAO-09-586] 
(Washington, D.C.: May 18, 2009). 

[50] GAO, DOD Business Systems Modernization: Key Navy Programs' 
Compliance with DOD's Federated Business Enterprise Architecture Needs 
to Be Adequately Demonstrated, [hyperlink, 
http://www.gao.gov/products/GAO-08-972] (Washington, D.C.: Aug. 7, 
2008). 

[51] See discussion earlier in this framework. 

[52] These six views may be captured in any number of EA models or 
architectural artifacts depending on the EA content framework being 
used. 

[53] See [hyperlink, http://www.gao.gov/products/GAO-06-831] for 
examples of architecture-related benefits reported by departments and 
agencies. 

[54] This "inverse" relationship between strategic plans and program 
implementations is similarly recognized at the highest maturity stage 
in GAO's IT Investment Management Framework. Specifically, Stage 5 of 
this framework emphasizes the importance of IT-driven strategic 
business change, whereby IT is used to strategically renovate and 
transform work processes and push the organization to explore new and 
better ways to execute its mission. See [hyperlink, 
http://www.gao.gov/products/GAO-04-394G]. 

[55] See, for example, Carnegie Mellon Software Engineering Institute, 
CMMI for Development, Version 1.2, CMU/SEI-2006-TR-008 (Pittsburgh, 
Pa.: August 2006). 

[56] See, for example, Carnegie Mellon Software Engineering Institute, 
CMMI for Development, Version 1.2, CMU/SEI-2006-TR-008 (Pittsburgh, 
Pa.: August 2006). 

[57] See, for example, Carnegie Mellon Software Engineering Institute, 
CMMI for Development, Version 1.2, CMU/SEI-2006-TR-008 (Pittsburgh, 
Pa.: August 2006). 

[58] See, for example, Carnegie Mellon Software Engineering Institute, 
CMMI for Development, Version 1.2, CMU/SEI-2006-TR-008 (Pittsburgh, 
Pa.: August 2006). 

[End of section] 

GAO's Mission: 

The Government Accountability Office, the audit, evaluation and 
investigative arm of Congress, exists to support Congress in meeting 
its constitutional responsibilities and to help improve the performance 
and accountability of the federal government for the American people. 
GAO examines the use of public funds; evaluates federal programs and 
policies; and provides analyses, recommendations, and other assistance 
to help Congress make informed oversight, policy, and funding 
decisions. GAO's commitment to good government is reflected in its core 
values of accountability, integrity, and reliability. 

Obtaining Copies of GAO Reports and Testimony: 

The fastest and easiest way to obtain copies of GAO documents at no 
cost is through GAO's Web site [hyperlink, http://www.gao.gov]. Each 
weekday, GAO posts newly released reports, testimony, and 
correspondence on its Web site. To have GAO e-mail you a list of newly 
posted products every afternoon, go to [hyperlink, http://www.gao.gov] 
and select "E-mail Updates." 

Order by Phone: 

The price of each GAO publication reflects GAO’s actual cost of
production and distribution and depends on the number of pages in the
publication and whether the publication is printed in color or black and
white. Pricing and ordering information is posted on GAO’s Web site, 
[hyperlink, http://www.gao.gov/ordering.htm]. 

Place orders by calling (202) 512-6000, toll free (866) 801-7077, or
TDD (202) 512-2537. 

Orders may be paid for using American Express, Discover Card,
MasterCard, Visa, check, or money order. Call for additional 
information. 

To Report Fraud, Waste, and Abuse in Federal Programs: 

Contact: 

Web site: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]: 
E-mail: fraudnet@gao.gov: 
Automated answering system: (800) 424-5454 or (202) 512-7470: 

Congressional Relations: 

Ralph Dawn, Managing Director, dawnr@gao.gov: 
(202) 512-4400: 
U.S. Government Accountability Office: 
441 G Street NW, Room 7125: 
Washington, D.C. 20548: 

Public Affairs: 

Chuck Young, Managing Director, youngc1@gao.gov: 
(202) 512-4800: 
U.S. Government Accountability Office: 
441 G Street NW, Room 7149: 
Washington, D.C. 20548: