INFORMATION 

TECHNOLOGY 

The Federal Enterprise 

Architecture and Agencies’ 

Enterprise Architectures 

Are Still Maturing 

Statement of Randolph C. Hite 

Director, Information Technology Architecture and 

Systems Issues 

United States General Accounting Office 

GAO Testimony

Before the Subcommittee on Technology, 

Information Policy, Intergovernmental Relations 

and the Census, Committee on Government 

Reform, House of Representatives 

For Release on Delivery 

Expected at 2 p.m. EDT on 

Wednesday May 19, 2004 

GAO-04-798T 
www.gao.gov/cgi-bin/getrpt?GAO-04-798T.

To view the full product, including the scope 

and methodology, click on the link above. 

For more information, contact Randy Hite at 

202-512-6256 or hiter@gao.gov. 

Highlights of GAO-04-798T, a testimony 

before the Subcommittee on Technology, 

Information Policy, Intergovernmental 

Relations and the Census, Committee on 

Government Reform, House of 

Representatives. 

May 19, 2004

INFORMATION TECHNOLOGY 

The Federal Enterprise Architecture and 

Agencies' Enterprise Architectures Are 

Still Maturing 

OMB has made progress on the FEA, but it remains very much a work in 

process and is still maturing. Its stated purposes include facilitating (1) the 

development of agencies’ enterprise architectures, (2) the reuse of common 

IT components across agencies, and (3) the identification of opportunities 

for interagency collaboration in developing common IT solutions. Currently, 

the FEA is made up of five parts known as reference models, four of which 

have been issued in at least initial form (see table). OMB reports that the 

FEA has been used to help identify potentially redundant agency IT 

investments, choose five lines of business (e.g., grants management) in 

which to pursue opportunities for agency collaboration, and begin to 

develop the architectural foundation for some of these business lines. GAO 

supports the FEA as a framework for achieving these ends, but raises 

questions whose answers are important to the its future. For example: 

Should the FEA be described as an enterprise architecture? GAO’s reading of 

its content suggests that it is more akin to a classification scheme for 

government operations than a true enterprise architecture. Further, OMB 

requires agencies to “map” and “align” their architectures with the FEA. 

However, since these terms are not well-defined, GAO asks if the expected 

relationship between the FEA and agencies’ architectures is clear enough. 

Like the FEA, agencies’ enterprise architectures are still maturing. GAO 

recently reported (GAO-04-40) that agencies’ management of architecture 

programs was generally not mature. Using its Enterprise Architecture 

Management Maturity Framework as a benchmark, GAO found little change 

in overall maturity between 2001 and 2003. Only 20 of 96 agencies examined 

had established at least the foundation for effective architecture 

management. Further, while 22 agencies increased in maturity since 2001, 24 

agencies decreased and 47 agencies remained the same. Recently, OMB and 

the federal CIO Council initiated actions to advance agency architecture 

programs that are consistent with many of GAO’s recommendations. 

FEA Reference Models 

Reference 

model Description Release date 

Performance Provides a common set of general performance outputs and 

measures for agencies to use to achieve business goals and 

objectives. 

V 1.0, 

September 

2003 

Business Describes the hierarchy of federal business operations 

independent of the agencies that perform them, including 

defining the services provided to state and local governments. 

V 2.0, 

June 2003 

Service 

component 

Identifies and classifies IT service (i.e., application) components 

that support federal business operations and promotes the reuse 

of components across agencies 

V 1.0, 

June 2003 

Data and 

information 

Is intended to describe, at an aggregate level, the types of data 

and information that support program ad business line operatin 

and the hierarchical relationships among them. 

Planned for 

2004 

Technical Describes how technology is supporting the delivery of service 

components, including relevant implementation standards. 

V 1.1, 

August 2003 

Source: GAO analysis of OMB data. 

The concept of enterprise 

architecture emerged in the mid1980s as a means for optimizing 

integration and interoperability 

across organizations. In the early 

1990s, GAO research of successful 

public and private sector 

organizations led it to identify 

enterprise architecture as a critical 

success factor for agencies that are 

attempting to modernize their 

information technology (IT) 

environments. Since then, GAO has 

repeatedly identified the lack of an 

enterprise architecture as a key 

management weakness in major 

modernization programs at a 

number of federal agencies. It has 

also collaborated with the Office of 

Management and Budget (OMB) 

and the federal Chief Information 

Officers (CIO) Council to develop 

architecture guidance. In 2002, 

OMB began developing the Federal 

Enterprise Architecture (FEA), an 

initiative intended to guide and 

constrain federal agencies’ 

enterprise architectures and IT 

investments. 

GAO was asked to testify on the 

status of the FEA and on the state 

of federal agencies’ development 

and use of enterprise architectures. 
Page 1 GAO-04-798T

Mr. Chairman and Members of the Subcommittee: 

I appreciate the opportunity to participate in the Subcommittee’s 

hearing on the status of the Federal Enterprise Architecture (FEA) 

and on the state of federal agencies’ development and use of 

enterprise architectures—two topics that are closely related. 

An enterprise architecture can be viewed as a link between an 

organization’s strategic plan and the program and supporting system 

implementation investments that it intends to pursue to 

systematically achieve its strategic goals and outcomes. As such, the 

architecture is basically a blueprint, defined largely by interrelated 

models, that describes (in both business and technology terms) an 

entity’s “as is” or current environment, its “to be” or future 

environment, and its investment plan for transitioning from the 

current to the future environment. The use of such a blueprint is a 

recognized hallmark of organizations that effectively leverage 

technology in the transformation and modernization of business 

operations and supporting systems. Further, it is recognized in 

legislation and related Office of Management and Budget (OMB) 

implementing guidance. The FEA is intended to provide a 

governmentwide framework to guide and constrain federal agencies’ 

enterprise architectures and information technology (IT) 

investments. 

My testimony today is drawn largely from our 2003 report on federal 

agencies’ development and use of enterprise architectures, which 

was based on work conducted in accordance with generally 

accepted government auditing standards.1

 We augmented the results 

in this report with available information on the recent actions of 

OMB and the federal Chief Information Officers (CIO) Council to 

address the recommendations that we made in the report. This 

testimony is also based on discussions with and information from 

 1

 U.S. General Accounting Office, Information Technology: Leadership Remains Key to 

Agencies Making Progress on Enterprise Architecture Efforts, GAO-04-40 (Washington,

D.C.: Nov. 17, 2003). 
Page 2 GAO-04-798T

OMB on the FEA, as well as discussions with GAO’s Executive 

Council on Information Management and Technology.2

Results in Brief 

The FEA continues to evolve in both content and use, which is both 

reasonable and expected, in our view, for such a broad-based 

framework. Through the FEA, OMB is attempting to provide federal 

agencies and other decision-makers with a common frame of 

reference or taxonomy for informing agencies’ individual enterprise 

architecture efforts and their planned and ongoing investment 

activities, and to do so in a way that identifies opportunities for 

avoiding duplication of effort and launching initiatives to establish 

and implement common, reusable, and interoperable solutions 

across agency boundaries. We support this goal, and the 

development and use of the FEA as part of the means to accomplish 

it. We nevertheless observe that development and use of the FEA is 

but the first step in a multistep process needed to realize the 

promise of such interagency solutions. Because the FEA is still 

maturing both in content and in use, we have a number of questions 

that we believe OMB needs to address to maximize understanding 

about the tool and thus facilitate its advancement. 

1. Should the FEA be described as an enterprise architecture? 

2. Is the expected relationship between agencies’ enterprise 

architectures and the FEA clearly articulated? 

3. How will the security aspects of the FEA be addressed? 

Like the FEA, the enterprise architecture efforts of individual 

federal departments and agencies are also still maturing. In 

September 2003, we reported that federal agencies’ collective 

 2 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 CIOs for government agencies, professors of information technology, presidents of 

private businesses, and information technology consultants. 
Page 3 GAO-04-798T

progress toward effectively managing enterprise architectures was 

limited, with much work remaining.3

 In particular, the percentage of 

agencies that had established at least the foundation for effective 

enterprise architecture management was virtually unchanged from 

