This is the accessible text file for GAO report number GAO-04-798T 
entitled 'Information Technology: The Federal Enterprise Architecture 
and Agencies' Enterprise Architectures Are Still Maturing' which was 
released on May 19, 2004.

This text file was formatted by the U.S. General Accounting 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.

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:

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:

GAO-04-798T:

GAO Highlights:

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. 

Why GAO Did This Study:

The concept of enterprise architecture emerged in the mid-1980s 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.

What GAO Found:

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: 

[See PDF for image]

[End of table]

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.

[End of section]

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.[Footnote 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 OMB on the FEA, as well 
as discussions with GAO's Executive Council on Information Management 
and Technology.[Footnote 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 progress toward effectively 
managing enterprise architectures was limited, with much work 
remaining.[Footnote 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.

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 "to-be" 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 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)[Footnote 4] and "Line of 
Business"[Footnote 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.[Footnote 
6] Accordingly, Zachman developed a structure or framework for defining 
and capturing an architecture, which provides for six "windows" from 
which to view the enterprise.[Footnote 7] Zachman also proposed six 
abstractions or models associated with each of these 
perspectives.[Footnote 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.[Footnote 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, 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: Performance reference Model; 
Description: Provides a common set of general performance outputs and 
measures for agencies to use to achieve business goals and objectives; 
Status: Version 1.0 released in September 2003.

Reference model: Business reference model; 
Description: Describes the hierarchy of federal business operations 
independent of the agencies that perform them, including defining the 
services provided to state and local governments; 
Status: Version 2.0 released in June 2003.

Reference model: Service component reference model; 
Description: Identifies and classifies IT service (i.e., application) 
components that support federal business operations and promotes the 
reuse of components across agencies; 
Status: Version 1.0 released in June 2003.

Reference model: Data and information reference model; 
Description: 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; 
Status: Release planned in 2004.

Reference model: Technical reference model; 
Description: Describes technology that is to support the delivery of 
service components, including relevant standards for implementing the 
technology; 
Status: Version 1.1 released in August 2003. 

Source: GAO analysis based on OMB data.

[End of table]

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 the Clinger-
Cohen Act in 1996,[Footnote 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,[Footnote 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,[Footnote 12] the Federal 
Aviation Administration air traffic control modernization,[Footnote 
13] and the Internal Revenue Service tax systems 
modernization.[Footnote 14] 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,[Footnote 15] the 
former Customs Service,[Footnote 16] the former Immigration and 
Naturalization Service,[Footnote 17] the Centers for Medicare and 
Medicaid Services,[Footnote 18] the Department of Defense 
(DOD),[Footnote 19] the Federal Bureau of Investigation,[Footnote 20] 
and the National Aeronautics and Space Administration.[Footnote 21] 
These 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.

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.[Footnote 22] In April 2003, we published version 1.1 of this 
framework,[Footnote 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.

Figure 1: Figure 1: EAMMF (Version 1.0):

[See PDF for image]

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

[End of figure]

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,[Footnote 24] augmented by our experience in reviewing agency 
architecture 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.

Figure 2: EAMMF (version 1.1):

[See PDF for image]

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

[End of figure]

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

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

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

Service domain: Customer services; 
Description: Interaction between the business and the customer, 
including customer-driven activities (directly related to the end 
customer); 
Service types: Customer preferences, customer relationship management, 
and customer-initiated assistance.

Service domain: Process automation services; 
Description: Automation of processes and activities that support 
managing the business; 
Service types: Tracking and workflow, and routing and automation.

Service domain: Business management services; 
Description: Management and execution of business functions and 
organizational activities that maintain continuity across the business; 
Service types: Management of process, organizational management, supply 
chain management, and investment management.

Service domain: Digital asset services; 
Description: Generation, management, and distribution of intellectual 
capital and electronic media across the business; 
Service types: Content management, knowledge management, document 
management, and records management.

Service domain: Business analytical services; 
Description: Extraction, aggregation, and presentation of information 
to facilitate decision analysis and business evaluation; 
Service types: Analysis and statistics, business intelligence, 
visualization, and reporting.

Service domain: Back office services; 
Description: Management of transaction-based functions; 
Service types: Data management, human resources, financial management, 
assets/materials management, development and integration, and human 
capital/workforce management.

Service domain: Support services; 
Description: Cross-functional capabilities that are independent of 
service domains; 
Service types: Security management, systems management, forms, 
communication, collaboration, and search. 

Source: OMB.

[End of table]

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:

* 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 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, agency-led 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, 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.[Footnote 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.):

Table 3: Summary of Agencies' Positions on the FEA:

Statement: Understand the goals and objectives; 
Percentage of agencies that agreed: 80; 
Percentage of agencies that disagreed: 8; 
Percentage of agencies that neither agreed nor disagreed: 12.

Statement: Understand OMB's approach to development; 
Percentage of agencies that agreed: 67; 
Percentage of agencies that disagreed: 13; 
Percentage of agencies that neither agreed nor disagreed: 20.

Statement: Support the goals and objectives; 
Percentage of agencies that agreed: 80; 
Percentage of agencies that disagreed: 6; 
Percentage of agencies that neither agreed nor disagreed: 14.

Statement: Support OMB's approach to development; 
Percentage of agencies that agreed: 63; 
Percentage of agencies that disagreed: 10; 
Percentage of agencies that neither agreed nor disagreed: 27.

Statement: Can trace enterprise architecture to the FEA; 
Percentage of agencies that agreed: 72; 
Percentage of agencies that disagreed: 6; 
Percentage of agencies that neither agreed nor disagreed: 22.

Statement: Will change enterprise architecture as a result of the FEA; 
Percentage of agencies that agreed: 61; 
Percentage of agencies that disagreed: 8; 
Percentage of agencies that neither agreed nor disagreed: 31. 

Source: GAO.

[End of table]

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 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.[Footnote 
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 
leading practices shows, security cannot be an afterthought when it 
comes to engineering systems or enterprises.[Footnote 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.[Footnote 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.

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.[Footnote 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.[Footnote 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, 'to-
be' environment, and sequencing plan" (about a 39 percent decrease),

* "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: 12 agencies increased 
maturity from stage 1 (6 to stage 2, 6 to stage 3); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 2 elements: Chief architect exists; 
Number of agencies fulfilling element: 6 of 12.

Agencies increasing maturity stage: 12 agencies increased 
maturity from stage 1 (6 to stage 2, 6 to stage 3); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 2 elements: Program office responsible for enterprise 
architecture development exists; 
Number of agencies fulfilling element: 6 of 12.

Agencies increasing maturity stage: 12 agencies increased 
maturity from stage 1 (6 to stage 2, 6 to stage 3); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 2 elements: Committee or group representing the 
enterprise is responsible for directing, overseeing, or approving 
enterprise architecture; 
Number of agencies fulfilling element: 6 of 12.

Agencies increasing maturity stage: 12 agencies increased 
maturity from stage 1 (6 to stage 2, 6 to stage 3); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 2 elements: Enterprise architecture being developed 
using framework and automated tool; 
Number of agencies fulfilling element: 4 of 12.

Agencies increasing maturity stage: 8 agencies increased 
maturity from stage 2 (6 to stage 3, 1 to stage 4, 1 to stage 5); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 3 elements: Enterprise architecture products are under 
configuration management; 
Number of agencies fulfilling element: 7 of 8.

Agencies increasing maturity stage: 8 agencies increased 
maturity from stage 2 (6 to stage 3, 1 to stage 4, 1 to stage 5); 
Core elements whose fulfillment most frequently contributed to 
increase: Stage 3 elements: Written and approved policy exists for 
enterprise architecture development; 
Number of agencies fulfilling element: 5 of 8.

Core elements whose fulfillment most frequently contributed to 
increase: Stage 5 element: Metrics exist for measuring enterprise 
architecture benefits; 
Number of agencies fulfilling element: 2 of 2. 

Source: GAO analysis of survey data.

[End of table]

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 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: 16 agencies decreased maturity to 
stage 1 (12 from stage 2, 4 from stage 3); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 2 elements: Program office responsible for enterprise 
architecture development exists; 
Number of agencies not fulfilling element: 13 of 16.

Agencies decreasing maturity stage: 16 agencies decreased maturity to 
stage 1 (12 from stage 2, 4 from stage 3); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 2 elements: Chief architect exists; 
Number of agencies not fulfilling element: 4 of 16.

Agencies decreasing maturity stage: 7 agencies decreased maturity to 
stage 2 (6 from stage 3, 1 from stage 4); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 3 elements: Written and approved policy exists for 
enterprise architecture development; 
Number of agencies not fulfilling element: 6 of 7.

Agencies decreasing maturity stage: 7 agencies decreased maturity to 
stage 2 (6 from stage 3, 1 from stage 4); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 3 elements: Enterprise architecture products are under 
configuration management; 
Number of agencies not fulfilling element: 3 of 7.

Agencies decreasing maturity stage: 1 agency decreased maturity to 
stage 3 (from stage 4); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 4 elements: Enterprise architecture products describe 
'as-is' environment, 'to-be' environment, and sequencing plan; 
Number of agencies not fulfilling element: 1 of 1.

Agencies decreasing maturity stage: 1 agency decreased maturity to 
stage 3 (from stage 4); 
Core elements whose fulfillment most frequently contributed to 
decrease: Stage 4 elements: Enterprise architecture products describe 
enterprise's business--and the data, applications, and technology that 
support it; 
Number of agencies not fulfilling element: 1 of 1. 

Source: GAO analysis of survey data.

[End of table]

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 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 
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. Also, DOD's Global 
Information Grid architecture[Footnote 34] 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").

Ninety-six percent of agencies in stages 1 through 4 were performing at 
least one core element above their current maturity stage,[Footnote 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 
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:

Management challenge: Fostering top management understanding; 
Percentage of agencies that frequently identified management challenge: 
2001 survey: 39; 
Percentage of agencies that frequently identified management challenge: 
2003 survey: 50.

Management challenge: Overcoming parochialism; 
Percentage of agencies that frequently identified management challenge: 
2001 survey: 39; 
Percentage of agencies that frequently identified management challenge: 
2003 survey: 47.

Management challenge: Ensuring adequate funding; 
Percentage of agencies that frequently identified management challenge: 
2001 survey: 50; 
Percentage of agencies that frequently identified management challenge: 
2003 survey: 50.

Management challenge: Obtaining skilled staff; 
Percentage of agencies that frequently identified management challenge: 
2001 survey: 32; 
Percentage of agencies that frequently identified management challenge: 
2003 survey: 49. 

Source: GAO analysis of survey data.

[End of table]

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: Fostering top management understanding; 
Percentage of agencies satisfied[A]: 58; 
Percentage of agencies dissatisfied[A]: 14; 
Percentage of agencies neither satisfied nor dissatisfied[A]: 27.

Management challenge: Overcoming parochialism; 
Percentage of agencies satisfied[A]: 53; 
Percentage of agencies dissatisfied[A]: 10; 
Percentage of agencies neither satisfied nor dissatisfied[A]: 37.

Management challenge: Ensuring adequate funding; 
Percentage of agencies satisfied[A]: 40; 
Percentage of agencies dissatisfied[A]: 26; 
Percentage of agencies neither satisfied nor dissatisfied[A]: 34.

Management challenge: Obtaining skilled staff; 
Percentage of agencies satisfied[A]: 40; 
Percentage of agencies dissatisfied[A]: 15; 
Percentage of agencies neither satisfied nor dissatisfied[A]: 45. 

Source: GAO analysis of survey data.

[A] Numbers do not add to 100 percent due to rounding.

[End of table]

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

FOOTNOTES

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

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



[3] GAO-04-40.

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

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

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

[11] Public Law 107-347.

[12] U.S. General Accounting Office, Weather Forecasting: Systems 
Architecture Needed for National Weather Service Modernization, GAO/
AIMD-94-28 (Washington, D.C.: Mar. 11, 1994).

[13] U.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).

[14] U.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).

[15] U.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).

[16] U.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).

[17] U.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).

[18] U.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).

[22] U.S. General Accounting Office, Information Technology: Enterprise 
Architecture Use across the Federal Government Can Be Improved, GAO-02-
6 (Washington, D.C.: Feb. 19, 2002).

[23] U.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).

[24] CIO Council, A Practical Guide to Federal Enterprise Architecture, 
Version 1.0 (February 2001).

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

[27] Additional Guidance on the FEA-related Requirements in OMB 
Circular A-11, Office of Management and Budget, Federal Enterprise 
Architecture Program Management Office.

[28] GAO-04-40.

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

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

[32] GAO-04-40.

[33] Numbers do not add to 100 percent due to rounding.

[34] The 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.

[35] One 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.

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