Information Technology: The Federal Enterprise Architecture and
Agencies' Enterprise Architectures Are Still Maturing (19-MAY-04,
GAO-04-798T).
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.
-------------------------Indexing Terms-------------------------
REPORTNUM: GAO-04-798T
ACCNO: A10140
TITLE: Information Technology: The Federal Enterprise
Architecture and Agencies' Enterprise Architectures Are Still
Maturing
DATE: 05/19/2004
SUBJECT: Information technology
Strategic planning
Performance measures
Productivity in government
Enterprise architecture
******************************************************************
** This file contains an ASCII representation of the text of a **
** GAO Product. **
** **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced. Tables are included, but **
** may not resemble those in the printed version. **
** **
** Please see the PDF (Portable Document Format) file, when **
** available, for a complete electronic file of the printed **
** document's contents. **
** **
******************************************************************
GAO-04-798T
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
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.
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.
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 V
1.0, measures for agencies to use to achieve business goals and September
objectives. 2003
Business Describes the hierarchy of federal business operations
independent of the agencies that perform them, including V 2.0, defining
the services provided to state and local governments. June 2003
Service Identifies and classifies IT service (i.e., application)
components component that support federal business operations and promotes
the reuse V 1.0,
of components across agencies June 2003
Data and Is
intended to
describe, at an
aggregate level,
the types of data
information and
information that
support program ad
www.gao.gov/cgi-bin/getrpt?GAO-04-798T. business line Planned
operatin and the for 2004
hierarchical
relationships among
them.
Technical Describes
how technology is
supporting the V 1.1,
delivery of service August
components, 2003
To view the full product, including the including relevant
scope and methodology, click on the link implementation
above. standards.
Source: GAO
For more information, contact Randy Hite at analysis of OMB
data.
202-512-6256 or [email protected].
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).
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.
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.
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
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).
"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.
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 Provides a common set of general performance outputs
and Version 1.0 released
Model measures for agencies to use to achieve business goals and
objectives.
in September 2003 Business reference model Describes the hierarchy of federal
business operations Version 2.0 released
independent of the agencies that perform them, including defining the
services provided to state and local governments.
in June 2003
Service component Identifies and classifies IT service (i.e., application)
components Version 1.0 released reference model that support federal
business operations and promotes the reuse in June 2003
of components across agencies.
Data and information Is intended to describe, at an aggregate level, the
data and Release planned in reference model information types that support
program and business line 2004
operations and the hierarchical relationships among these types.
Technical reference model Describes technology that is to support the
delivery of service Version 1.1 released components, including relevant
standards for implementing the in August 2003 technology.
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
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).
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.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.
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).
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).
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).
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)
Note: Each stage includes all elements of the previous stages.
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:
0MVersion 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.
0MVersion 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.
0MVersion 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.
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
0Mwhich agencies share common business functions, processes, and
activities;
0Mwhich budget requests support duplicative business functions and
information systems; and
0Mwhere 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.
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 Description Service types
Customer services Interaction between the business and the Customer
preferences, customer relationship customer, including customer-driven
activities management, and customer-initiated (directly related to the end
customer) assistance
Process automation Automation of processes and activities that Tracking
and workflow, and routing and services support managing the business
automation
Business management Management and execution of business Management of
process, organizational
services functions and organizational activities that management, supply
chain management, and maintain continuity across the business investment
management
Digital asset Generation, management, and Content management,
services distribution of knowledge
intellectual capital and management, document
electronic media management, and
across the business records management
Extraction, aggregation, and Analysis and statistics,
Business analytical presentation of business intelligence,
services information to facilitate visualization, and
decision analysis and reporting
business evaluation
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 Security
management, systems management, independent of service domains 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:
0M Service access and delivery: the collection of standards and
specifications that support external access, exchange, and delivery of
service components.
0M Service platform and infrastructure: the delivery platforms and
infrastructure that support the construction, maintenance, and
availability of a service component or capability.
0M Component framework: the underlying foundation, technologies,
standards, and specifications by which service components are built,
exchanged, and deployed.
0M 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, 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,
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.
Table 3: Summary of Agencies' Positions on the FEA
Percentage of
agencies that
Percentage of agencies Percentage of agencies neither agreed nor
Statement that agreed that disagreed disagreed
Understand the goals and objectives 80 8
Understand OMB's approach to
development 67 13
Support the goals and objectives 80 6
Support OMB's approach to development 63 10
Can trace enterprise architecture to the
FEA 726
Will change enterprise architecture as a
result of the FEA 61 8
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
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).
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.
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,
0M22 agencies (24 percent) increased their maturity, 0M24 agencies (26
percent) decreased their maturity, and 0M47 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:
0M"Metrics exist for measuring enterprise architecture benefits" (about a
38 percent increase),
0M"Chief architect exists" (about a 23 percent increase), and
0M"Enterprise architecture products are under configuration management"
(about an 18 percent increase).
The following are examples of core elements where agency satisfaction
significantly declined:
0M"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.
0M"Enterprise architecture products describe enterprise's business- and
the data, applications, and technology that support it" (about a 36
percent decrease),
0M"Either enterprise architecture steering committee, investment review
board, or agency head has approved enterprise architecture" (about a 25
percent decrease), and
0M"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 Core elements whose fulfillment most
frequently contributed to
Number of agencies maturity stage increase fulfilling element
12 agencies increased Stage 2 elements:
maturity from stage 1 (6 Chief architect exists 6 of 12
to stage 2, 6 to stage 3) Program office responsible for enterprise
architecture development 6 of 12 exists
Committee or group representing the enterprise is responsible for 6 of 12
directing, overseeing, or approving enterprise architecture
Enterprise architecture being developed using framework and 4 of 12
automated tool
8 agencies increased Stage 3 elements:
maturity from stage 2 (6 Enterprise architecture products are under
configuration
to stage 3, 1 to stage 4, 1 management
to stage 5) Written and approved policy exists for enterprise architecture
7 of 8
5 of 8 development
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
unsatisfied element for the 24 agencies that had decreased maturity
levels.
Table 5: Core Elements That Most Frequently Contributed to Maturity Stage
Decreases
Number of agencies Agencies decreasing Core elements whose fulfillment
most frequently contributed to not fulfilling maturity stage decrease
element
16 agencies decreased Stage 2 elements:
maturity to stage 1 (12 Program office responsible for enterprise
architecture development 13 of 16
from stage 2, 4 from exists
stage 3) Chief architect exists 4 of 16
7 agencies decreased Stage 3 elements:
maturity to stage 2 (6 Written and approved policy exists for enterprise
architecture
from stage 3, 1 from development
stage 4) Enterprise architecture products are under configuration
6 of 7
3 of 7 management
1 agency decreased Stage 4 elements:
maturity to stage 3 (from Enterprise architecture products describe
`as-is' environment, 'to-1 of 1 stage 4) be' environment, and sequencing
plan
Enterprise architecture products describe enterprise's business- 1 of 1
and the data, applications, and technology that support it
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
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:
0M "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);
0M "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
0M "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
0M "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 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.
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.
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
Percentage of
agencies
Percentage of Percentage of neither satisfied
agencies agencies nor
Management challenge asatisfied adissatisfied adissatisfied
Fostering top
management
understanding 58 14
Overcoming 53 10 37
parochialism
Ensuring adequate 40 26 34
funding
Obtaining skilled 40 15 45
staff
Source: GAO analysis of survey data.
a Numbers do not add to 100 percent due to rounding.
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).
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 [email protected]. Other key contributors to this testimony
included Shannin Addison, Mark Bird, Barbara Collier, Nancy Glover, Anh
Le, Nnaemeka Okonkwo, Randolph Tekeley, and William Wadsworth.
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.
GAO's Mission
Obtaining Copies of GAO Reports and Testimony
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.
Order by Mail or Phone 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
To Report Fraud, Contact: Web site: www.gao.gov/fraudnet/fraudnet.htm
Waste, and Abuse in E-mail: [email protected]
Federal Programs Automated answering system: (800) 424-5454 or (202)
512-7470
Jeff Nelligan, Managing Director, [email protected] (202) 512-4800
Public Affairs U.S. General Accounting Office, 441 G Street NW, Room 7149
Washington, D.C. 20548
*** End of document. ***