where it was in 2001 (about 50 percent). We further reported that 

when the state of enterprise architecture is considered in relation to 

a more recent and demanding benchmark, this percentage dropped 

to about 20 percent (in round terms), although some agencies did do 

well against this benchmark and were thus role models for other 

agencies to follow. This composite picture of immature enterprise 

architecture management can be attributed to several long-standing 

challenges, which were the basis for the recommendations that we 

made to OMB in 2001 and reiterated in 2003. Recently, OMB and the 

CIO Council took steps that are consistent with many of our 

recommendations. We support these steps, and we are working 

collaboratively with both organizations to maximize their 

effectiveness. However, the fact remains that until agencies have 

and use well-defined enterprise architectures, they will be severely 

challenged in their ability to effectively leverage IT in transforming 

their operations. 

Background 

The concept of using an architecture to describe an enterprise 

emerged in the mid-1980s, and over the years, the field of enterprise 

architecture has continued to evolve and mature. In the early 1990s, 

we identified an architecture as a critical success factor in allowing 

organizations to effectively apply IT to meet mission goals. Since 

then, we have worked with the Congress, OMB, and the CIO Council 

to promote the importance of architectures and assist agencies in 

developing, maintaining, and using them. In our reviews of selected 

agency IT management practices and major systems modernization 

programs, we have consistently identified the lack of an architecture 

as a major management weakness and made recommendations to 

address this important area. 

 3 GAO-04-40. 
Page 4 GAO-04-798T

To help oversee and budget for federal IT investments, OMB began 

developing the FEA in 2002, and has since issued versions of four of 

its five major parts. According to OMB, the FEA is to provide a 

common, governmentwide framework for agency enterprise 

architectures and IT investments. Thus far, OMB reports that it has 

begun using the FEA to identify and address interagency duplication 

of effort and to launch interagency projects. 

What Is an Enterprise Architecture? 

In simplest terms, an enterprise is any purposeful activity, and an 

architecture is the structural description of an activity. Building on 

this, we can view enterprise architectures as systematically derived 

and captured structural descriptions—in useful models, diagrams, 

and narrative—of the mode of operation for a given enterprise, 

which can be either a single organization or a functional or mission 

area that transcends more than one organizational boundary (e.g., 

financial management, homeland security). 

The architecture can also be viewed as a blueprint that links an 

enterprise’s strategic plan to the programs and supporting systems 

that it intends to implement to accomplish the mission goals and 

objectives laid out in the strategic plan. As such, the architecture 

describes the enterprise’s operations in both logical terms (such as 

interrelated business processes and business rules, information 

needs and flows, and work locations and users) and technical terms 

(such as hardware, software, data, communications, and security 

attributes and performance standards). Moreover, it provides these 

perspectives both for the enterprise’s current (or “as-is”) 

environment and for its targeted future (or “to-be”) environment, as 

well as for the transition plan for moving from the “as-is” to the “tobe” environment. 

Importance of Enterprise Architectures 

The importance of enterprise architectures is a basic tenet of IT 

management, and their effective use is a recognized hallmark of 

successful public and private organizations. For over a decade, we 

have promoted the use of architectures, recognizing them as a 

crucial means to a challenging goal: that is, agency operational 

structures that are optimally defined, in terms of both business and 
Page 5 GAO-04-798T

technology. The alternative, as our work has shown, is perpetuation 

of the kinds of operational environments that saddle most agencies 

today, in which the lack of integration among business operations 

and the IT resources that support them leads to systems that are 

duplicative, not well integrated, and unnecessarily costly to 

maintain and interface. 

Managed properly, an enterprise architecture can clarify and help 

optimize the interdependencies and relationships among an 

organization’s business operations and the underlying IT 

infrastructure and applications that support these operations. 

Employed in concert with other important IT management controls 

(such as portfolio-based capital planning and investment control 

practices), architectures can greatly increase the chances that 

organizations’ operational and IT environments will be configured 

so as to optimize mission performance. Enterprise architectures are 

integral to managing large-scale programs in federal departments 

and agencies, as well as initiatives that span several agencies, such 

as those currently being undertaken to support OMB’s electronic 

government (e-government)4

 and “Line of Business”5 efforts. 

Brief History of Enterprise Architecture Frameworks and Management Guidance 

During the mid-1980s, John Zachman, widely recognized as a leader 

in the field of enterprise architecture, identified the need to use a 

logical construction blueprint (i.e., an architecture) for defining and 

controlling the integration of systems and their components.6

Accordingly, Zachman developed a structure or framework for 

defining and capturing an architecture, which provides for six 

 4

 According to OMB, e-government is a mode of operations (using people, process, and 

technology—particularly Web-based Internet technology) to enhance access to and 

delivery of government information and service to citizens, business partners, employees, 

other agencies, and other levels of government. U.S. General Accounting Office, Electronic 

Government: Initiatives Sponsored by the Office of Management and Budget Have Made 

Mixed Progress, GAO-04-561T (Washington, D.C.: March 24, 2004). 

5

 According to OMB, the “Lines of Business” efforts will entail reviewing proposed 

investments in five areas (financial, human resources, grants, health, and case management 

systems) to identify common solutions and reduce costs. 

6

 J.A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems 

Journal, vol. 26, no. 3 (1987). 
Page 6 GAO-04-798T

“windows” from which to view the enterprise.7 Zachman also 

proposed six abstractions or models associated with each of these 

perspectives.8 Zachman’s framework provides a way to identify and 

describe an entity’s existing and planned component parts, and the 

relationships between those parts, before the entity begins the 

costly and time-consuming efforts associated with developing or 

transforming itself. 

Since Zachman introduced his framework, a number of frameworks 

have emerged within the federal government, beginning with the 

publication of the National Institute of Standards and Technology 

(NIST) framework in 1989. Since that time, other federal entities 

have issued enterprise architecture frameworks, including the 

Department of Defense (DOD) and the Department of the Treasury. 

In September 1999, the federal CIO Council published the Federal 

Enterprise Architecture Framework, which was intended to provide 

federal agencies with a common construct for their architectures, 

thereby facilitating the coordination of common business processes, 

technology insertion, information flows, and system investments 

among federal agencies. The Federal Enterprise Architecture 

Framework describes an approach, including models and 

definitions, for developing and documenting architecture 

descriptions for multiorganizational functional segments of the 

federal government.9 

In February 2002, OMB established the Federal Enterprise 

Architecture Program Management Office to develop the FEA, 

which, according to OMB, is intended to facilitate governmentwide 

improvement through cross-agency analysis and identification of 

duplicative investments, gaps, and opportunities for collaboration, 

 7

 The windows provide the viewpoints 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. 

8

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

9

 Similar to the Zachman framework, the Federal Enterprise Architecture Framework’s 

proposed models describe an entity’s business, data necessary to conduct the business, 

applications to manage the data, and technology to support the applications. 
Page 7 GAO-04-798T

interoperability, and integration within and across agency programs. 

The FEA is composed of five “reference models” describing the 

federal government’s (1) business (or mission) processes and 

functions, independent of the agencies that perform them, 

(2) performance goals and outcome measures, (3) service delivery 

means, (4) information and data definitions, and (5) technology 

standards. The reference models are intended to inform agency 

efforts to develop their agency-specific enterprise architectures and 

enable agencies to ensure that their proposed investments are not 

duplicative with those of other agencies and to pursue, where 

appropriate, joint projects. The FEA reference models are 

summarized in table 1. 

Table 1: FEA Reference Models 

Reference model Description Status 

Performance reference 

Model 

Provides a common set of general performance outputs and 

measures for agencies to use to achieve business goals and 

objectives. 

Version 1.0 released 

in September 2003 

Business reference model Describes the hierarchy of federal business operations 

independent of the agencies that perform them, including defining 

the services provided to state and local governments. 

Version 2.0 released 

in June 2003 

Service component 

reference model 

Identifies and classifies IT service (i.e., application) components 

that support federal business operations and promotes the reuse 

of components across agencies. 

Version 1.0 released 

in June 2003 

Data and information 

reference model 

Is intended to describe, at an aggregate level, the data and 

information types that support program and business line 

operations and the hierarchical relationships among these types. 

Release planned in 

2004 

Technical reference model Describes technology that is to support the delivery of service 

components, including relevant standards for implementing the 

technology. 

Version 1.1 released 

in August 2003 

Source: GAO analysis based on OMB data. 

Although these post-Zachman frameworks differ in their 

nomenclatures and modeling approaches, most provide for defining 

an enterprise’s operations in both logical terms and technical terms, 

provide for defining these perspectives for the enterprise’s current 

and target environments, and call for a transition plan between the 

two. 

Several laws and regulations have established requirements and 

guidance for agencies’ management of architectures, beginning with 
Page 8 GAO-04-798T

the Clinger-Cohen Act in 1996,10 which directs the CIOs of major 

departments and agencies to develop, maintain, and facilitate the 

implementation of IT architectures as a means of integrating agency 

goals and business processes with IT. OMB Circular A-130, which 

implements the Clinger-Cohen Act, requires that agencies document 

and submit their initial enterprise architectures to OMB and updates 

when significant changes to their architectures occur. The circular 

also directs the OMB Director to use various kinds of reviews to 

evaluate the adequacy and efficiency of agency compliance with the 

circular. 

OMB was given explicit responsibility for overseeing government 

enterprise architectures by the E-Government Act of 2002,11 which 

established the Office of Electronic Government within the office. 

More specifically, it gives OMB the responsibility for facilitating the 

development of enterprise architectures within and across agencies 

and supporting improvements in government operations through the 

use of IT. 

Prior Work Indicates Opportunities for Improving Enterprise Architectures 

We began reviewing federal agencies’ use of architectures in 1994, 

initially focusing on those agencies that were pursuing major 

systems modernization programs that were high risk. These 

included the National Weather Service systems modernization,12 the 

Federal Aviation Administration air traffic control modernization,13

and the Internal Revenue Service tax systems modernization.14

 10 Public Law 104-106, 40 U.S.C. 11315. 

11 Public Law 107-347. 

12U.S. General Accounting Office, Weather Forecasting: Systems Architecture Needed for 

National Weather Service Modernization, GAO/AIMD-94-28 (Washington, D.C.: Mar. 11,

1994). 

13U.S. General Accounting Office, Air Traffic Control: Complete and Enforced 

Architecture Needed for FAA Systems Modernization, GAO/AIMD-97-30 (Washington,

D.C.: Feb. 3, 1997). 

14U.S. General Accounting Office, Tax Systems Modernization: Blueprint Is a Good Start 

but Not Yet Sufficiently Complete to Build or Acquire Systems, GAO/AIMD/GGD-98-54

(Washington, D.C.: Feb. 24, 1998). 
Page 9 GAO-04-798T

Generally, we reported that these agencies’ enterprise architectures 

were incomplete, and we made recommendations that they develop 

and implement complete enterprise architectures to guide their 

modernization efforts. 

Since then, we have reviewed architecture efforts at other federal 

agencies, including the Department of Education,15 the former 

Customs Service,16 the former Immigration and Naturalization 

Service,17 the Centers for Medicare and Medicaid Services,18 the 

Department of Defense (DOD),19 the Federal Bureau of 

Investigation,20 and the National Aeronautics and Space 

Administration.21These reviews have identified the absence of 

complete and enforced enterprise architectures, which has led to 

agency business operations, systems, and data that are not 

integrated and that are duplicative and incompatible. These 

conditions, in turn, have either prevented agencies from sharing 

data or forced them to do so through inefficient manual processes 

or costly, custom-developed system interfaces. 

 15U.S. General Accounting Office, Student Financial Aid Information: Systems 

Architecture Needed to Improve Programs’ Efficiency, GAO/AIMD-97-122 (Washington, 

D.C.: July 29, 1997). 

16U.S. General Accounting Office, Customs Service Modernization: Architecture Must Be 

Complete and Enforced to Effectively Build and Maintain Systems, GAO/AIMD-98-70

(Washington, D.C.: May 5, 1998). 

17U.S. General Accounting Office, Information Technology: INS Needs to Better Manage 

the Development of Its Enterprise Architecture, GAO/AIMD-00-212 (Washington, D.C.: Aug.

1, 2000). 

18U.S. General Accounting Office, Medicare: Information Systems Modernization Needs 

Stronger Management and Support, GAO-01-824 (Washington, D.C.: Sept. 20, 2001).

19 U.S. General Accounting Office, DOD Business Systems Modernization: Important 

Progress Made to Develop Business Enterprise Architecture, but Much Work Remains, 

GAO-03-1018 (Washington, D.C.: Sept. 19, 2003). 

20 U.S. General Accounting Office, Information Technology: FBI Needs an Enterprise 

Architecture to Guide Its Modernization Activities, GAO-03-959 (Washington, D.C.: Sept. 

25, 2003). 

21 U.S. General Accounting Office, Information Technology: Architecture Needed to Guide 

NASA’s Financial Management Modernization, GAO-04-43 (Washington, D.C.: Nov. 21,

2003). 
Page 10 GAO-04-798T

Our Enterprise Architecture Management Maturity Framework 

To contribute to the evolution and maturity of the enterprise 

architecture discipline, in 2002, we published version 1.0 of our 

Enterprise Architecture Management Maturity Framework

(EAMMF) as an extension of A Practical Guide to Federal 

Enterprise Architecture, Version 1.0, published by the CIO Council. 

By arranging core elements from the practical guide into a matrix of 

five hierarchical stages and four critical success attributes, this 

framework provides a common benchmarking tool for planning and 

measuring enterprise architecture efforts.22 In April 2003, we 

published version 1.1 of this framework,23 which reflects changes 

and additions that are based on comments we received on the initial 

version, as well as on our experiences in reviewing enterprise 

architecture programs. 

The EAMMF Version 1.0 

EAMMF version 1.0 is made up of five stages of maturity, each of 

which includes an associated set of elements along with all the 

elements of the previous stages. In addition to the maturity stages, 

each core element is associated with attributes that are critical to 

the successful performance of any management function. Figure 1 

shows a summary of version 1.0 of the framework and shows the 

key elements with the associated stages and attributes. 

 22U.S. General Accounting Office, Information Technology: Enterprise Architecture Use 

across the Federal Government Can Be Improved, GAO-02-6 (Washington, D.C.: Feb. 19, 

2002). 

23U.S. General Accounting Office, Information Technology: A Framework for Assessing 

and Improving Enterprise Architecture Management (Version 1.1), GAO-03-584G

(Washington, D.C.: April 2003). 
Page 11 GAO-04-798T

 Figure 1: EAMMF (Version 1.0) 

Note: Each stage includes all elements of the previous stages. 

EAMMF Version 1.1 

Version 1.1 of this framework was released in April 2003. Like the 

initial version, Version 1.1 is based on the CIO Council guidance,24

augmented by our experience in reviewing agency architecture 

 24 CIO Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0

(February 2001). 
Page 12 GAO-04-798T

programs. Changes and additions to the framework were also based 

on comments received from federal agencies on the initial version. 

Figure 2 shows a summary of Version 1.1. 
Page 13 GAO-04-798T

Figure 2: EAMMF (version 1.1) 

Note: Each stage includes all elements of the previous stages. 
Page 14 GAO-04-798T

Key Differences between EAMMF Versions 1.0 and 1.1 

Overall, version 1.1 is more demanding (i.e., sets a higher standard) 

than version 1.0 because version 1.1 adds content and links the 

framework to related IT management guidance, such as our IT 

investment management framework.25 Key differences in version 1.1 

of the framework appear first in stage 2 and affect later stages either 

explicitly or implicitly. That is, some planning elements associated 

with stage 2 now propagate explicitly through later stages as plans 

are executed and architecture products are developed, completed, 

and implemented. For example: 

● Version 1.1 includes “performance” among the models that are 

needed to describe the “as-is” and “to-be” environments; these 

models are introduced into the planning elements in stage 2 and 

built upon as plans are executed: that is, as architecture products 

are developed and completed in stages 3 and 4, respectively. 

● Version 1.1 explicitly recognizes the need to address security in the 

descriptions of the “as-is” and “to-be” environments; this element is 

introduced in stage 2 and reiterated in stages 3 and 4. 

● Version 1.1 introduces the need to plan for metrics in stage 2 and to 

measure different aspects of enterprise architecture development, 

quality, and use in stages 3, 4, and 5. 

OMB Has Made Progress on FEA, but Questions Remain 

In 2001, the lack of a federal enterprise architecture was cited by 

OMB’s E-Government Task Force as a barrier to the success of the 

administration’s e-government initiatives.26 In response, OMB began 

developing the FEA, and over the last 23 months it has released 

various versions of all but one of the five FEA reference models. 

According to OMB, the purpose of the FEA, among other things, is 

 25 U.S. General Accounting Office, Information Technology Investment Management: A 

Framework for Assessing and Improving Process Maturity, GAO-04-394G (Washington, 

D.C.: March 2004).

26 OMB’s E-Government Task Force identified 23 initiatives (two additional initiatives were 

subsequently added) aimed at improving service to individuals, service to businesses, 

intergovernmental affairs, and federal agency-to-agency efficiency and effectiveness. 
Page 15 GAO-04-798T

to provide a common frame of reference or taxonomy for agencies’ 

individual enterprise architecture efforts and their planned and 

ongoing investment activities.

OMB reports that it first began using the FEA in 2002 as part of the 

fiscal year 2004 budget cycle to identify duplicative investments, 

gaps, and opportunities for collaboration, interoperability, and 

integration within and across government agency programs. OMB 

has since required agencies to use the FEA in developing their fiscal 

year 2005 budget submissions.27 Despite OMB’s progress, however, 

questions remain about the FEA. 

OMB Has Cited a Number of Broad Purposes for the FEA 

OMB has identified multiple purposes for the FEA. One purpose 

cited is to inform agencies’ individual enterprise architectures and 

to facilitate their development by providing a common classification 

structure and vocabulary. Another stated purpose is to provide a 

governmentwide framework that can increase agencies’ awareness 

of IT capabilities that other agencies have or plan to acquire, so that 

they can explore opportunities for reuse. Still another stated 

purpose is to help OMB decision-makers identify opportunities for 

collaboration among agencies through the implementation of 

common, reusable, and interoperable solutions. To this end, the 

business reference model states that OMB will use the FEA to 

analyze agency IT investments to identify 

● which agencies share common business functions, processes, and 

activities; 

● which budget requests support duplicative business functions and 

information systems; and 

● where the government is investing money on redundant capabilities. 

According to OMB, still another purpose of the FEA is to provide the 

Congress with information that it can use as it considers the 

authorization and appropriation of funding for federal programs. 

 27 Additional Guidance on the FEA-related Requirements in OMB Circular A-11, Office 

of Management and Budget, Federal Enterprise Architecture Program Management Office. 
Page 16 GAO-04-798T

OMB Has Released Versions of Four of Five FEA Reference Models 

OMB has issued at least initial versions of four of the five reference 

models and plans to issue the fifth in the near future (see table 1). 

The following summarizes the purpose, content, and status of each 

reference model. 

Performance reference model. According to OMB, the performance 

reference model is intended to produce IT performance information, 

articulate the contribution of IT to business outputs and outcomes, 

and identify performance improvement opportunities that cross 

organizational boundaries. 

To accomplish these purposes, the model specifies measurement 

areas (e.g., mission and business results), measurement categories 

(e.g., services for citizens), and generic measurement indicators 

(e.g., delivery time) that agencies are to use to organize their 

respective measurement indicators. It also describes a process for 

agencies to use to identify and define these measurement indicators. 

Version 1.0 of the model was released in September 2003. 

Business reference model. OMB characterizes the business 

reference model as being the foundation of the FEA. It describes the 

businesses of the federal government, independent of the agencies 

that perform them. According to OMB, the purpose of the business 

reference model is to provide the basis for analyzing IT investments 

and associated budget requests relative to whether they support 

common business functions, processes, and activities. OMB expects 

agencies to use the model as part of their capital planning and 

investment control processes to help identify opportunities for 

consolidating IT investments across the federal government. 

The model consists of four business areas: (1) services for citizens, 

(2) mode of delivery, (3) support delivery of services, and 

(4) management of government resources. These four business 

areas are decomposed into 39 lines of business, which are made up 

of 153 subfunctions. Examples of lines of business under the 

“services for citizens” business area are homeland security, law 

enforcement, and economic development. For the homeland 

security line of business, an example of a subfunction is border and 

transportation security; for law enforcement, a subfunction example 
Page 17 GAO-04-798T

is citizen protection; and for economic development, a subfunction 

example is financial sector oversight. Version 1.0 of the model was 

released to agencies in July 2002. In June 2003, version 2.0 was 

released. 

Service component reference model. According to OMB, the service 

component reference model identifies and classifies IT service (i.e., 

application) components that support federal agencies so that OMB 

can identify, among other things, agencies that are building or have 

already built similar components that can be reused. Agencies are 

expected to use the service reference model to do the same. 

The model is organized as a hierarchy, beginning with seven service 

domains. These service domains are decomposed into 29 service 

types (see table 2), which are further broken down into 168 

components. For example, the customer services domain is made up 

of three service types: customer relationship management, customer 

preferences, and customer-initiated assistance. Components of the 

customer relationship management service type include call center 

management and customer analytics; components of the customer 

preferences service type include personalization and subscriptions; 

and components of the customer-initiated assistance service type 

include on-line help and on-line tutorials. Version 1.0 of the service 

component reference model was released in June 2003. 
Page 18 GAO-04-798T

Table 2. Service Domains, the Capabilities That They Describe, and Associated Service Types 

Service domain Description Service types 

Customer services Interaction between the business and the 

customer, including customer-driven activities 

(directly related to the end customer) 

Customer preferences, customer relationship 

management, and customer-initiated 

assistance 

Process automation 

services 

Automation of processes and activities that 

support managing the business 

Tracking and workflow, and routing and 

automation 

Business management 

services 

Management and execution of business 

functions and organizational activities that 

maintain continuity across the business 

Management of process, organizational 

management, supply chain management, and 

investment management 

Digital asset services Generation, management, and distribution of 

intellectual capital and electronic media 

across the business 

Content management, knowledge 

management, document management, and 

records management 

Business analytical 

services 

Extraction, aggregation, and presentation of 

information to facilitate decision analysis and 

business evaluation 

Analysis and statistics, business intelligence, 

visualization, and reporting 

Back office services Management of transaction-based functions Data management, human resources, 

financial management, assets/materials 

management, development and integration, 

and human capital/workforce management 

Support services Cross-functional capabilities that are 

independent of service domains 

Security management, systems management, 

forms, communication, collaboration, and 

search 

Source: OMB. 

Data and information reference model. The data and information 

reference model is intended to help define the types of interactions 

and information exchanges that occur between the government and 

its customers. According to OMB, the model will describe data and 

information types that support program and business line 

operations and the relationships among these types. According to 

OMB officials, the model’s release is imminent.

Technical reference model. The technical reference model is 

intended to help agencies define their respective target technical 

architectures. It describes the standards, specifications, and 

technologies that collectively support the secure delivery, exchange, 

and construction of service components. OMB describes the model 

as being made up of the following four core service areas: 
Page 19 GAO-04-798T

● Service access and delivery: the collection of standards and 

specifications that support external access, exchange, and delivery 

of service components. 

● Service platform and infrastructure: the delivery platforms and 

infrastructure that support the construction, maintenance, and 

availability of a service component or capability. 

● Component framework: the underlying foundation, technologies, 

standards, and specifications by which service components are 

built, exchanged, and deployed. 

● Service interface and integration: the collection of technologies, 

methodologies, standards, and specifications that govern how 

agencies will interface internally and externally with a service 

component. 

Each of these four core service areas is made up of service 

categories, which identify lower levels of technologies, standards, 

and specifications; service standards, which define the standards 

and technologies that support the service category; and the service 

specification, which details the standard specification or the 

provider of the specification. For example, within the first core 

service area (service access and delivery), an example of a service 

category is access channels, and service standards are Web browsers

and wireless personal digital assistants. Examples of service 

specifications for the Web browser service standard are Internet 

Explorer and Netscape Navigator. Version 1.0 of the technical 

reference model was released in January 2003 and then revised in 

August 2003 to incorporate minor revisions that were based, in part, 

on agencies’ reviews. This version—version 1.1—was used during 

the 2005 budget process. 

OMB Has Used the FEA to Identify Five Areas for Interagency Collaboration 

As part of the fiscal year 2004 budget cycle, OMB required agencies 

to align business cases for their proposed IT investments to the 

business reference model; beginning with the fiscal year 2005 

budget cycle, agencies were required to align their business cases to 

all the available reference models (i.e., the business, performance, 

technical, and service component reference models). This alignment 

activity was intended to result in the identification of redundancies 

and opportunities for collaboration. According to OMB, the fiscal 
Page 20 GAO-04-798T

year 2004 IT investment budget review process identified potential 

redundancies in six lines of business. Further analysis of these six 

lines of business as part of the fiscal year 2005 IT budget process 

resulted in OMB settling on five lines of business in which to pursue 

opportunities for collaboration (i.e., financial management, human 

resources, grants, health, and case management). 

Since then, OMB initiated a governmentwide analysis of these five 

lines of business to examine business and IT data and best practices 

for each. According to OMB, over the next several months, agencyled teams will identify common solutions and define a target 

architecture that is to be reflected in a business case for proposed 

IT investments for each line of business. The business cases are to 

be submitted for review in the fiscal year 2006 budget process. To 

this end, on April 15, 2004, OMB issued a formal request for 

information, seeking information from industry and government 

service providers on common solutions and target architectures for 

three of the five lines of business: financial management, human 

resources, and grants management. 

OMB Plans to Improve the FEA and Expand Its Use 

According to OMB officials, the FEA is in the early stages of its 

development and use, with future development and uses planned. 

OMB’s plans for improving the FEA include releasing the previously 

mentioned data and information reference model, creating a plan for 

FEA management and maintenance, revising and consolidating 

reference models, and expanding use of the automated tool for 

collecting FEA data from agencies. Each is discussed below. 

First, OMB plans to develop a formalized Management and 

Maintenance Plan that it says will provide explicit instructions to 

agencies on the roles, responsibilities, standards, and expectations 

for the management and upkeep of the FEA. Second, according to 

OMB, another planned activity is annually revising the reference 

models and consolidating all five reference models into one 

document. Specifically, it plans to (1) release a new version of the 

business reference model in mid-spring of each year, so that 

agencies will be able to use it when setting strategic budget 

priorities, and (2) create a consolidated set of models that, 
Page 21 GAO-04-798T

according to OMB, will facilitate integration of the reference models 

and changes across all the models as they are updated. Finally, it is 

expecting agencies to expand their use of the Federal Enterprise 

Architecture Management System, so that agencies themselves, 

rather than OMB, will have the means to identify opportunities for 

collaboration internally as well as across agency boundaries. 

Agencies Have Expressed High Levels of FEA Understanding and Support 

As part of our governmentwide report on enterprise architecture 

maturity, we reported on federal agency views on the FEA, 

particularly agencies’ understanding of and support for it and 

agencies’ assessment of the impact of it on their respective 

enterprise architectures.28 In general, we reported that most 

agencies understood and supported the FEA, although a handful did 

not. More specifically, of the 96 agencies that we contacted, about 

80 percent told us that they understood the goals and objectives of 

the FEA (about 8 percent did not). Additionally, about 67 percent 

said that they understood the approach OMB was following to 

develop the FEA (about 13 percent did not). 

Regarding agency support for the FEA, about 80 percent of the 

agencies said that they supported its goals and objectives (about 6 

percent did not); about 63 percent stated that they supported OMB’s 

approach to developing the FEA (about 10 percent did not). Further, 

about 72 percent told us that their respective architectures were 

traceable to the FEA (about 6 percent were not). With respect to its 

impact, about 61 percent of the agencies said that their respective 

enterprise architectures would change as a result of the FEA (about 

8 percent did not). (See table 3.) 

 28 GAO-04-40.
Page 22 GAO-04-798T

Table 3: Summary of Agencies’ Positions on the FEA 

Statement 

Percentage of agencies 

that agreed

Percentage of agencies 

that disagreed 

Percentage of 

agencies that 

neither agreed nor 

disagreed

Understand the goals and objectives 80 8 12

Understand OMB’s approach to 

development 67 13 20

Support the goals and objectives 80 6 14

Support OMB’s approach to development 63 10 27

Can trace enterprise architecture to the 

FEA 72 6 22

Will change enterprise architecture as a 

result of the FEA 61 8 31

Source: GAO. 

As the FEA Continues to Evolve, Questions Need to Be Addressed 

Despite OMB progress in developing the FEA, questions remain. We 

raise these questions in an effort to enhance agency understanding 

of the FEA and facilitate its use. As OMB continues to mature the 

FEA, these questions should be addressed. 

Should the FEA be described as an enterprise architecture? As 

discussed earlier in this statement, a true enterprise architecture is 

intended to provide a blueprint for optimizing an organization’s 

business operations and implementing the IT that supports them. 

Accordingly, well-defined enterprise architectures describe, in 

meaningful models, both the enterprise’s “as-is” and “to-be” 

environments, along with the plan for transitioning from the current 

to the target environment. To be meaningful, these models should 

be inherently consistent with one another, in view of the many 

interrelationships and interdependencies among, for example, 

business functions, the information flows among the functions, the 

security needs of this information, and the services and applications 

that support these functions. 

Our reading of the four available reference models does not 

demonstrate to us that this kind of content exists in the FEA, and 

thus we believe that the FEA is more akin to a point-in-time 

framework or classification scheme for federal government 

operations. Our discussions with OMB officials confirmed our 
Page 23 GAO-04-798T

reading of the FEA. Accordingly, if agencies use the FEA as a model 

for defining the depth and detail for their own architectures, the 

agencies’ enterprise architectures may not provide sufficient 

content for driving the implementation of systems. 

Is the expected relationship between agencies’ enterprise 

architectures and the FEA clearly articulated? According to OMB, 

the FEA is to inform agency enterprise architectures. For example, 

OMB has stated that although it is not mandating that the business 

reference model serve as the foundation for every agency’s business 

architecture, agencies should invest time mapping their respective 

business architectures to the FEA. Similarly, OMB has stated that 

agencies’ alignment of their respective architectures to the service 

component reference model and the technical reference model will 

enable each agency to categorize its IT investments according to 

common definitions. 

Such descriptions of the agency enterprise architecture/FEA 

relationship, in our view, are not clear, in part because definitions of 

such key terms as alignment, mapping, and consistency were not 

apparent in the FEA. As with any endeavor, the more ambiguity and 

uncertainty there is with requirements and expectations, the greater 

the use of assumptions and thus deviation from the intended course 

of action. This is particularly true in the area of enterprise 

architecture. 

How will the security aspects of the FEA be addressed? Our work 

has found that a well-defined enterprise architecture should include 

explicit discussion of security, including descriptions of security 

policies, procedures, rules, standards, services, and tools.29

Moreover, security is an element of the very fabric of architecture 

artifacts and models and thus should be woven into them all. As our 

experience in reviewing agency security practices and research of 

 29 U.S. General Accounting Office, DOD Business Systems Modernization: Important 

Progress Made to Develop Business Enterprise Architecture, but Much Work Remains, 

GAO-03-1018 (Washington, D.C.: Sept. 19, 2003). 
Page 24 GAO-04-798T

leading practices shows, security cannot be an afterthought when it 

comes to engineering systems or enterprises.30

OMB has stated that it plans to address security through what it 

terms a “security profile” to be added to the FEA. However, OMB 

officials could not comment on the profile’s status or development 

plans, beyond stating that the CIO Council is taking the lead in 

developing the profile. 

Overall, Federal Agency Architecture Management Is Not Mature, 

but Some Agencies Are Doing Well and Efforts Are under Way to 

Advance Governmentwide Maturity 

As we reported in 2003, while some agencies have made progress in 

improving their enterprise architecture management maturity, 

progress for the federal government as a whole has not occurred.31

In particular, the percentage of agencies that had established at least 

the foundation for effective enterprise architecture management 

was virtually unchanged from where it was in 2001 (about 50 

percent). Further, we reported that when the state of enterprise 

architecture is considered in relation to a more recent and 

demanding benchmark, this percentage dropped to about 20 percent 

(in round terms), even though some agencies fared favorably against 

this benchmark and were role models for others to follow. This 

composite picture of immature enterprise architecture management 

can be attributed to several long-standing challenges, which were 

the basis for the recommendations that we made to OMB in 2002 

and reiterated in 2003. Recently, OMB and the federal CIO Council 

began to take steps that are consistent with many of our 

recommendations. 

 30 U.S. General Accounting Office, Information Security Management: Learning From 

Leading Organizations, GAO/AIMD-98-86 (Washington, D.C.: May 1998). 

31 GAO-04-40. 
Page 25 GAO-04-798T

Governmentwide Progress in Managing Enterprise Architecture Has Been Limited 

Between 2001 and 2003, little substantial change was revealed in 

agencies’ collective enterprise architecture maturity, when this is 

compared against version 1.0 of our framework.32 Of the 93 agencies 

that we reported on in 2001 and 2003, 

● 22 agencies (24 percent) increased their maturity, 

● 24 agencies (26 percent) decreased their maturity, and 

● 47 agencies (51 percent) remained the same.33

Agencies’ progress between 2001 and 2003 is similarly limited when 

we consider the total number of EAMMF core elements satisfied. 

Specifically, the 93 agencies satisfied about 57 percent of all 

possible framework elements in 2001 and about 60 percent in 2003. 

Upon further inspection, these data show that agencies improved in 

satisfying certain core elements, but these improvements were 

offset by declines in satisfaction of other core elements. The 

following are examples of elements where agency satisfaction 

significantly improved: 

● “Metrics exist for measuring enterprise architecture benefits” (about 

a 38 percent increase), 

● “Chief architect exists” (about a 23 percent increase), and 

● “Enterprise architecture products are under configuration 

management” (about an 18 percent increase). 

The following are examples of core elements where agency 

satisfaction significantly declined: 

● “Enterprise architecture products describe ‘as-is’ environment, ‘tobe’ environment, and sequencing plan” (about a 39 percent 

decrease), 

 32 GAO-04-40.

33Numbers do not add to 100 percent due to rounding. 
Page 26 GAO-04-798T

● “Enterprise architecture products describe enterprise’s business—

and the data, applications, and technology that support it” (about a 

36 percent decrease), 

● “Either enterprise architecture steering committee, investment 

review board, or agency head has approved enterprise architecture” 

(about a 25 percent decrease), and 

● “Program office responsible for enterprise architecture development 

exists” (about a 23 percent decrease). 

For the 22 agencies that advanced one or more maturity stages from 

2001 to 2003, completion of no single core element accounted for 

these advancements. That is, for the 22 agencies, increases in 

maturity stages are most often attributable to the fulfillment of 7 

core elements spanning 3 stages of maturity. Table 4 shows those 

newly satisfied core elements that most often accounted for an 

increase in a maturity stage. 

Table 4: Core Elements That Most Frequently Contributed to Maturity Stage Increases 

Agencies increasing 

maturity stage 

Core elements whose fulfillment most frequently contributed to 

increase 

Number of agencies 

fulfilling element 

Stage 2 elements: 

Chief architect exists 6 of 12 

Program office responsible for enterprise architecture development 

exists 

6 of 12 

Committee or group representing the enterprise is responsible for 

directing, overseeing, or approving enterprise architecture 

6 of 12 

12 agencies increased 

maturity from stage 1 (6 

to stage 2, 6 to stage 3) 

Enterprise architecture being developed using framework and 

automated tool 

4 of 12 

Stage 3 elements: 

Enterprise architecture products are under configuration 

management 

7 of 8 

8 agencies increased 

maturity from stage 2 (6 

to stage 3, 1 to stage 4, 1 

to stage 5) Written and approved policy exists for enterprise architecture 

development 

5 of 8 

2 agencies increased Stage 5 element: 

maturity from stage 4 Metrics exist for measuring enterprise architecture benefits 2 of 2 

Source: GAO analysis of survey data. 

As with increases in agency maturity levels, no single core element 

accounted for the decreases in agency maturity between 2001 and 

2003. However, as shown in table 5, the stage 2 framework element 

requiring a program office was the most significant newly 
Page 27 GAO-04-798T

unsatisfied element for the 24 agencies that had decreased maturity 

levels. 

Table 5: Core Elements That Most Frequently Contributed to Maturity Stage Decreases 

Agencies decreasing 

maturity stage 

Core elements whose fulfillment most frequently contributed to 

decrease 

Number of agencies 

not fulfilling 

element 

Stage 2 elements: 

Program office responsible for enterprise architecture development 

exists 

13 of 16 

16 agencies decreased 

maturity to stage 1 (12 

from stage 2, 4 from 

stage 3) Chief architect exists 4 of 16 

Stage 3 elements: 

Written and approved policy exists for enterprise architecture 

development 

6 of 7 

7 agencies decreased 

maturity to stage 2 (6 

from stage 3, 1 from 

stage 4) Enterprise architecture products are under configuration 

management 

3 of 7 

Stage 4 elements: 

Enterprise architecture products describe ‘as-is’ environment, ’tobe’ environment, and sequencing plan 

1 of 1 

1 agency decreased 

maturity to stage 3 (from 

stage 4) 

Enterprise architecture products describe enterprise’s business—

and the data, applications, and technology that support it 

1 of 1 

Source: GAO analysis of survey data. 

One factor contributing to the decreases in maturity between 2001 

and 2003 is improved accuracy in agencies’ responses to our data 

collection instrument. Improved accuracy is a function of 

(1) improved agency familiarity with and understanding of 

enterprise architecture management and our framework and (2) the 

requirement in our 2003 work for documentation to support certain 

agency responses. 

Overall, the State of Architecture Development and Use in Federal Agencies Is Uneven 

and Needs to Improve 

When compared against version 1.1 of our framework, the state of 

enterprise architecture management across the federal government 

is not mature. In particular, about 21 percent of federal agencies (20 

of 96) have the stage 2 management foundation that is needed to 

begin successfully developing, implementing, and maintaining an 

enterprise architecture, and about 79 percent of agencies (76 of 96) 

have not yet advanced to this basic stage of maturity. (One agency, 

the Executive Office of the President, was at a stage of maturity that 

can be considered effective.) This overall state of maturity is 
Page 28 GAO-04-798T

consistent for each of the three agency groups surveyed: 

departments, component agencies, and independent agencies. 

No single core element that was added to our framework 

contributed significantly to this current state, but the “methodology” 

subelement of the stage 2 element “Enterprise architecture is being 

developed with a framework, methodology, and automated tool” 

was the most significant factor that kept agencies from achieving 

stage 2. The absence of a “methodology” kept seven agencies from 

attaining stage 2 status. 

Nevertheless, certain core elements of version 1.1 of our framework 

were frequently not satisfied by agencies. Of the 31 core elements in 

version 1.1, 17 were not satisfied by more than 50 percent of the 

agencies. Further, 8 elements associated with stages 4 and 5 were 

not satisfied by about 80 percent of the agencies. 

Although significant gaps existed across federal agencies in meeting 

the core elements of version 1.1 of the framework, at least 80 

percent of the agencies reported performing 8 core elements that 

were related to stages 2 and 3. The most often satisfied elements 

included the following stage 2 elements: 

● “Enterprise architecture plans call for describing both the ‘as-is’ and 

the ‘to-be’ environments of the enterprise, as well as a sequencing 

plan for transitioning from the ‘as-is’ to the ‘to-be’”(about 94 

percent); 

● “Enterprise architecture plans call for describing both the ‘as-is’ and 

the ‘to-be’ environments in terms of business, performance, 

information/data, application/service, and technology” (about 90 

percent); and 

● “Enterprise architecture plans call for business, performance, 

information/data, application/service, and technology descriptions 

to address security” (about 86 percent). 

The most often satisfied elements also included the stage 3 element 

● “Enterprise architecture products describe or will describe both the 

‘as-is’ and the ‘to-be’ environments of the enterprise, as well as a 
Page 29 GAO-04-798T

sequencing plan for transitioning from the ‘as-is’ to the ‘to-be’” 

(about 88 percent). 

In addition, although only one agency has achieved stage 5, many 

agencies reported satisfying the stage 5 core elements requiring that 

IT investments comply with their enterprise architecture (about 80 

percent) and that enterprise architecture is an integral component 

of their IT investment management process (about 69 percent). 

Departments, component agencies, and independent agencies had 

varying degrees of success satisfying certain core elements within 

individual stages. In general, departments had more success 

satisfying lower stage elements than did components and 

independent agencies. In stage 2, for example, while 69 percent of 

departments reported using a framework, methodology, and 

automated tool to develop their enterprise architecture, only 29 

percent of components and 50 percent of independent agencies 

reported the same. Additionally, in stage 3, while 81 percent of 

departments reported that progress against plans is measured and 

reported, only 25 percent of components and 25 percent of 

independent agencies reported the same. One possible reason for 

this situation is that OMB’s oversight of agency enterprise 

architecture efforts focuses on departments and major independent 

agencies—not on component agencies. 

Although, as a whole, departments satisfied more lower-level 

framework elements than did component agencies and independent 

agencies, departments generally still would need to satisfy several 

lower-level framework elements to achieve a stage 3 maturity level. 

On average, each department needs to satisfy 2 core elements to 

satisfy all stage 2 and 3 framework elements. 

The maturity stage of a department generally was not indicative of 

the maturity of its component agencies. For example, the 

Departments of Health and Human Services and Transportation 

reached stage 2, while their component agencies averaged stage 1. 
Page 30 GAO-04-798T

Also, DOD’s Global Information Grid architecture34 was at stage 3, 

while its business enterprise architecture was at stage 1, as were its 

components, in general. Conversely, the Departments of Commerce, 

Justice, and the Treasury were at stage 1, with their component 

agencies averaging higher maturity levels; the component agencies 

of Commerce showed a slightly higher maturity level than did 

component agencies of all other departments. That is, the average 

maturity level of all component agencies we surveyed was 1.23, but 

the Commerce component agencies averaged 1.80, largely owing to 

the maturity levels for the Bureau of the Census (stage 3), the U.S. 

Patent and Trademark Office (stage 2), and the National Oceanic 

and Atmospheric Administration (stage 2). The Department of 

Agriculture’s maturity level (stage 1) was the same as the average 

maturity level of its component agencies. 

Eight Agencies Were Well Positioned to Achieve Stage 5 Maturity, and Many Agencies 

Were Performing Core Elements beyond Their Assigned Maturity Stages 

Although the Executive Office of the President was the sole stage 5 

agency, seven other agencies were close to becoming models of 

enterprise architecture management. For example, the Office of 

Personnel Management (OPM), which achieved stage 1 of version 

1.1, needed to satisfy only five more elements to become a stage 5 

agency. OPM needed to satisfy one stage 2 element (“Enterprise 

architecture plans call for developing metrics for measuring 

enterprise architecture progress, quality, compliance, and return on 

investment”), one stage 3 element (“Progress against enterprise 

architecture plans is measured and reported”), two stage 4 elements 

(“Enterprise architecture products and management processes 

undergo independent verification and validation” and “Quality of 

enterprise architecture products is measured and reported”), and 

one stage 5 element (“Return on enterprise architecture investment 

is measured and reported”). 

 34The GIG architecture describes the globally interconnected, end-to-end set of information 

capabilities, associated processes, and personnel for collecting, processing, storing, 

disseminating, and managing information on demand to war fighters, policy makers, and 

support personnel. 
Page 31 GAO-04-798T

Ninety-six percent of agencies in stages 1 through 4 were 

performing at least one core element above their current maturity 

stage,35 which means that as a whole, agencies are, to varying 

degrees, performing above their assigned maturity stages. 

Specifically, of the 76 agencies at stage 1, about 95 percent were 

performing at least one core element in a higher maturity stage. 

About 35 percent of agencies need to satisfy only one additional 

core element to advance to at least the next maturity stage. Two of 

these agencies, Commerce and the U.S. Mint, could advance two 

stages by satisfying just one additional core element. Commerce, 

currently a stage 1 agency, could advance to stage 3 by satisfying the 

framework element “Program office responsible for development 

and maintenance exists.” The Mint, also currently a stage 1 agency, 

could advance to stage 3 by satisfying the framework element 

“Adequate resources exist.” 

Agencies Identified Enterprise Architecture Management Challenges 

Agencies continue to face the same management challenges that we 

identified in 2001—that is, obtaining top management support and 

commitment, overcoming parochialism, and having the requisite 

resources (financial and human capital) to accomplish the work. 

Moreover, the prevalence of these challenges has grown. For 

example, getting top management to understand the purpose, 

content, and value of architectures was seen as a challenge by about 

50 percent of agencies—up from 39 percent in 2001. As our 

framework recognizes, obtaining executive understanding and 

support is essential to having an effective enterprise architecture 

program. Without it, agencies will have increased difficulty in 

addressing other challenges such as overcoming parochialism 

among organizational components and obtaining requisite resources 

(funding and human capital). Our work in 2003 bears this out—at 

the same time that the percentage of agencies identifying top 

management understanding and support as a challenge rose, the 

percentage of agencies identifying these other challenges almost all 

 35One agency—the Executive Office of the President—is currently performing at stage 5 

and cannot perform above its current maturity stage. As a result, it is excluded from this 

analysis. 
Page 32 GAO-04-798T

rose. For example, the percentage that identified parochialism as a 

challenge grew from about 39 to 47 percent. Also, while about 50 

percent of agencies continued to report funding as a significant 

challenge, the percentage of agencies that reported obtaining skilled 

staff as a challenge grew from about 32 to 49 percent. (See table 6.) 

Table 6: Change in Prevalence of Enterprise Architecture Management Challenges 

Percentage of agencies 

that frequently identified 

management challenge 

Management challenge 2001 survey 2003 survey

Fostering top management understanding 39 50

Overcoming parochialism 39 47

Ensuring adequate funding 50 50

Obtaining skilled staff 32 49

Source: GAO analysis of survey data. 

Agencies have also reported mixed levels of satisfaction with OMB’s 

efforts to address these management challenges. Specifically, just 

over half of the agencies were satisfied with OMB’s efforts to foster 

top management understanding and to overcome agency component 

organization parochialism (about 58 and 53 percent, respectively). 

Moreover, fewer than half of the agencies (40 percent) were 

satisfied with OMB’s actions to address their enterprise architecture 

funding and staffing challenges. (See table 7.) 

Table 7: Percentage of Agencies Satisfied with OMB’s Efforts to Address Various Management Challenges 

Management challenge 

Percentage of agencies 

satisfied a Percentage of agencies 

dissatisfied a

Percentage of agencies 

neither satisfied nor 

dissatisfied a

Fostering top management 

understanding 58 14 27

Overcoming parochialism 53 10 37

Ensuring adequate funding 40 26 34

Obtaining skilled staff 40 15 45

Source: GAO analysis of survey data. 

a Numbers do not add to 100 percent due to rounding. 
Page 33 GAO-04-798T

OMB and the Federal CIO Council Have Recently Acted to Strengthen Agency 

Enterprise Architecture Maturity 

Both OMB and the federal CIO Council have long been advocates of 

enterprise architecture. For example, in collaboration with others 

and us, OMB issued guidance on the purpose and use of enterprise 

architectures shortly after passage of the Clinger-Cohen Act of 

1996.36 Subsequently, it incorporated enterprise architecture 

considerations into its oversight processes and issued guidance 

directing that agency IT investments be based on agency enterprise 

architectures.37 Further, OMB collaborated with the CIO Council and 

us on the Practical Guide to Federal Enterprise Architecture, 

Version 1.0. As a means of promoting agencies’ enterprise 

architecture use, OMB has also included requirements for having 

and using enterprise architectures as part of the budget process, 

which began with the fiscal year 2002 budget cycle and, according to 

OMB officials, has continued since then. OMB has also worked 

through the CIO Council, which is chaired by OMB, to improve 

enterprise architecture management and use. 

Despite OMB’s longstanding advocacy and support for enterprise 

architecture, we reported in 2002 that OMB needed to advance the 

level of enterprise architecture management maturity by exercising 

stronger leadership and improved oversight and by identifying 

governmentwide solutions to common enterprise architecture 

management challenges facing agencies. Accordingly, we 

recommended that the OMB Director, in collaboration with the 

federal CIO Council, use our maturity framework and the agency 

baseline information provided in our February 2002 report as the 

basis for helping agencies to advance the state of their respective 

enterprise architecture development, implementation, and 

maintenance efforts, and for measuring agency progress. We further 

recommended that in doing so, the OMB Director require agencies 

to (1) submit to OMB an annual update of the agency’s satisfaction 

 36 OMB, Information Technology Architectures, Memorandum M-97-16 (June 18, 1997); 

rescinded with the update of OMB Circular A-130 (Nov. 28, 2000). 

37 OMB, Management of Federal Information Resources, Circular No. A-130 (Nov. 28, 

2000). 
Page 34 GAO-04-798T

of each of the core elements contained in our maturity framework 

and (2) have this update verified by the agency’s inspector general 

or comparable audit function before it is submitted to OMB. 

Additionally, we recommended that the OMB Director, in 

collaboration with the CIO Council, develop and implement a plan 

to address the governmentwide impediments to greater agency use 

of enterprise architectures. We recommended that, at a minimum, 

this plan should include the two primary challenges identified in our 

2002 report—that is, agency executive management understanding 

of enterprise architectures and the availability of enterprise 

architecture human capital expertise. Finally, we recommended that 

the director report annually to the Senate Committee on 

Governmental Affairs and the House Committee on Government 

Reform on the results of OMB’s annual update of the state and 

progress of federal agencies’ enterprise architecture efforts. OMB 

officials generally agreed with the findings and conclusions of our 

report and stated that they would consider using our framework. 

As previously noted, we reported in 2003 that agencies had 

collectively made little progress toward improving their enterprise 

architecture maturity. In commenting on this report, OMB officials 

told us that they were still considering using our framework as a 

basis for evaluating agencies’ progress in developing and 

implementing their architectures, but had not committed to doing so 

because they were still reviewing options. Additionally, these 

officials did not have any plans to address governmentwide 

impediments to greater agency use of architectures. Further, they 

said that OMB has provided and plans to continue to provide 

information to the Congress on the state of agency enterprise 

architecture efforts and on progress in implementing the FEA. As a 

result, we again called for stronger leadership and reiterated the 

recommendations we made in our February 2002 report, with the 

modification that OMB use version 1.1 of our framework and the 

baseline data from our 2003 report. Additionally, we recommended 

that the OMB Director, in developing and implementing the plan we 

previously recommended to address governmentwide impediments 

to greater agency use of enterprise architectures, ensure that the 

plan provides for identifying agencies that have effectively 

overcome enterprise architecture management challenges and 

sharing those and other lessons learned and best practices. Also, we 
Page 35 GAO-04-798T

recommended that the director, in annually reporting to the Senate 

Committee on Governmental Affairs and the House Committee on 

Government Reform, as we previously recommended, include in the 

report what steps have been taken to implement our 

recommendations, including reasons for not adopting our maturity 

framework. 

OMB and the CIO Council have recently initiated actions consistent 

with many of our recommendations. For example, the council 

established a Chief Architect Forum, the first meeting of which was 

held on April 5, 2004, and in which we participated. This forum has 

created a means for chief architects across federal agencies to 

systematically collaborate on matters of mutual concern and 

interest. Vehicles for this collaboration include periodic meetings, a 

listserve to share information and ideas, and special gatherings that 

focus on specific issues. As another example, OMB recently released 

for comment version 1.0 of an agency enterprise architecture 

assessment tool. The tool is intended to help individual agencies 

assess their enterprise architecture programs. According to OMB, 

this initial version will be revised to reflect comments it receives. 

In summary, enterprise architecture development and use in the 

federal government are maturing, but they are not mature. Given 

that effective development and use of enterprise architectures are 

critical to federal agencies achieving breakthrough levels of 

performance, senior leadership across the government needs to 

elevate its attention to this essential transformation and 

modernization tool. While progress on this front has occurred over 

the last few years, it has been spotty, and in our view, considerable 

maturation is needed before the federal government will be 

positioned to reap the rewards that others have reported from 

effective architecture development and use. The fact remains that 

until agencies have and use well-defined enterprise architectures, 

they will be severely challenged in their ability to effectively 

leverage IT in transforming their operations. Recent steps by OMB 

and the CIO Council to assume stronger leadership roles are 

encouraging. However, hard work lies ahead to clarify and evolve 
Page 36 GAO-04-798T

the FEA, and to ensure that well-managed architecture programs—

ones that produce architecture blueprints that can be implemented 

and become integral parts of the fabric of institutional strategic 

planning, investment decision-making, and budget execution—are 

actually established across the government. These are important 

goals, which we support, and we will continue to work with OMB 

and the CIO Council throughout the multistep process needed to 

ensure that the FEA is appropriately described, matured, and used, 

and to advance the state of agency enterprise architecture efforts. 

Mr. Chairman, that concludes my testimony. I would be pleased to 

answer any questions that you and the other Members of the 

Subcommittee may have. 

Contact and Acknowledgements 

For further information, please contact Randolph C. Hite at (202) 

512-6256 or by e-mail at hiter@gao.gov. Other key contributors to 

this testimony included Shannin Addison, Mark Bird, Barbara 

Collier, Nancy Glover, Anh Le, Nnaemeka Okonkwo, Randolph 

Tekeley, and William Wadsworth. 

(310280) 
This is a work of the U.S. government and is not subject to copyright protection in the 

United States. It may be reproduced and distributed in its entirety without further 

permission from GAO. However, because this work may contain copyrighted images or 

other material, permission from the copyright holder may be necessary if you wish to 

reproduce this material separately. 
The General Accounting 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. 

The fastest and easiest way to obtain copies of GAO documents at no cost is 

through the Internet. GAO’s Web site (www.gao.gov) contains abstracts and fulltext files of current reports and testimony and an expanding archive of older 

products. The Web site features a search engine to help you locate documents 

using key words and phrases. You can print these documents in their entirety, 

including charts and other graphics. 

Each day, GAO issues a list of newly released reports, testimony, and 

correspondence. GAO posts this list, known as “Today’s Reports,” on its Web site 

daily. The list contains links to the full-text document files. To have GAO e-mail 

this list to you every afternoon, go to www.gao.gov and select “Subscribe to e-mail 

alerts” under the “Order GAO Products” heading. 

The first copy of each printed report is free. Additional copies are $2 each. A 

check or money order should be made out to the Superintendent of Documents. 

GAO also accepts VISA and Mastercard. Orders for 100 or more copies mailed to a 

single address are discounted 25 percent. Orders should be sent to: 

U.S. General Accounting Office 

441 G Street NW, Room LM 

Washington, D.C. 20548 

To order by Phone: Voice: (202) 512-6000 

TDD: (202) 512-2537 

Fax: (202) 512-6061 

Contact: 

Web site: www.gao.gov/fraudnet/fraudnet.htm 

E-mail: fraudnet@gao.gov

Automated answering system: (800) 424-5454 or (202) 512-7470 

Jeff Nelligan, Managing Director, NelliganJ@gao.gov (202) 512-4800 

U.S. General Accounting Office, 441 G Street NW, Room 7149 

Washington, D.C. 20548 

GAO’s Mission 

Obtaining Copies of 

GAO Reports and 

Testimony 

Order by Mail or Phone 

To Report Fraud, 

Waste, and Abuse in 

Federal Programs 

Public Affairs