This is the accessible text file for GAO report number GAO-04-43 
entitled 'Information Technology: Architecture Needed to Guide NASA's 
Financial Management Modernization' which was released on December 22, 
2003.

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.

Report to Congressional Committees:

November 2003:

INFORMATION TECHNOLOGY:

Architecture Needed to Guide NASA's Financial Management Modernization:

GAO-04-43:

GAO Highlights:

Highlights of GAO-04-43, a report to congressional committees

Why GAO Did This Study:

The National Aeronautics and Space Administration (NASA) is in the 
process of modernizing its financial management operations and 
supporting information technology systems. This modernization, known 
as the Integrated Financial Management Program (IFMP), is intended to 
provide NASA with an agencywide, integrated approach to performing 
critical business functions, such as contract management—an area that 
GAO first designated as high risk in 1990 and continues to do so 
today. GAO was requested to review various aspects of IFMP, and this 
report is one in a series on the program. The objective of this review 
was to determine whether NASA has been acquiring and implementing 
IFMP in the context of an enterprise architecture. 

What GAO Found:

To date, NASA has acquired and implemented significant components of 
IFMP without an enterprise architecture to guide and constrain the 
program. An enterprise architecture is an organizational blueprint 
that defines—in both business and technology terms—how an 
organization operates today and how it intends to operate in the 
future; it also provides a plan for transitioning to this future 
state. Using an enterprise architecture to guide and constrain systems 
modernization programs is a federal requirement and a recognized best 
practice of successful public and private organizations. In addition, 
GAO’s research has shown that attempting major modernization programs 
such as IFMP without a well-defined enterprise architecture risks, 
among other things, building systems that are duplicative, are not 
interoperable, and do not effectively and efficiently support mission 
operations and performance.

During the course of GAO’s work, NASA recognized the need for an 
enterprise architecture and has taken steps to develop one. For 
example, it has established an architecture program office, 
designated a chief architect, and selected an architecture framework 
to use. In addition, after GAO completed its audit work, NASA 
released an initial version of an enterprise architecture, which the 
chief technology officer stated was not yet complete and would be 
improved upon in future versions. However, the agency has yet to 
establish other key architecture management capabilities, such as 
designating an accountable corporate entity to lead the architecture 
effort, having an approved policy for developing and maintaining the 
architecture, and implementing an independent verification and 
validation function to provide needed assurance that architecture 
products and architecture management processes are effective. 
Moreover, the architecture products used to date to manage NASA’s 
investment in IFMP did not provide sufficient context (depth and 
scope of agencywide operational and technical requirements) to 
effectively guide and constrain the program. 

The chief technology officer agreed that NASA needs an effective 
enterprise architecture program and stated that efforts are under way 
to establish one. GAO’s experience in reviewing other agencies has 
shown that not having an effective enterprise architecture program 
can be attributed to, among other things, an absence of senior 
management understanding and support, as well as cultural 
resistance. 

NASA’s current approach to acquiring and implementing IFMP outside 
the context of an architecture unnecessarily increases the risk that 
the program’s system components will not effectively and efficiently 
support agencywide operations. The result will be costly system 
rework. It is critical for NASA to discontinue this approach and adopt 
the best practice of managing its IFMP system investments within the 
context of a well-defined enterprise architecture.

What GAO Recommends:

GAO is making recommendations to the NASA Administrator for 
establishing an effective enterprise architecture management 
capability, ensuring the completeness of future releases of NASA’s 
enterprise architecture, and minimizing its exposure to risk on IFMP 
caused by system component acquisition and implementation efforts 
that have proceeded to date in the absence of an enterprise 
architecture. NASA concurred with GAO’s recommendations and described 
completed, ongoing, and planned actions to address them. 

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

To view the full product, including the scope and methodology, click 
on the link above. For more information, contact Randolph C. Hite at 
(202) 512-3439 or hiter@gao.gov.

[End of section]

Contents:

Letter: 

Results in Brief: 

Background: 

IFMP Has Proceeded without an Enterprise Architecture, and NASA's 
Ongoing Architecture Management Efforts Are Missing Key Elements: 

Conclusions: 

Recommendations for Executive Action: 

Agency Comments and Our Evaluation: 

Appendixes:

Appendix I: Objective, Scope and Methodology: 

Appendix II: Detailed Results of GAO's Analyses of Architecture 
Products Used to Date by NASA to Acquire and Implement IFMP: 

Appendix III: Assessment of NASA's EA Management Efforts against GAO's 
Architecture Management Maturity Framework: 

Appendix IV: Comments from the National Aeronautics and Space 
Administration: 

Appendix V: GAO Contacts and Staff Acknowledgments: 

GAO Contact: 

Acknowledgments: 

Tables: 

Table 1: Overview of NASA's Organizational Components: 

Table 2: Overview of NASA's Strategic Enterprises and the Contributing 
Centers: 

Table 3: Description and Status of NASA's IFMP System Modules: 

Table 4: Summary of IFMP Management Structure: 

Table 5: Summary of the Maturity Stages and Core Elements of GAO's 
Enterprise Architecture (EA) Management Framework: 

Figure: 

Figure 1: Summary of Extent to Which NASA's Architecture Products 
Satisfy Key Elements Governing Architectural Content: 

Abbreviations: 

ARC: Ames Research Center:

CIO: chief information officer:

CTO: chief technology officer:

CRUD: create, read, update, and/or delete:

DFRC: Dryden Flight Research Center:

EAI: enterprise application integration:

EA: enterprise architecture:

FEAF: Federal Enterprise Architecture Framework:

GRC: Glenn Research Center:

GSFC: Goddard Space Flight Center:

IFMP: Integrated Financial Management Program:

IT: information technology:

JPL: Jet Propulsion Laboratory:

JSC: Johnson Space Center:

KSC: Kennedy Space Center:

LaRC: Langley Research Center:

MSFC: Marshall Space Flight Center:

NISSU: NASA's Information System Services Utility:

NASA: National Aeronautics and Space Administration:

OIG: Office of the Inspector General:

OMB: Office of Management and Budget:

SSC: Stennis Space Center:

TRM: technical reference model:

Letter November 21, 2003:

The Honorable John McCain: 
Chairman: 
The Honorable Ernest F. Hollings: 
Ranking Minority Member: 
Committee on Commerce, Science and Transportation: 
United States Senate:

The Honorable Sherwood L. Boehlert: 
Chairman: 
The Honorable Ralph M. Hall: 
Ranking Minority Member: 
Committee on Science: 
House of Representatives:

To improve its ability to manage its contractors, which is an area that 
we designated as high risk in 1990, and continue to do so 
today,[Footnote 1]the National Aeronautics and Space Administration 
(NASA) began its third attempt at modernizing its financial management 
systems in April 2000. This modernization effort, known as the 
Integrated Financial Management Program (IFMP), is expected to produce 
an integrated, NASA-wide business systems environment by acquiring and 
incrementally implementing commercial hardware and software 
components. Our research of successful public-and private-sector 
organizations shows that attempting a modernization program, like IFMP, 
without having and using a well-defined modernization blueprint, 
commonly called an enterprise architecture,[Footnote 2] results in 
operations and systems that are duplicative, are not well integrated, 
are unnecessarily costly to maintain and interface, and do not 
effectively optimize mission performance.

In April 2003, we issued the first in a series of reports on the 
program, in which we concluded that NASA's approach to acquiring and 
implementing IFMP components had and would continue to introduce risk 
and increase the chances that the agency would fall short of meeting 
its program goal.[Footnote 3] Because of the importance of IFMP to 
overall mission performance, you asked us to continue our review. 
Specifically, you requested that we determine whether (1) NASA has been 
acquiring and implementing IFMP in the context of an enterprise 
architecture, (2) the core financial module as implemented in June 2003 
would satisfy NASA's key external reporting requirements, and (3) 
NASA's life-cycle cost estimate, program schedule, and funding reserves 
for IFMP were reasonable.

We are responding to the second two issues in separate 
reports,[Footnote 4] as well as summarizing our findings on all three 
areas in an additional report.[Footnote 5] This report addresses the 
first issue--whether NASA had and was using an enterprise architecture 
to acquire and implement IFMP. To accomplish this, we compared the 
architecture documents that NASA provided us, and represented as being 
used to manage IFMP, against published guidance governing the content 
of a well-defined architecture.[Footnote 6] We also compared NASA's 
architecture development, maintenance, and implementation practices 
against our enterprise architecture management maturity 
framework.[Footnote 7] Details on our objective, scope, and methodology 
are in appendix I.

Results in Brief:

To date, NASA has acquired and implemented significant components of 
IFMP without an enterprise architecture, or modernization blueprint, to 
guide and constrain the program.[Footnote 8] During the course of our 
review of this program, the agency recognized the need for an 
enterprise architecture and began efforts to develop one. For example, 
NASA established some important architecture management structures and 
process controls advocated by best practices and federal guidance, such 
as having an enterprise architecture program office; designating a 
chief architect; and using an architecture development methodology, 
framework, and automated tool. In addition, after we completed our 
audit work, the agency released an initial version of an enterprise 
architecture, which the chief technology officer stated was not yet 
complete and would be improved upon in future versions. However, NASA 
has yet to establish other key architecture management capabilities 
that are essential to having a mature, effective enterprise 
architecture program. Moreover, the architecture products that the 
agency has used to date in managing its $983 million IFMP 
investment[Footnote 9] did not provide sufficient context (depth and 
scope of agencywide operational and technical requirements) to 
effectively guide and constrain the program. NASA's chief technology 
officer agreed that NASA needs an effective enterprise architecture 
program and stated that efforts are under way to establish one.

Our experience in reviewing other agencies has shown that not having an 
effective enterprise architecture program can be attributed to, among 
other things, an absence of senior management understanding and 
support, and cultural resistance to having and using one. Our 
experience also shows that attempting major modernization programs such 
as IFMP without having and using an enterprise architecture often 
results in system implementations that are duplicative, are not well 
integrated, and require costly rework to interface. In the case of 
IFMP, this is occurring. Specifically, NASA's Office of the Inspector 
General (OIG) recently reported[Footnote 10] that the agency would need 
to resolve several accounting and costing issues before the IFMP core 
system component provides full cost accounting capabilities. This means 
that the agency will now have to reconfigure the software for this 
component to reflect the issues' resolution. According to the chief 
technology officer, determining the need for additional rework of 
already implemented IFMP system components will be based on a future 
assessment of these components' alignment to an initial version of the 
agency's enterprise architecture that NASA first provided to us on 
September 24, 2003, which was after we had completed our audit work.

To assist NASA in its efforts to effectively and efficiently acquire 
and implement IFMP, as well as its recently launched efforts to develop 
and use a well-defined enterprise architecture, we are making 
recommendations to the Administrator related to establishing an 
effective enterprise architecture management capability, ensuring the 
completeness of planned future releases of its enterprise architecture, 
and minimizing its exposure to risk on IFMP caused by system component 
acquisition and implementation efforts that have proceeded to date 
without an enterprise architecture. NASA concurred with our 
recommendations, and described actions recently completed, ongoing, or 
planned to implement them.

Background:

NASA's mission encompasses human exploration and development of space, 
the advancement and communication of scientific knowledge, and research 
and development of aeronautics and space technologies. Its activities 
span a broad range of complex and technical endeavors--from 
investigating the composition, evaluation, and resources of Mars; to 
working with the agency's international partners to complete and 
operate the International Space Station; to providing satellite and 
aircraft observations of Earth for scientific and weather forecasting 
purposes; to developing new technologies designed to improve air 
safety. NASA's workforce comprises over 19,000 civil service employees, 
primarily located at its headquarters and 10 major field centers, and 
more than 40,000 contractors and grantees, who collectively perform a 
wide range of roles and responsibilities. Table 1 describes the roles 
and responsibilities of NASA's headquarters and field centers.

Table 1: Overview of NASA's Organizational Components:

NASA headquarters and field centers: NASA Headquarters; Location: 
Washington, D.C.; Roles/responsibilities: NASA headquarters manages 
the space flight centers, research centers, and other installations. It 
is responsible for determining programs and projects; establishing 
management policies, procedures, and performance criteria; evaluating 
progress; and reviewing and analyzing all phases of the aerospace 
program.

NASA headquarters and field centers: Ames Research Center (ARC); 
Location: Moffett Field, Calif; Roles/responsibilities: ARC is a 
principal center for computational fluid dynamics, rotorcraft and 
powered-lift technology, artificial intelligence, and airborne 
sciences.

NASA headquarters and field centers: Dryden Flight Research Center 
(DFRC); Location: Edwards Air Force Base, Calif; Roles/
responsibilities: DFRC is the premier installation for aeronautical 
flight research.

NASA headquarters and field centers: Glenn Research Center (GRC); 
Location: Cleveland, Ohio; Roles/responsibilities: GRC, the lead center 
for aeropropulsion, is responsible for developing, verifying, and 
transferring aeropropulsion technologies to U.S. industry.

NASA headquarters and field centers: Goddard Space Flight Center 
(GSFC); Location: Greenbelt, Md; Roles/responsibilities: GSFC is a 
major U.S. laboratory for developing and operating unmanned scientific 
spacecraft.

NASA headquarters and field centers: Jet Propulsion Laboratory (JPL); 
Location: Pasadena, Calif; Roles/responsibilities: JPL is the lead 
U.S. center for robotic exploration of the solar system, with a primary 
focus on planetary exploration (e.g., missions to Mars) and 
environmental research (e.g., Shuttle Imaging Radar). The California 
Institute of Technology manages JPL for NASA.

NASA headquarters and field centers: Johnson Space Center (JSC); 
Location: Houston, Tex; Roles/responsibilities: JSC is the primary 
center for designing, developing, and testing spacecraft and associated 
systems for human flight, selecting and training astronauts, and 
planning and conducting human space flight missions.

NASA headquarters and field centers: Kennedy Space Center (KSC); 
Location: Cape Canaveral, Fla.; Roles/responsibilities: KSC is 
primarily responsible for ground turnaround and support operations, 
prelaunch checkout, and launching of the space shuttle and its 
payloads, including NASA's International Space Station. KSC is the 
nation's spaceport--the liftoff site for all manned missions into 
space.

NASA headquarters and field centers: Langley Research Center (LaRC); 
Location: Hampton, Va; Roles/responsibilities: LaRC is primarily 
responsible for basic research in aeronautics and space technology. It 
is the lead center for managing NASA's technology development programs 
for future high-speed civil transport, hypersonic vehicle concepts, and 
general aviation.

NASA headquarters and field centers: Marshall Space Flight Center 
(MSFC); Location: Huntsville, Ala; Roles/responsibilities: MSFC is the 
premier organization for developing space transportation and propulsion 
systems and for conducting microgravity research.

NASA headquarters and field centers: Stennis Space Center (SSC); 
Location: Hancock County, Miss; Roles/responsibilities: SSC is the 
primary center for testing large rocket propulsion systems for the 
space shuttle and future generation space vehicles.

Source: NASA.

[End of table]

Transcending NASA's organizational components are six strategic mission 
enterprises or business areas, each with a unique set of strategic 
goals, objectives, and implementation strategies focused on the 
requirements of the agency's customers. Each enterprise draws on the 
capabilities of several centers so that each center contributes to 
multiple enterprises. Table 2 summarizes NASA's strategic enterprises 
and the contributing centers.

Table 2: Overview of NASA's Strategic Enterprises and the Contributing 
Centers:

Strategic enterprise: Aerospace technology; Primary goal: Pioneer and 
develop advanced technologies that, in turn, improve the air 
transportation system, access to space, and science missions. Includes 
helping others use NASA technology for nonaerospace commercial purposes 
and developing technology partnerships with those in industry and 
academia that are outside of traditional aerospace fields; 
Contributing NASA centers: ARC, DFRC, GRC, and LaRC.

Strategic enterprise: Biological and physical research; Primary goal: 
Offer a unique laboratory in which to study biological and physical 
processes. Experiments that take advantage of this environment extend 
from basic biology to quantum mechanics and from fundamental research 
to research with near-term applications in medicine and industry; 
Contributing NASA centers: ARC, GRC, JPL, JSC, KSC, and MSFC.

Strategic enterprise: Earth science; Primary goal: Seek to understand 
and protect our planet by advancing Earth-system science with a near-
term emphasis on global climate change through the use of Earth remote-
sensing spacecraft, airborne observations, space shuttle missions, and 
ground-based measurements; Contributing NASA centers: ARC, DFRC, GSFC, 
JPL, LaRC, MSFC, and SSC.

Strategic enterprise: Education; Primary goal: Inspire students to 
pursue the study of science and engineering, with the ultimate goal of 
having them choose careers in aeronautics and space at NASA; 
Contributing NASA centers: ARC, DFRC, GRC, GSFC, JPL, JSC, KSC, LaRC, 
MSFC, and SSC.

Strategic enterprise: Space flight; Primary goal: Provide critical 
enabling capabilities that make possible the science, research, and 
exploration achievements of the rest of the agency; Contributing NASA 
centers: ARC, GRC, JPL, JSC, KSC, and MSFC.

Strategic enterprise: Space science; Primary goal: Seek to answer 
fundamental questions about life in the universe: how it arose, what 
its mechanisms are, where in the solar system life may have originated 
or may exist today, and whether there are similar planetary 
environments around other stars where the signature of life can be 
found; Contributing NASA centers: ARC, GSFC, JPL, KSC, and MSFC.

Source: NASA.

[End of table]

To execute its mission responsibilities, NASA performs numerous 
management functions, such as contract management, financial 
management, and human capital management, relying heavily on 
information technology (IT) to assist it in performing these functions. 
For fiscal year 2003, the agency estimated that it would spend 
approximately $2.3 billion on IT systems and services. Of this amount, 
NASA anticipated spending $32.5 million on IT security and $11 million 
on enterprise architecture.

NASA Continues to Face Challenges in Managing Large Programs:

In January 2003, we reported[Footnote 11]that NASA faced challenges 
that threaten its ability to effectively run its largest programs. We 
also reported that because these challenges are rooted in NASA's 
culture and long-standing ways of doing business, the agency needed to 
make a major transformation. In particular, we identified the following 
four performance and accountability challenges facing the agency:

* Strengthening strategic human capital management. NASA is facing 
shortages in its workforce, which could likely worsen as the workforce 
continues to age and the pipeline of talent shrinks. This dilemma is 
more pronounced among areas crucial to NASA's ability to perform its 
mission, such as engineering, science, and IT. NASA is addressing this 
challenge through strategic planning, through a new workforce planning 
and analysis system, and by requesting additional personnel 
flexibilities, among other initiatives.

* Controlling International Space Station costs. Development costs for 
this project have soared to the point where NASA has had to cut back 
the program substantially, including reducing construction, the number 
of crew members, and scientific research. These cutbacks have raised 
concern among NASA's international partners, who have a large stake in 
the scientific research to be performed on the station. Although NASA 
is instituting management and cost-estimating reforms, it still needs 
to reach agreement with its partners on its planned cutbacks.

* Reducing costs of space launches. The administration submitted an 
amendment to NASA's fiscal year 2003 budget request, which (1) extends 
the life of the space shuttle and enhances its reliability, (2) funds 
the development of a new vehicle for ferrying crew to and from the 
space station, and (3) alters the time frame for a shuttle replacement. 
Accomplishing these and other goals related to space launches will be 
difficult and risky in light of the technology advances that NASA would 
like to pursue and the high degree of communication and coordination 
required among industry and government partners.

* Improving contract management. NASA spends most of its funds on 
acquisitions.[Footnote 12] Yet, for many years, the agency has been 
unable to oversee contracts effectively, principally because it lacked 
accurate and reliable information on contract spending and placed 
little emphasis on end results, product performance, and cost control. 
NASA has addressed many acquisition-related weaknesses and is beginning 
to tackle one of its most formidable barriers to sound contract 
management--the lack of a modern, integrated financial management 
system. Considerable work remains to be done since NASA is only in the 
early stages of designing and implementing this new system, and NASA 
reported that it is already facing challenges in terms of cost, 
interoperability, and security.

We also reported that NASA's ability to collect, maintain, and report 
the full cost of its projects and programs is weakened by diverse and 
often incompatible and nonintegrated center-level accounting systems; 
uneven and nonstandard cost-reporting capabilities; decentralized 
policies, procedures, and practices that are unique to its field 
centers; nonstandard data formats; and online financial information 
that is not readily available to program managers. Thus, it is 
difficult to ensure that contracts are being efficiently and 
effectively implemented and that budgets are executed as planned. This 
lack of integration and standardization also impedes the agency's 
ability to provide data required for external reporting purposes.

Recognizing the need for change, NASA's Administrator articulated a new 
vision for the agency--one that is science-driven, not destination-
driven. To better enable NASA to fulfill this vision, the agency is 
taking on a major transformation aimed at eliminating stovepipes, 
becoming more integrated and results-oriented, and reducing risks while 
working more economically, efficiently, and effectively.

NASA Has Initiated a Large, Complex Systems Modernization to Address 
Financial Management Concerns:

A key transformation effort is IFMP, which is NASA's third attempt in 
more than 12 years to modernize its financial management processes and 
systems. NASA spent about $180 million on its two prior failed efforts, 
and NASA's data indicate that the agency will spend approximately $983 
million through 2010 for its current effort, IFMP, which it began in 
April 2000.[Footnote 13] IFMP is expected to produce an integrated, 
NASA-wide financial management system by acquiring and incrementally 
implementing commercial software packages and related hardware and 
software components. The main objective of IFMP is to improve the 
financial, physical, and human capital management processes throughout 
the agency. According to NASA, once fully implemented, IFMP will 
reengineer NASA's business operations around industry "best practices" 
and use enabling technology to provide necessary management information 
to support implementation of the agency's strategic plan. To meet this 
objective and support these crosscutting activities, NASA has 
identified the following business drivers for the program:

* providing timely, consistent, and reliable information for management 
decisions;

* improving NASA's accountability and enabling full cost management;

* achieving increased efficiencies and operating effectively;

* exchanging information with customers and stakeholders in a timely 
and reliable way; and:

* attracting and retaining a world-class workforce.

The IFMP system is to consist of nine modules supporting a range of 
functionality (see table 3).

Table 3: Description and Status of NASA's IFMP System Modules:

Module: Core financial; Description: Support full cost management by 
providing agencywide standards for accounting and budget execution 
processes and financial reporting. Includes eight financial 
subprocesses: budget execution, purchasing, cost management, accounts 
payable, accounts receivable, fixed assets, standard general ledger, 
and federal reporting; Reported status: Operational as of June 2003.

Module: Travel management; Description: Streamline and unify the 
agency's employee travel system and improve traveler and vendor 
reimbursement. (According to NASA, this product has been integrated 
into the core financial module.); Reported status: Operational as of 
June 2003.

Module: Executive financial management information system (Erasmus); 
Description: Provide budget, cost, and performance information for all 
major NASA programs and projects in a standardized format; Reported 
status: Operational as of July 2002.

Module: Resume management; Description: Enable applicants to search for 
matching NASA job listings and generate resumes online and allow NASA's 
human resources community to generate job listings while increasing 
efficiency and effectiveness; Reported status: Operational as of 
December 2001.

Module: Position description management; Description: Enable position 
descriptions to be rapidly generated and classified and associated 
documents to be automatically generated; Reported status: Operational 
as of early 2002.

Module: Budget formulation; Description: Enable the formulation of 
project, program, institutional, enterprise, and agency-level budget 
requirements. It will promote full cost management and real-time 
decision making; Reported status: Currently being implemented; to be 
operational at all locations in February 2004.

Module: Integrated asset management; Description: Enable financial 
reporting, physical inventory, maintenance, and liability reporting for 
the functional areas of aircraft, environmental, facilities, and 
logistics management; Reported status: Not yet initiated; no 
milestones set.

Module: Procurement; Description: Support the procurement, receiving, 
invoicing, and payment of materials. Will provide detailed and 
quantitative data to facilitate, economize, and expedite procurement 
processes; Reported status: Not yet initiated; no milestones set.

Module: Human resources; Description: Provide a human resources 
infrastructure that meets recordkeeping and process requirements while 
helping NASA managers fill positions with staff that possess the 
appropriate skill sets and career goals; Reported status: Not yet 
initiated; no milestones set.

Source: NASA.

[End of table]

As structured, NASA is the IFMP system integrator and thus is 
responsible for acquiring and integrating the multiple commercial 
components and ensuring that they collectively perform in a manner that 
meets the defined requirements. Table 4 describes the key IFMP program 
management positions/entities and their respective responsibilities.

Table 4: Summary of IFMP Management Structure:

Management position/entity: Program Executive; Responsibilities: 
Manages, on a corporate level, program rollout, budget, performance, 
and schedule requirements; has decision authority over all program 
content, implementation schedules, and budget allocations; and provides 
leadership and accountability for top-level program requirements, 
implementation success criteria, overall performance definition, and 
strategic planning in the direction and operation of the Integrated 
Financial Management Program (IFMP).

Management position/entity: Program Director; Responsibilities: 
Implements IFMP according to specific guidelines (e.g., the program 
plan); reports to the Program Executive, and is under the oversight of 
the agency's Chief Financial Officer and the IFMP Steering Council.

Management position/entity: Chief Financial Officer; Responsibilities: 
Ensures that the program meets externally mandated requirements while 
satisfying internal customer needs in a cost-effective manner.

Management position/entity: Steering Council; Responsibilities: Acts 
as a forum for reviewing and approving the agencywide crosscutting 
facets of the program, including, for example, program strategy and 
budgets and expanding the scope of projects; resolves functional 
conflicts and ensures functional integration.

Management position/entity: Project Manager; (each NASA center has a 
Project Manager); Responsibilities: Plans and manages the 
implementation of each functional module approved by the program 
office; coordinates process team activities and supports the selection 
of software products, including updating requirements on the basis of 
the selected software's capabilities and the developed gap assessments, 
which identify differences between NASA's requirements and the 
software's capabilities.

Management position/entity: Integration Project Manager; 
Responsibilities: Establishes a viable technical infrastructure and 
ensures that the various functional module requirements are 
coordinated, ensures that each IFMP module is appropriately integrated/
interfaced, minimizes redundant data, ensures that data definitions are 
consistent across modules, establishes life-cycle requirements, and 
performs configuration management.

Source: NASA.

[End of table]

Early Problems with IFMP Have Been Reported:

In April 2003, we reported[Footnote 14] that NASA was not following key 
best practices for acquiring and implementing IFMP. For example, the 
agency had not established an analytical capability to understand and 
proactively manage the dependencies among IFMP commercial components. 
Further, in implementing the core financial module component, NASA had 
deferred addressing the needs of key systems users and had not properly 
developed detailed system requirements. We concluded that the agency 
was at risk of making a substantial investment in a system that would 
fall far short of its stated goal of providing meaningful and reliable 
information to support effective program management and congressional 
oversight.

To address its problems, we recommended that NASA (1) develop and 
implement a short-term plan to identify and mitigate the risks 
currently associated with relying on already deployed IFMP commercial 
components and to expeditiously stabilize these components' operational 
capability and performance; (2) as part of the short-term plan, develop 
and properly document requirements, reengineer acquisition management 
processes, and fully engage stakeholders--including program managers, 
cost estimators, and the Congress--in the development of user 
requirements; and (3) develop a longer-term strategy for acquiring 
additional IFMP components that includes implementing a methodology for 
analyzing commercial system component dependencies. NASA concurred with 
the need for a short-term plan but disagreed with most of our findings 
and recommendations related to user needs and requirements and testing. 
NASA also agreed with the importance of having an approach for 
acquiring additional IFMP components, but stated that it already has an 
effective strategy in place.

In May 2003, NASA's OIG reported[Footnote 15] that the core financial 
module software, which had been deployed at six NASA centers, had the 
capability to implement full cost accounting. However, before this 
implementation could take place, NASA needed to resolve several complex 
accounting and costing issues. These issues involved how to allocate 
service and general and administrative costs, civil service costs, and 
unassigned costs. Once these accounting and costing issues were 
resolved, the OIG reported that NASA would have to configure the IFMP 
software to reflect the changes. The OIG recommended that NASA revise 
the IFMP plans to include (1) time frames and milestones for completing 
steps to implement full cost accounting, including addressing and 
resolving the cost issues identified above; (2) identification of the 
personnel and other resources necessary to perform the steps within the 
established time frames; and (3) senior management approval and support 
of these additional procedures. IFMP officials concurred with the 
recommendations and plan to have all phases of full cost accounting 
implemented by October 1, 2003. (NASA reported that full implementation 
of the core financial module at all centers was completed in June 
2003.):

An Enterprise Architecture Is Critical to an Organization's Ability to 
Effectively Modernize Its Business Operations and Systems:

Effective use of enterprise architectures, or modernization blueprints, 
is a trademark of successful public and private organizations. For a 
decade, we have promoted the use of architectures to guide and 
constrain systems modernization, recognizing them as a crucial means to 
a challenging goal: agency operational structures that are optimally 
defined in both business and technological environments. The Congress, 
the Office of Management and Budget (OMB), and the federal Chief 
Information Officer (CIO) Council have also recognized the importance 
of an architecture-centric approach to modernization. The Clinger-Cohen 
Act of 1996 mandates that an agency's CIO develop, maintain, and 
facilitate the implementation of architectures as a means for managing 
the integration of business processes and supporting systems. Further, 
OMB has issued guidance that, among other things, requires system 
investments to be consistent with these architectures.

An enterprise architecture provides a clear and comprehensive picture 
of an entity, whether it is an organization (e.g., federal department 
or agency) or a functional or mission area that cuts across more than 
one organization (e.g., financial management). This picture consists of 
snapshots of both the enterprise's current or "As Is" operational and 
technological environment and its target or "To Be" environment, as 
well as a capital investment road map for transitioning from the 
current to the target environment. These snapshots further consist of 
"views," which are basically one or more architecture products that 
provide conceptual or logical representations of the enterprise.

The suite of products and their content that form a given entity's 
enterprise architecture are largely governed by the framework used to 
develop the architecture. Since the 1980's, various frameworks have 
emerged and been applied. For example, John Zachman developed a 
structure or "framework" for defining and capturing an 
architecture.[Footnote 16] This framework provides for six windows from 
which to view the enterprise, which Zachman terms "perspectives" on how 
a given entity operates: those of (1) the strategic planner, (2) the 
system user, (3) the system designer, (4) the system developer, (5) the 
subcontractor, and (6) the system itself. Zachman also proposed six 
abstractions or models associated with each of these perspectives: 
these models cover (1) how the entity operates, (2) what the entity 
uses to operate, (3) where the entity operates, (4) who operates the 
entity, (5) when entity operations occur, and (6) why the entity 
operates.

In September 1999, the federal CIO Council published the Federal 
Enterprise Architecture Framework (FEAF), which is intended to provide 
federal agencies with a common construct for their respective 
architectures, thereby facilitating the coordination of common business 
processes, technology insertion, information flows, and system 
investments among federal agencies. FEAF describes an approach, 
including models and definitions, for developing and documenting 
architecture descriptions for multiorganizational functional segments 
of the federal government. Similar to most frameworks, FEAF'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.

More recently, OMB established the Federal Enterprise Architecture 
Program Management Office to develop a federated enterprise 
architecture according to a collection of five "reference models:":

* The Business Reference Model is intended to describe the business 
operations of the federal government independent of the agencies that 
perform them, including defining the services provided to state and 
local governments.

* The Performance Reference Model is to provide a common set of general 
performance outputs and measures for agencies to use to achieve 
business goals and objectives.

* The Data and Information Reference Model is to describe, at an 
aggregate level, the types of data and information that support program 
and business line operations, and the relationships among these types.

* The Service Component Reference Model is to identify and classify IT 
service (i.e., application) components that support federal agencies 
and promote the reuse of components across agencies.

* The Technical Reference Model is to describe how technology is 
supporting the delivery of service components, including relevant 
standards for implementing the technology.

These various enterprise architecture frameworks differ in their 
nomenclatures and modeling approach. However, the frameworks 
consistently provide for defining an enterprise's operations in both 
(1) logical terms, such as interrelated business processes and business 
rules, information needs and flows, and work locations and users, and 
(2) technical terms, such as hardware, software, data, communications, 
and security attributes and performance standards. The frameworks also 
provide for defining these perspectives for both the enterprise's 
current or "As Is" environment and its target or "To Be" environment, 
as well as a transition plan for moving from the "As Is" to the "To Be" 
environment.

The importance of developing, implementing, and maintaining an 
enterprise architecture is a basic tenet of both organizational 
transformation and IT management. 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 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 to 
optimize mission performance. Our experience with federal agencies has 
shown that investing in IT without defining these investments in the 
context of an architecture often results in systems that are 
duplicative, not well integrated, and unnecessarily costly to maintain 
and interface.[Footnote 17]

IFMP Has Proceeded without an Enterprise Architecture, and NASA's 
Ongoing Architecture Management Efforts Are Missing Key Elements:

NASA has thus far acquired and deployed IFMP without a sufficiently 
complete enterprise architecture to guide and constrain program 
investment decisions. During the course of our review of IFMP, NASA 
took steps to correct this situation by establishing key architecture 
management capabilities and undertaking the development of an initial 
version of an enterprise architecture that, according to the chief 
technology officer, will provide some missing contextual information 
(operational and technical). However, NASA has not established other 
key architecture management capabilities, such as designating an 
accountable corporate entity to lead the architecture effort, having an 
approved policy for developing and maintaining the architecture, and 
implementing an independent verification and validation function to 
provide needed assurance that architecture products and architecture 
management processes are effective. The chief technology officer agreed 
that NASA needs an effective enterprise architecture program and stated 
that efforts are under way to establish one. Based on our experience in 
reviewing other agencies, not having an effective enterprise 
architecture program is attributable to, among other things, limited 
senior management understanding and commitment and cultural resistance 
to having and using an architecture. The result is an inability to 
implement modernized systems in a way that minimizes overlap and 
duplication and maximizes integration and mission support.

The Architecture Products that NASA Has Used for IFMP Are Limited:

As previously discussed, the various frameworks used to develop 
architecture products consistently provide for describing a given 
enterprise in both logical (e.g., business, performance, application, 
information) and technical (e.g., hardware, software, data) terms, and 
for doing so for the enterprise's current or "As Is" environment and 
its target or "To Be" environment; these frameworks also provide for 
defining a capital investment sequencing plan to transition from the 
"As Is" to the "To Be" environment. However, the frameworks do not 
prescribe the degree to which the component parts should be described 
to be considered correct, complete, understandable, and usable--
essential attributes of any architecture. This is because the depth and 
detail of the descriptive content depends on what the architecture is 
to be used for (i.e., its intended purpose).

NASA's stated intention is to use an architecture as the basis for 
agencywide business transformation and systems modernization, 
including IFMP. This purpose necessitates that NASA's architecture 
products provide considerable depth and detail, as well as logical and 
rational structuring and internal linkages. More specifically, it means 
that these architecture products should contain sufficient scope and 
detail so that, for example, (1) duplicative business operations and 
systems are eliminated; (2) business operations are standardized and 
integrated, and supporting systems are interoperable; (3) use of 
enterprisewide services is maximized; and (4) related shared solutions 
are aligned, like OMB's e-government initiatives.[Footnote 18] 
Moreover, this scope and detail should be accomplished in a way that 
(1) provides flexibility in adapting to changes in the enterprise's 
internal and external environments; (2) facilitates its usefulness and 
comprehension by varying perspectives, users, or stakeholders; and (3) 
provides for properly sequencing investments to recognize, for example, 
the investments' respective dependencies and relative business value.

The architecture artifacts that NASA's chief technology officer 
provided to us and represented as those used to date in acquiring and 
implementing IFMP do not contain sufficient context (depth and scope of 
agencywide operational and technical requirements) to effectively guide 
and constrain agencywide business transformation and systems 
modernization efforts. More specifically, these artifacts do not 
satisfy the most basic characteristics of architecture content, such as 
clearly distinguishing between artifacts that represent the "As Is" and 
the "To Be" environments. The agency's chief technology officer agreed 
that these existing architecture products do not clearly distinguish 
between the two environments. Therefore, for purposes of our analyses, 
the chief technology officer told us to treat the architecture products 
as descriptive of the "To Be" environment, and to assume that any "As 
Is" content in these products represented capability intended for reuse 
in the future environment. This characterization is consistent with 
NASA contractual documents associated with developing these 
architecture products. On the basis of this characterization, we did 
not assess these artifacts for their "As Is" content and accepted the 
chief technology officer's acknowledgment that this content was 
missing. Instead, we focused on the "To Be" content and the transition 
plan. To assess the "To Be" architecture products, we divided them into 
five architectural components similar to those in OMB's architecture 
reference models: the business, information/data, services/
applications, technical, and performance components; we added security 
as a sixth component because of its recognized importance and relevance 
to the other five. We then compared architecture products NASA used to 
date for IFMP to relevant criteria[Footnote 19] governing the content 
of key architectural elements for the transition plan and these six 
components of the "To Be" architecture. Based on this comparison, we 
determined whether the architecture products generally satisfied, did 
not satisfy,[Footnote 20] or partially satisfied[Footnote 21] each 
architectural element.

Overall, we found that NASA's "To Be" architecture products did not 
satisfy 18 of 35 (51 percent) key elements and partially satisfied the 
remaining 17 (49 percent), and its transition plan partially satisfied 
1 (25 percent) of 4 elements and did not satisfy the remaining 3 (75 
percent) (see fig. 1).

Figure 1: Summary of Extent to Which NASA's Architecture Products 
Satisfy Key Elements Governing Architectural Content:

[See PDF for image]

[End of figure]

This means that the architecture products that NASA used to date in 
acquiring and implementing IFMP have not provided an adequate context 
in which to wisely invest in the program. In general, these products 
were limited to descriptions of (1) technology characteristics, which 
is one of many enterprise architecture elements, and (2) one of nine 
business operations (finance and accounting). Our specific analysis of 
"To Be" and transition plan products follows.

"To Be" Products: A "To Be" architecture is intended to capture the 
vision of future business operations and supporting technology. It 
should describe the desired capabilities, structures (e.g., entities, 
activities, and roles), and relationships among these structures at a 
specified point(s) in the future. The "To Be" architecture should show, 
for example, future business processes, information needs, and 
supporting infrastructure and be fiscally and technologically 
achievable. According to relevant guidance,[Footnote 22] the "To Be" 
architecture should contain, among other things, a description of (1) 
the future business operations that will be performed to support the 
organization's mission, including the entities or people that will 
perform the functions, processes, and activities, and the locations 
where the functions, processes, and activities will be performed; 
(2) the logical database model that is to be used to guide the creation 
of the physical databases where information will be stored; (3) the 
systems to be developed or acquired to support the business operations; 
(4) the physical infrastructure (e.g., hardware and software) that will 
be needed to support the business systems; (5) the organizations that 
will be accountable for implementing security and the tools to be used 
to secure and protect systems and data; and (6) the metrics that will 
be used to evaluate the effectiveness of mission operations and 
supporting system performance in achieving mission goals and 
objectives. By including these elements, the architecture would provide 
NASA with the necessary frame of reference for engineering business 
processes and systems in a manner that supports agencywide goals and 
objectives, such as ensuring that decision makers routinely receive 
timely, accurate, and reliable information.

The "To Be" architecture products used to date in acquiring and 
implementing IFMP provide minimal descriptive content. On the positive 
side, they contain a description of one future business operation 
(i.e., finance and accounting). However, they do not describe other 
future business operations (e.g., asset management and human 
resources). In addition, they do not describe (1) finance and 
accounting in terms of the entities or people who will perform the 
functions, processes, and activities and the locations where the 
functions, processes, and activities will be performed; (2) the logical 
database model to be used to create the physical databases; (3) the 
actual systems to be developed or acquired to support future business 
operations; (4) the physical infrastructure (e.g., hardware and 
software) that will be needed to support the business systems; (5) the 
organizations that will be accountable for implementing security and 
the tools to be used to secure and protect systems and data; and 
(6) the metrics that will be used to evaluate the effectiveness of 
mission operations and supporting system performance in achieving 
mission goals and objectives. Without this information, the 
organization will not have a common vision and frame of reference for 
defining a transition plan to guide and constrain the transformation of 
business operations and associated capital investments and, thus, will 
be unable to effectively leverage technology to orchestrate logical and 
systematic change and optimize enterprisewide mission performance. 
Detailed results of our analysis are provided in appendix II.

Transition Plan Products: According to relevant guidance and best 
practices,[Footnote 23] the transition plan should provide a temporal 
road map for moving from the "As Is" to the "To Be" environment. An 
important step in developing a well-defined transition plan is a gap 
analysis--comparison of the "As Is" and "To Be" architectures to 
identify differences. Other important steps include analyzing 
technology opportunities and marketplace trends, as well as assessing 
fiscal and budgetary realities and institutional acquisition and 
development capabilities. With the use of such analyses and 
assessments, options are explored and decisions are made regarding 
which legacy systems to retain, modify, or retire and which new systems 
to introduce on a tactical (temporary) basis or to pursue as strategic 
solutions. Accordingly, transition plans identify legacy, migration, 
and new systems and sequence them to show, for example, the phasing out 
and termination of systems and capabilities and the timing of the 
introduction of new systems and capabilities, and they do so in light 
of resource constraints, such as budget, people, acquisition/
development process maturity, and associated time frames.

The transition plan artifacts that NASA relied on in acquiring and 
implementing IFMP generally do not possess these attributes. 
Specifically, they do not (1) provide a gap analysis identifying the 
needed changes to current business processes and systems; (2) identify 
all of the systems that will not become part of the "To Be" 
architecture, as well as the time frames for phasing out these systems; 
(3) show a time-based strategy for replacing legacy systems, including 
identifying intermediate (i.e., migration) systems that may be 
temporarily needed; and (4) define the resources (e.g., funding and 
staff) needed to transition to the target environment. The result is 
that NASA has not had a meaningful and reliable basis for managing the 
disposition of its systems or for sequencing the introduction of 
modernized business operations and supporting systems. Detailed results 
of our analysis appear in appendix II.

The chief technology officer agreed that the architecture products used 
to date to acquire and implement IFMP do not provide sufficient scope 
and content to constitute a well-defined enterprise architecture. Based 
on our experience in reviewing other agencies, not having an effective 
enterprise architecture program is attributable to, among other things, 
limited senior management understanding and commitment and cultural 
resistance to having and using an architecture.

Our experience with federal agencies has shown that attempting to 
define and build major IT systems without first completing an 
enterprise architecture often results in IT systems that are 
duplicative, are not well integrated, are unnecessarily costly to 
maintain and interface, and do not effectively optimize mission 
performance. In fact, NASA's OIG recently reported[Footnote 24] that 
the agency would need to resolve several accounting and costing issues 
before the IFMP core financial module, which is to implement NASA's 
finance and accounting business process, would be able to provide full 
cost-accounting capabilities as envisioned. To accomplish this, the 
agency will have to reconfigure the IFMP software to reflect these 
changes, resulting in system rework and additional associated costs 
that could have been prevented.

Beyond this known rework, additional corrective action could be 
necessary to address any misalignment between already implemented IFMP 
system components and NASA's just-released initial version of an 
enterprise architecture. Specifically, the chief technology officer 
provided us with an initial version of a NASA enterprise architecture 
on September 24, 2003, which was after we completed our audit work. 
According to this official, although this initial version of the 
architecture is incomplete, it does provide some of the missing 
contextual information (operational and technical) that we had 
identified during our review. The official also stated that future 
versions of the architecture are to be issued quarterly through June 
2004 and semiannually thereafter, and that plans are currently being 
developed for assessing IFMP's alignment with the architecture. The 
IFMP deputy program manager affirmed these plans for assessing IFMP's 
alignment. In the likely event that any misalignment is found, NASA 
will be faced with additional system rework demands.

NASA Does Not Have Key Capabilities in Place for Effectively Managing 
Its Recently Launched Enterprise Architecture Effort:

As NASA proceeds with its enterprise architecture effort, it is 
critical that it employs rigorous and disciplined management practices 
in doing so. Such practices form the basis of our architecture 
management maturity framework,[Footnote 25] which specifies by stages 
the key architecture management controls that are embodied in federal 
guidance and best practices, provides an explicit benchmark for gauging 
the effectiveness of architecture management, and provides a road map 
for making improvements. Each of the five stages is described below.

1.  Creating enterprise architecture awareness. The organization does 
not have plans to develop and use an architecture, or it has plans that 
do not demonstrate an awareness of the value of having and using an 
architecture. While stage 1 agencies may have initiated some 
architecture activity, these agencies' efforts are ad hoc and 
unstructured, lack institutional leadership and direction, and do not 
provide the management foundation necessary for successful architecture 
development.

2.  Building the enterprise architecture management foundation. The 
organization recognizes that the architecture is a corporate asset by 
vesting accountability for it in an executive body that represents the 
entire enterprise. At this stage, an organization assigns architecture 
management roles and responsibilities and establishes plans for 
developing enterprise architecture products and for measuring program 
progress and product quality; it also commits the resources necessary 
for developing an architecture--people, processes, and tools.

3.  Developing the enterprise architecture. The organization focuses on 
developing architecture products according to the selected framework, 
methodology, tool, and established management plans. Roles and 
responsibilities assigned in the previous stage are in place, and 
resources are being applied to develop actual enterprise architecture 
products. The scope of the architecture has been defined to encompass 
the entire enterprise, whether organization-based or function-based.

4.  Completing the enterprise architecture. The organization has 
completed its enterprise architecture products, meaning that the 
products have been approved by the architecture steering committee or 
an investment review board, and by the CIO. Further, an independent 
agent has assessed the quality (i.e., completeness and accuracy) of the 
architecture products. Additionally, evolution of the approved products 
is governed by a written architecture maintenance policy approved by 
the head of the organization.

5.  Leveraging the enterprise architecture to manage change. The 
organization has secured senior leadership approval of the enterprise 
architecture products and a written institutional policy stating that 
IT investments must comply with the architecture, unless granted an 
explicit compliance waiver. Further, decision makers are using the 
architecture to identify and address ongoing and proposed IT 
investments that are conflicting, overlapping, not strategically 
linked, or redundant. Also, the organization tracks and measures 
architecture benefits or return on investment, and adjustments are 
continuously made to both the architecture management process and the 
enterprise architecture products.

For stage 2, our framework specifies nine key practices or core 
elements that are necessary to provide the management foundation for 
successfully launching and sustaining an architecture effort. Examples 
of stage 2 core elements are described below.

* Establish a committee or group representing the enterprise that is 
responsible for directing, overseeing, or approving the enterprise 
architecture. This committee should include executive-level 
representatives from each line of business, and these representatives 
should have the authority to commit resources and enforce decisions 
within their respective organizational units. By establishing this 
enterprisewide responsibility and accountability, the agency 
demonstrates its commitment to building the management foundation and 
obtaining buy-in from across the organization.

* Appoint a chief architect. The chief architect should be responsible 
and accountable for the enterprise architecture, supported by the 
architecture program office, and overseen by the architecture steering 
committee. The chief architect, in collaboration with the CIO, the 
architecture steering committee, and the organizational head, is 
instrumental in obtaining organizational buy-in for the enterprise 
architecture, including support from the business units, as well as in 
securing resources to support architecture management functions, such 
as risk management, configuration management, quality assurance, and 
security management.

* Use a framework, methodology, and automated tool to develop the 
enterprise architecture. These elements are important because they 
provide the means for developing the architecture in a consistent and 
efficient manner. The framework provides a formal structure for 
representing the enterprise architecture, while the methodology is the 
common set of procedures that the enterprise is to follow in developing 
the architecture products. The automated tool serves as a repository 
where architectural products are captured, stored, and maintained.

* Develop an architecture program management plan. This plan specifies 
how and when the architecture is to be developed. It includes a 
detailed work breakdown structure; resource estimates (e.g., funding, 
staffing, and training); performance measures; and management controls 
for developing and maintaining the architecture. The plan demonstrates 
the organization's commitment to managing architecture development and 
maintenance as a formal program.

* Allocate adequate resources. An organization needs to have the 
resources (funding, people, tools, and technology) to establish and 
effectively manage its architecture. This includes, among other things, 
identifying and securing adequate funding to support architecture 
activities, hiring and retaining the right people, and selecting and 
acquiring the right tools and technology to support activities.

Our framework similarly identifies key architecture management 
practices associated with later stages of architecture management 
maturity. For example, at stage 3, the stage at which organizations 
focus on architecture development activities, organizations need to 
satisfy six core elements. Examples of these core elements are 
discussed below.

* Issue a written and approved organization policy for development of 
the enterprise architecture. The policy defines the scope of the 
architecture, including the requirement for a description of the 
baseline and target architecture, as well as an investment road map or 
sequencing plan specifying the move between the two. This policy is an 
important means for ensuring enterprisewide commitment to developing an 
enterprise architecture and for clearly assigning responsibility for 
doing so.

* Ensure that enterprise architecture products are under configuration 
management. This involves ensuring that changes to products are 
identified, tracked, monitored, documented, reported, and audited. 
Configuration management maintains the integrity and consistency of 
products, which is key to enabling effective integration among related 
products and for ensuring alignment between architecture artifacts.

At stage 4, during which organizations focus on architecture completion 
activities, organizations need to satisfy eight core elements. Examples 
of these core elements are described below.

* Ensure that enterprise architecture products and management processes 
undergo independent verification and validation. This core element 
involves having an independent third party--such an as internal audit 
function or contractor that is not involved with any of the 
architecture development activities--verify and validate that the 
products were developed in accordance with architecture processes and 
product standards. Doing so provides organizations with needed 
assurance of the quality of the architecture.

* Ensure that business, performance, information/data, application/
service, and technology descriptions address security. An organization 
should explicitly and consistently address security in its business, 
performance, information/data, application/service, and technology 
architecture products. Because security permeates every aspect of an 
organization's operations, the nature and substance of 
institutionalized security requirements, controls, and standards 
should be captured in the enterprise architecture products.

At stage 5, during which the focus is on architecture maintenance and 
implementation activities, organizations need to satisfy eight core 
elements. Examples of these core elements are described below.

* Make the enterprise architecture an integral component of the IT 
investment management process. Because the road map defines the IT 
systems that an organization plans to invest in as it transitions from 
the "As Is" to the "To Be" environment, the enterprise architecture is 
a critical frame of reference for making IT investment decisions. Using 
the architecture when making such decisions is important because 
organizations should approve only those investments that move the 
organization toward the "To Be" environment, as specified in the road 
map.

* Measure and report return on enterprise architecture investment. Like 
any investment, the enterprise architecture should produce a return on 
investment (i.e., a set of benefits), and this return should be 
measured and reported in relation to costs. Measuring return on 
investment is important to ensure that expected benefits from the 
architecture are realized and to share this information with executive 
decision makers, who can then take corrective action to address 
deviations from expectations.

Table 5 summarizes our framework's five stages and the associated core 
elements for each stage.

Table 5: Summary of the Maturity Stages and Core Elements of GAO's 
Enterprise Architecture (EA) Management Framework:

Stage: Stage 1: Creating EA awareness; Core elements: 
* Agency is aware of EA.

Stage: Stage 2: Building the EA management foundation; Core elements: 
* Adequate resources exist; 
* Committee or group representing the enterprise is responsible for 
directing, overseeing, or approving EA; 
* Program office responsible for EA development and maintenance 
exists; 
* Chief architect exists; 
* EA is being developed using a framework, methodology, and automated 
tool; 
* EA plans call for describing the "As Is" environment, the "To Be" 
environment, and a sequencing plan; 
* EA plans call for describing the enterprise in terms of business, 
information/data, application/service, and technology; 
* EA plans call for business, performance, information/ data, 
application/service, and technology descriptions to address security; 
* EA plans call for developing metrics for measuring EA progress, 
quality, compliance, and return on investment.

Stage: Stage 3: Developing EA products (includes all elements from 
stage 2); Core elements: 
* Written and approved organization policy exists for EA development; 
* EA products are under configuration management; 
* EA products describe or will describe the enterprise's business, 
performance, information/data, application/service, and the technology 
that supports them; 
* EA products describe or will describe the "As Is" environment, the 
"To Be" environment, and a sequencing plan; 
* Business, performance, information/data, application/service, and 
technology descriptions address or will address security; 
* Progress against EA plans is measured and reported.

Stage: Stage 4: Completing EA products (includes all elements from 
stage 3); Core elements: 
* Written and approved organization policy exists for EA maintenance; 
* EA products and management processes undergo independent 
verification and validation; 
* EA products describe the "As Is" environment, the "To Be" 
environment, and a sequencing plan; 
* EA products describe the enterprise's business, performance, 
information/data, application/service, and the technology that 
supports them; 
* Business, performance, information/data, application/service, and 
technology descriptions address security; 
* Organization chief information officer has approved current version 
of EA; 
* Committee or group representing the enterprise or the investment 
review board has approved current version of EA; 
* Quality of EA products is measured and reported.

Stage: Stage 5: Leveraging the EA for managing change (includes all 
elements from stage 4); Core elements: 
* Written and approved policy exists for IT investment compliance 
with EA; 
* Process exists to formally manage EA change; 
* EA is integeral component of IT investment management process; 
* EA products are periodically updated; 
* IT investments comply with EA; 
* Organization head has approved current version of EA; 
* Return on EA investment is measured and reported; 
* Compliance with EA is measured and reported. 

Source: GAO.

[End of table]

The state of NASA's implementation of key enterprise architecture 
management practices, conditions, and structures currently places the 
agency at stage 1 of our maturity framework. Specifically, it has 
satisfied all but one of the core elements associated with building the 
architecture management foundation--stage 2 of our framework--but only 
about 23 percent (5 of the 22) of the core elements associated with 
stages 3, 4, and 5. According to our framework, effective architecture 
management is generally not achieved until an enterprise has a 
completed and approved architecture that is being effectively 
maintained and is being used to leverage organizational change and 
support investment decision making; having these characteristics is 
equivalent to having satisfied all stage 3 core elements and many stage 
4 and 5 elements.

Regarding stage 2 core elements, NASA has, for example, recently 
established a program office, assigned a chief architect, and selected 
a framework (Zachman) and automated tools (e.g., the Rational Rose by 
Rational Software Corporation/IBM Software Group). However, the agency 
has not satisfied a stage 2 core element that is critical to effective 
architecture management. Specifically, a committee or group 
representing the enterprise has not yet been established to guide, 
direct, or approve the architecture. Instead, the CIO is guiding the 
architecture development effort. Having such a corporate entity is 
critical to overcoming cultural resistance to using an enterprise 
architecture. Without such an entity to lead and be accountable for the 
architectural effort, there is increased risk that the architecture 
will not represent a corporate decision-making tool and will not be 
viewed and endorsed as an agencywide asset.

Concerning stage 3, NASA has not satisfied three of six core elements. 
For example, the agency does not have a written and approved policy for 
architecture development, which is a stage 3 core element. Without such 
a policy that, for example, identifies the major players in the 
development process and provides for architecture guidance, direction, 
and approval, NASA will be challenged in overcoming cultural resistance 
to using an enterprise architecture and achieving agencywide 
architecture commitment and support.

The agency also has yet to implement numerous stage 4 and 5 core 
elements. For example, NASA has not (1) documented and approved a 
policy for architecture maintenance, (2) implemented an independent 
verification and validation function that covers architecture products 
and architecture management processes, and (3) made the architecture an 
integral component of its IT investment management process. (The 
detailed results of our assessment of NASA's satisfaction of each of 
the stages and associated core elements are provided in app. III.):

According to the chief technology officer, the agency recognizes the 
importance of having rigorous and disciplined architecture management 
controls and is in the process of establishing them. Our research of 
successful organizations and experience in reviewing other agency 
enterprise architecture efforts shows that not having these controls 
is, among other things, a function of limited senior management 
understanding of and commitment to an enterprise architecture and 
cultural resistance to having and using one. Until such barriers are 
addressed, and effective architecture management structures and 
processes are established, it is unlikely that any agency will be able 
to produce and maintain a complete and enforceable architecture or 
implement modernized systems in a way that minimizes overlap and 
duplication and maximizes integration and mission support.

Conclusions:

NASA's acquisition and implementation of six major IFMP system 
components outside the context of an enterprise architecture was not a 
prudent decision. Such a systems modernization approach unnecessarily 
increases the risk that system components will not effectively and 
efficiently support agencywide operations, which in turn leads to 
costly system rework. It is critical for NASA to discontinue this 
approach and adopt the best practice of managing its IFMP system 
investments within the context of a well-defined enterprise 
architecture. In order to do so, it is important for NASA to establish 
an effective means for developing and implementing an architecture, 
which includes gaining top management understanding and support to lead 
the way in overcoming any cultural resistance. It is equally important 
that the agency ensure that the architecture contains sufficient depth 
and scope, quickly determine whether existing and planned IFMP 
component systems align with initial and subsequent versions of the 
architecture, and limit further investment in these systems until such 
determinations are made. To do less risks introducing additional system 
rework to that already facing the agency on already implemented system 
components.

Recommendations for Executive Action:

To ensure that NASA has the necessary agencywide context within which 
to make informed IFMP and other systems modernization decisions, we 
recommend that the NASA Administrator demonstrate an institutional 
commitment to developing and using an enterprise architecture by 
establishing a NASA enterprise architecture policy and designating a 
NASA architecture board, or comparable body, that is made up of agency 
executives who are responsible and accountable for developing and 
maintaining the architecture.

In carrying out its responsibility, we recommend that the Administrator 
direct the architecture board, in collaboration with the CIO, to ensure 
that the architecture content requirements identified in this report 
are satisfied by first determining the extent to which NASA's initial 
release of an enterprise architecture satisfies these content 
requirements and then developing and approving a plan for incorporating 
any content that is missing.

We further recommend that the Administrator direct the IFMP Program 
Executive Officer to appropriately limit acquisition and implementation 
activities until the agency ensures that the program's plans are 
aligned with the initial and subsequent versions of the enterprise 
architecture. In addition, we recommend that the Administrator direct 
the architecture board, in collaboration with the CIO, to immediately 
map already implemented IFMP components to the agency's enterprise 
architecture and report to the Program Executive Officer any instances 
of misalignment, the associated risks, and proposed corrective actions. 
Moreover, we recommend that the Administrator direct the Program 
Executive Officer to develop corrective action plans, as appropriate, 
that include specific milestones, cost estimates, and detailed actions 
to be taken to align the program with the enterprise architecture.

To further assist NASA, we recommend that the Administrator direct the 
board, in collaboration with the CIO, to ensure that the best practices 
involved in stages 3 through 5 of our enterprise architecture 
management maturity framework are implemented. More specifically, we 
recommend that the board and the CIO (1) establish a written and 
approved policy for architecture development, (2) place enterprise 
architecture products under configuration management, and (3) ensure 
that progress against architecture plans is measured and reported.

In completing the architecture, we recommend that the board and CIO 
(1) establish a written and approved policy for architecture 
maintenance; (2) ensure that enterprise architecture products and 
management processes undergo independent verification and validation; 
(3) ensure that architecture products describe the enterprise's 
business and the data, application, and technology that supports it; 
(4) ensure that enterprise architecture products describe the "As Is" 
environment, the "To Be" environment, and a sequencing plan; (5) ensure 
that business, performance, data, application, and technology 
descriptions address security; (6) ensure that the CIO approves the 
enterprise architecture; (7) ensure that the steering committee and/or 
the investment review board has approved the current version of the 
enterprise architecture; and (8) measure and report on the quality of 
enterprise architecture products.

In implementing the architecture, we recommend that the board and CIO 
(1) establish a written and approved policy for IT investment 
compliance with the enterprise architecture, (2) ensure that the 
enterprise architecture is an integral component of IT investment 
management processes, (3) ensure that IT investments comply with the 
enterprise architecture, (4) obtain Administrator approval of each 
enterprise architecture version, (5) measure and report enterprise 
architecture return on investment, and (6) measure and report on 
enterprise architecture compliance.

Agency Comments and Our Evaluation:

In written comments on a draft of this report signed by the Deputy 
Administrator (reprinted in app. IV), NASA concurred with our 
recommendations and described recently completed, ongoing, or planned 
efforts to address them. For example, the agency stated that it has 
developed a 3-year plan for refining the latest version of its 
architecture, as well as a plan to guide the agency in using the 
architecture to achieve NASA's strategic goals. In addition, the agency 
stated that it has adopted our architecture management maturity 
framework and is currently working to satisfy the framework's core 
elements, including establishing architecture policies and a function 
for independently verifying and validating architecture artifacts and 
management practices. Additionally, it stated that it plans to 
continually validate IFMP against its architecture on a quarterly 
basis.

NASA also stated that its CIO board, which is chaired by NASA's CIO and 
composed of the CIOs from the agency's six major lines of business and 
its ten field centers, serves as the NASA architecture board or 
steering committee. While we support CIO representation on an 
architecture steering committee, recognized best practices and our 
maturity framework both advocate that architecture ownership and 
accountability be vested with an enterprise's business owners. Thus, we 
state in our framework that the architecture steering committee should 
be composed of executive-level representatives from each line of 
business and that these representatives should have the authority to 
commit resources and enforce decisions for their respective 
organizational units. Without such an entity to lead and be accountable 
for the architectural effort, there is increased risk that the 
architecture will be viewed solely as an IT tool and not represent a 
corporate, business-driven decision-making tool and will not be viewed 
and endorsed as an agencywide asset. Accordingly, it is important for 
NASA to ensure that its architecture board's membership includes 
business owner representation.

:

As agreed with your offices, unless you announce its contents earlier, 
we will not distribute this report further until 30 days from its date. 
At that time, we will send copies to interested congressional 
committees as well as to the NASA Administrator and the Director of 
OMB. We will make copies available to others upon request. In addition, 
the report will be available at no charge on the GAO Web site at 
[Hyperlink, http://www.gao.gov] http://www.gao.gov.

If you or your staff have any questions concerning this report, please 
contact me at (202) 512-3439 or [Hyperlink, hiter@gao.gov] 
hiter@gao.gov. Key contributors to this report are acknowledged in 
appendix V.

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

Signed by Randolph C. Hite: 

[End of section]

Appendixes: 

Appendix I: Objective, Scope and Methodology:

To determine whether the National Aeronautics and Space Administration 
(NASA) had and was using an enterprise architecture to guide and 
constrain its investment in its Integrated Financial Management Program 
(IFMP), we requested all NASA enterprise architecture artifacts and 
related documentation that had been used to date to guide and constrain 
IFMP and, based on what we were provided by NASA's chief technology 
officer,[Footnote 26] compared them to relevant guidance.[Footnote 27]

In doing so, we first segmented our analysis of artifacts and guidance 
into the three primary component parts of any architecture: the "As Is" 
architecture, the "To Be," and the transition plan. We then further 
divided the "As Is" and "To Be" architectures into five architectural 
components similar to the Office of Management and Budget's 
architecture reference models: business, information/data, services/
applications, technical, and performance. We also added security as a 
sixth component because of its recognized importance in the various 
architecture frameworks and relevance to the other five architectural 
components. Because NASA had not clearly distinguished between its "As 
Is" and "To Be" environments, the chief technology officer told us to 
treat the architecture products provided as the "To Be" environment and 
assume that any "As Is" content would be intended for reuse in the 
future environment. As a result, we did not analyze whether NASA's 
architecture products satisfied relevant "As Is" guidance; instead, we 
accepted the chief technology officer's acknowledgment that NASA did 
not have any "As Is" artifacts.

To augment our documentation reviews and analyses of architecture 
products used to date in acquiring and implementing IFMP, we also 
interviewed various officials, including the chief information officer 
and chief technology officer, to determine, among other things, the 
agency's plans to develop an enterprise architecture. Specifically, we 
inquired as to NASA's basis for selecting already acquired IFMP 
commercial products and its plans for selecting future IFMP modules, 
including whether the agency had developed an enterprise architecture 
to guide and constrain its future investment in IFMP.

We also requested information on ongoing efforts to develop the initial 
version of NASA's enterprise architecture, such as detailed program 
plans, updated policies and procedures, and the architecture itself, 
but this information was not provided until September 24, 2003, which 
was after we had completed our audit work. As a result, our review did 
not include an assessment of the initial version of NASA's enterprise 
architecture, which the chief technology officer stated addressed some, 
but not all, of the limitations discussed in this report.

To determine whether NASA's initial and subsequent versions of its 
enterprise architecture were supported by effective management 
structures and processes, we used our Enterprise Architecture 
Management Maturity Framework,[Footnote 28] which describes the five 
stages of management maturity, and determined the extent to which NASA 
has adopted key elements of architecture management best practices 
embodied in the framework. To make this determination, we reviewed 
program documentation, such as program policies and procedures, an IBM 
report[Footnote 29] on the agency's efforts to implement management 
processes and controls over its architecture development activities, 
and the architecture products used to date in acquiring IFMP system 
components, and we compared them to the elements in our framework. We 
did not independently validate the cost and budget information provided 
by the chief technology officer.

We conducted our work at NASA headquarters in Washington, D.C. We 
performed our work from June to mid-September 2003 in accordance with 
generally accepted government auditing standards.

[End of section]

Appendix II: Detailed Results of GAO's Analyses of Architecture Products 
Used to Date by NASA to Acquire and Implement IFMP:

Detailed Analysis of NASA's "To Be" Architecture Products:

Key architectural element: Business.

Key architectural element: A description of the overall architectural 
vision and strategic goals that define what an organization wants to 
achieve; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: No; Element satisfied?: Partially: 
Business: Yes; Business: No; Explanation of partially satisfied: 
Business: The available architecture products contain a high-level 
description of the agency's OneNASA vision, which focuses on how 
technology will be managed to improve services (e.g., providing secure 
and highly interoperable information systems in support of all NASA 
operations). It lists mission statements for both the agency and the 
lines of business. The architecture also lists business architecture 
drivers, which can be considered business goals; However, the 
available architecture products do not contain a description of the 
strategic goals, objectives, missions, and implementing strategies 
established to support NASA lines of business. In addition, the 
architecture products do not explain what the OneNASA vision 
encompasses since it appears to be technology-centric, as opposed to 
business-centric (i.e., it addresses business, information/data, 
services/applications, and technology).

Key architectural element: A business strategy, which defines how the 
enterprise's strategic goals and objectives will be achieved; Element 
satisfied?: Yes: Business: No; Element satisfied?: No: Business: 
No; Element satisfied?: Partially: Business: Yes; Business: No; 
Explanation of partially satisfied: Business: The available 
architecture products list business strategies, such as implementing 
the Integrated Financial Management Program (IFMP). However, they do 
not describe how these strategies will be implemented.

Key architectural element: Common (standard and agencywide) policies, 
procedures, and business and operational rules for consistent 
implementation of the architecture; Element satisfied?: Yes: Business: 
No; Element satisfied?: No: Business: Yes; Element satisfied?: 
Partially: Business: No; Business: No; Explanation of 
partially satisfied: Business: No.

Key architectural element: A description of key business processes and 
how they support the agency's mission, including the organizational 
units responsible for performing the business processes and the 
locations where the business processes will be performed. This 
description should provide for the consistent alignment of (1) 
applicable federal laws, regulations, and guidance; (2) agency 
policies, procedures, and guidance; (3) operational activities; (4) 
organizational roles; and (5) operational events and information; 
Element satisfied?: Yes: Business: No; Element satisfied?: No: 
Business: No; Element satisfied?: Partially: Business: Yes; 
Business: No; Explanation of partially satisfied: Business: The 
available architecture products contain a description of the finance 
and accounting processes (i.e., the processes to be supported by the 
IFMP core financial module). This description also identifies the 
subprocesses within these processes and includes detailed diagrams of 
process flows; ; However, these products do not identify the 
organizational units responsible for performing the finance and 
accounting business processes nor the locations where they will be 
performed. Moreover, the architecture products do not contain a 
description of other business processes, such as asset management, 
human resource management, and budget.

Key architectural element: A description of the operational management 
processes to ensure that the agency's business transformation effort 
remains compliant with the business rules for fault, performance, 
security, configuration, and account management; Element satisfied?: 
Yes: Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A listing of opportunities to unify and 
simplify systems or processes across the agency; Element satisfied?: 
Yes: Business: No; Element satisfied?: No: Business: No; 
Element satisfied?: Partially: Business: Yes; Business: No; 
Explanation of partially satisfied: Business: The available 
architecture products recognize the need for an implementing strategy 
to streamline financial operations and identify IFMP as that strategy. 
However, the products do not describe specific opportunities for 
improving weaknesses in the "As Is" financial systems or processes or 
how IFMP will be implemented to achieve this unification/
simplification.

Key architectural element: A description of the organizational approach 
(processes and organizational structure) for communications and 
interactions among business lines and program areas for (1) management 
reporting, (2) operational functions, and (3) architecture development 
and use (i.e., how to develop the architecture description, implement 
the architecture, and govern/manage the development and implementation 
of the architecture); Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: No; Element satisfied?: 
Partially: Business: Yes; Business: No; Explanation of partially 
satisfied: Business: The available architecture products contain a 
description of the management reporting lines for the agency's chief 
information officer (CIO) organization as it relates to managing the 
architecture products and standards. However, they do not describe the 
roles and responsibilities of other organizations. For example, these 
products do not have a model for roles and an organization chart that 
shows the lines of communication and reporting responsibilities for 
financial management operations.

Key architectural element: Information/data.

Key architectural element: A description of data management policies, 
processes, procedures, and tools (e.g., CRUD matrix[A] ) for analyzing, 
designing, building, and maintaining databases in an enterprise 
architected environment; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: Yes; Element satisfied?: Partially: 
Business: No; Business: No; Explanation of partially 
satisfied: Business: No.

Key architectural element: A description of the business and 
operational rules[B] for data standardization to ensure data 
consistency, integrity, and accuracy, such as business and security 
rules that govern access, maintenance, and use of data; Element 
satisfied?: Yes: Business: No; Element satisfied?: No: Business: 
No; Element satisfied?: Partially: Business: Yes; Business: No; 
Explanation of partially satisfied: Business: The available 
architecture products contain a description of technical standards 
currently being used. However, these products do not state whether 
these standards are still relevant or will need to be updated to 
reflect changes to the current environment. In addition, the 
architecture products do not identify data standards upon which 
business rules can later be developed.[C].

Key architectural element: A data dictionary, which is a repository of 
standard data definitions for applications; Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A conceptual data model that describes the 
fundamental things/objects (e.g., invoices, financial statements, 
inventory) that make up the business, but without regard for how they 
will be physically stored. It represents the consolidated structure of 
business objects to be used by business applications; Element 
satisfied?: Yes: Business: No; Element satisfied?: No: Business: 
Yes; Element satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A logical database model that provides (1) 
the data structures that support information flows and (2) the basis 
for developing the schemas for designing, building, and maintaining 
physical databases.[D]; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: Yes; Element satisfied?: Partially: 
Business: No; Business: No; Explanation of partially 
satisfied: Business: No.

Key architectural element: A metadata[E] model that specifies the rules 
and standards for access to information.f; Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A description of information flows and 
relationships between organizational units, business operations, and 
system elements; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: Yes; Element satisfied?: Partially: Business: 
No; Business: No; Explanation of partially satisfied: 
Business: No.

Key architectural element: Services/applications.

Key architectural element: A description of the end-user services to be 
provided by the application systems; Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A list of application systems (acquisition/
development and production portfolio)[G] and their relative importance 
to achieving the agency's vision based on business value and technical 
performance; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: Yes; Element satisfied?: Partially: Business: 
No; Business: No; Explanation of partially satisfied: 
Business: No.

Key architectural element: A description of the policies, procedures, 
processes, and tools for selecting, controlling, and evaluating 
application systems to enable effective IT investment management; 
Element satisfied?: Yes: Business: No; Element satisfied?: No: 
Business: Yes; Element satisfied?: Partially: Business: No; 
Business: No; Explanation of partially satisfied: Business: 
No.

Key architectural element: A description of the enterprise application 
systems and components and their interfaces.[G]; Element satisfied?: 
Yes: Business: No; Element satisfied?: No: Business: No; 
Element satisfied?: Partially: Business: Yes; Business: No; 
Explanation of partially satisfied: Business: The available 
architecture products contain a description of an enterprise 
application system that supports finance and accounting (IFMP core 
financial module) functions. They also identify legacy systems that 
interface with this application system; However, this description is 
limited to this one system.

Key architectural element: A description of the common technical 
approach, policies, and procedures for developing/acquiring 
application systems throughout their life cycle, including requirements 
management, design, implementation, testing, deployment, operations, 
and maintenance. The common technical approach should also describe the 
process for integrating legacy systems with the systems to be 
developed/acquired; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: No; Element satisfied?: 
Partially: Business: Yes; Business: No; Explanation of partially 
satisfied: Business: The available architecture products list several 
architectural principles for system development and acquisition (e.g., 
modular design, open system approach) and identify a strategy (i.e., a 
hub-spoke configuration) for integrating legacy systems. They also 
identify a minimum set of technical standards for hardware and 
software. In addition, the architecture products contain policies and 
guidance for implementing systems; However, these products do not 
describe a common technical approach. In addition, the products did not 
state whether the existing policies and procedures are common, 
complete, and sufficient to effectively implement the architecture. 
They do recognize the need to revise existing policies and procedures.

Key architectural element: Technical.

Key architectural element: A list of infrastructure systems and their 
relative importance to achieving the agency's vision based on business 
value and technical performance; Element satisfied?: Yes: Business: 
No; Element satisfied?: No: Business: Yes; Element satisfied?: 
Partially: Business: No; Business: No; Explanation of 
partially satisfied: Business: No.

Key architectural element: A description of the policies, procedures, 
processes, and tools for selecting, controlling, and evaluating 
infrastructure systems to enable effective IT investment management; 
Element satisfied?: Yes: Business: No; Element satisfied?: No: 
Business: Yes; Element satisfied?: Partially: Business: No; 
Business: No; Explanation of partially satisfied: Business: 
No.

Key architectural element: A description of the technical reference 
model (TRM[H]) that describes the enterprise infrastructure services,  
including specific details regarding the functionality and capabilities 
that these services will provide to enable development of application 
systems; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: No; Element satisfied?: Partially: 
Business: Yes; Business: No; Explanation of partially satisfied: 
Business: The available architecture products recognize the need for a 
TRM and contain a generic description of the TRM. These products also 
note that technology services needed to support the application 
portfolio should be defined and identify several of these services; 
However, according to NASA's chief technology officer, the TRM is 
incomplete and flawed. In addition, the list of technology services 
identified is incomplete.

Key architectural element: A description in the TRM that identifies and 
describes the technical standards[J] to be implemented for each 
enterprise service; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: No; Element satisfied?: 
Partially: Business: Yes; Business: No; Explanation of partially 
satisfied: Business: The available architecture products note that 
these standards should be identified and documented. They also contain 
a list of specific standards; However, the architecture products do 
not state whether these standards are for the current or future 
environment. In addition, the architecture products do not identify the 
technical standards to be implemented for specific enterprise services, 
such as query processing.

Key architectural element: A description of the physical IT 
infrastructure needed to support the developed and/or acquired systems, 
including the relationships among hardware, software, and 
communications devices; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: No; Element satisfied?: 
Partially: Business: Yes; Business: No; Explanation of partially 
satisfied: Business: The available architecture products contain a 
high-level description (i.e., diagrams without supporting narrative) of 
the IFMP core financial network, OneNASA network backbone, and NASA's 
Information System Services Utility (NISSU[K] ) network architecture; 
However, these networks do not encompass the entire enterprise, but 
rather a subset of activities.

Key architectural element: Common policies and procedures for 
developing infrastructure systems throughout their life cycle, 
including requirements management, design, implementation, testing, 
deployment, operations, and maintenance. These policies and procedures 
should also address the integration of applications, including legacy 
systems; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: No; Element satisfied?: Partially: 
Business: Yes; Business: No; Explanation of partially satisfied: 
Business: The available architecture products contain a list of 
policies and procedures for implementing systems. However, the products 
do not state whether these policies and procedures are common, 
complete, and sufficient to effectively implement the architecture.

Key architectural element: Security.

Key architectural element: A description of the policies, procedures, 
goals, strategies, and requirements relevant to information assurance 
and security and how they (the policies, procedures, goals, strategies, 
and requirements) align and integrate with other elements of the 
architecture (e.g., security services); Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: No; Element 
satisfied?: Partially: Business: Yes; Business: No; Explanation of 
partially satisfied: Business: The available architecture products 
contain a high-level description of security goals and strategies and 
identify some security requirements. They also note that an 
"Information Assurance Trust Model" is needed and will be developed; 
The architecture products do not contain a description of security 
policies and procedures. They also do not identify important security 
requirements (e.g., availability and access control), nor do they link 
identified security requirements to security services. Moreover, the 
architecture products do not define the "Information Assurance Trust 
Model" or address plans for its completion. Finally, regarding the 
strategies, they do not identify and summarize the agency's most 
significant security risks; According to NASA's chief technology 
officer, a clear computer security policy does not exist within the 
agency, and there is a lack of understanding as to how such a policy 
could be integrated into the network infrastructure.

Key architectural element: Definitions of security and information 
assurance related terms; Element satisfied?: Yes: Business: No; 
Element satisfied?: No: Business: No; Element satisfied?: 
Partially: Business: Yes; Business: No; Explanation of partially 
satisfied: Business: The available architecture products contain 
definitions for some security-related terms (e.g., authentication, 
confidentiality, and intrusion detection); however, they do not define 
other key terms listed (e.g., integrity, physical security, and 
encryption services). In addition, the definitions for these terms are 
inconsistent with the definitions shown in current standards (e.g., 
firewalls).

Key architectural element: A listing of accountable organizations and 
their respective responsibilities for implementing enterprise security 
services. Organizational relationships are important to show in an 
operational view because they illustrate fundamental roles (e.g., who 
conducts operational activities) and management relationships (e.g., 
what is the command structure or relationship to other key players), 
and how they influence the operational nodes; Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A description of operational security rules 
that are derived from security policies; Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: Yes; Element 
satisfied?: Partially: Business: No; Business: No; 
Explanation of partially satisfied: Business: No.

Key architectural element: A description of enterprise security 
infrastructure services (e.g., identification and authentication) that 
will be needed to protect the agency's assets, and the means for 
implementing such a service (e.g., firewalls and intrusion detection 
software). This description should also address how these services will 
align and integrate with other elements of the architecture (e.g., 
security policies and requirements); Element satisfied?: Yes: 
Business: No; Element satisfied?: No: Business: No; Element 
satisfied?: Partially: Business: Yes; Business: No; Explanation of 
partially satisfied: Business: The available architecture products 
contain high-level descriptions of enterprise security services; 
however, in most instances, these products describe the technology 
components that will be implemented to provide the security service, 
and not the security service. For example, the architecture products 
classify "Audit Logs" as a security service; however, audit logs are 
generally the function/component within an "Auditing Service."; The 
architecture products also do not link the security services to 
security policies, procedures, goals, strategies, and requirements.

Key architectural element: A description of the security standards to 
be implemented for each enterprise service. These standards should be 
derived from security requirements. This description should also 
address how these services will align and integrate with other elements 
of the architecture (e.g., security policies and requirements); 
Element satisfied?: Yes: Business: No; Element satisfied?: No: 
Business: No; Element satisfied?: Partially: Business: Yes; 
Business: No; Explanation of partially satisfied: Business: The 
available architecture products contain a description of various 
security standards, but it is unclear if these standards are relevant 
to the "As Is" or "To Be" environment or both; In addition, the 
architecture products do not contain a traceability matrix that links 
goals, strategies, requirements, and services to the security standards 
and security products (e.g., SmartCard). They also do not clearly state 
whether the list of security standards for enterprise services is 
complete.

Key architectural element: A description of the protection mechanisms 
that will be implemented to secure the agency's assets, such as 
firewalls and intrusion detection software, including a description of 
the relationships among these protection mechanisms; Element 
satisfied?: Yes: Business: No; Element satisfied?: No: Business: 
No; Element satisfied?: Partially: Business: Yes; Business: No; 
Explanation of partially satisfied: Business: The available 
architecture products contain a high-level description of protection 
mechanisms (e.g., firewalls). However, they do not describe the level 
of protection needed and the types of services the protection 
mechanisms will provide to protect IFMP applications that access 
information/data, business services/applications, and the various 
networks; In addition, the architecture products do not contain a 
traceability matrix that links goals, strategies, requirements, and 
services to the security standards, so it is unclear whether this is 
the definitive list of protection mechanisms.

Key architectural element: Performance.

Key architectural element: A description of the processes for 
establishing, measuring, tracking, evaluating, and predicting business 
performance regarding business functions, baseline data, and service 
levels; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: Yes; Element satisfied?: Partially: Business: 
No; Business: No; Explanation of partially satisfied: 
Business: No.

Key architectural element: A description of customer-focused measurable 
business goals and outcomes for business products and services through 
the execution of financial and financial-related business activities; 
Element satisfied?: Yes: Business: No; Element satisfied?: No: 
Business: Yes; Element satisfied?: Partially: Business: No; 
Business: No; Explanation of partially satisfied: Business: 
No.

Key architectural element: A description of measurable technical goals 
and outcomes for managing technology products and services for the "To 
Be" architecture that enable the achievement of business goals and 
outcomes; Element satisfied?: Yes: Business: No; Element 
satisfied?: No: Business: Yes; Element satisfied?: Partially: Business: 
No; Business: No; Explanation of partially satisfied: 
Business: No.

Source: GAO analysis of NASA data.

[A] A CRUD (create, read, update, and/or delete) matrix shows the 
specific business functions and applications that create, read, update, 
and/or delete specific data elements, which enables the organization to 
develop applications.

[B] Business and operational rules define specific constraints for the 
data, such as security needs (e.g., confidentiality and accessibility 
of data) and actions that should or should not occur, such as updating 
or deleting data.

[C] The framework that NASA is using for architecture development does 
not identify a work product that supports the creation of business 
rules.

[D] Although the framework that NASA is using identifies a logical 
database model as a work product, the available architecture products 
do not include such a model, and there was contradictory evidence in 
the architecture products that stated that NASA considered this model 
to be nonessential. As a result, it is unclear whether the agency plans 
to produce a logical database model as part of its architecture 
description.

[E] Metadata is "data about data" that enables automation and 
consistent management and use of information, such as rules and 
standards.

[F] The framework that NASA is using does not identify the metadata 
model as a type of work product nor does the agency's action plan 
address the development of a metadata model for later inclusion in the 
architecture description.

[G] While the framework that NASA is using does identify the 
application portfolio as a type of work product, the agency's action 
plan does not address the development of this portfolio for later 
inclusion in the architecture description.

[H] The technical reference model (TRM) describes how technology is 
supporting the delivery of service components, including relevant 
standards for implementing the technology. The TRM is a generally 
accepted representation of the generic components of an information 
system. It allows designers, developers, and users to agree on 
definitions, have a common understanding of the services to be 
provided, and identify and resolve issues affecting such requirements 
as interoperability, portability, reliability, scalability, and 
serviceability.

[I] Examples of enterprise services include application services, such 
as Web services, and collaboration services, such as instant messaging 
and video conferencing.

[J] Technical standards are strict rules and protocols governing how a 
given enterprise service is to be implemented.

[K] NISSU was initially established to support the deployment of the 
IFMP core financial module. However, NASA is now considering using this 
technical infrastructure to support the deployment of other enterprise 
applications that have yet to be identified.

[End of table]

Detailed Analysis of NASA's Transition Plan Artifacts:

Key architectural element: Transition plan.

Key architectural element: Analysis of the gaps between the baseline 
and target architecture for business processes, information/data, and 
services/application systems to define missing and needed 
capabilities; Element satisfied?: Yes: Transition plan: No; 
Element satisfied?: No: Transition plan: Yes; Element satisfied?: 
Partially: Transition plan: No; Transition plan: No; 
Explanation of partially satisfied: Transition plan: No.

Key architectural element: A high-level strategy[A] for implementing 
the enterprise architecture, including specific time-phased milestones 
for acquiring and deploying systems, performance metrics, and financial 
and nonfinancial resource needs; Element satisfied?: Yes: Transition 
plan: No; Element satisfied?: No: Transition plan: No; 
Element satisfied?: Partially: Transition plan: No; Transition 
plan: No; Explanation of partially satisfied: Transition plan: 
No.

Key architectural element: This strategy should include:; Element 
satisfied?: Yes: Transition plan: No; Element satisfied?: No: 
Transition plan: No; Element satisfied?: Partially: Transition 
plan: No; Transition plan: No; Explanation of partially 
satisfied: Transition plan: No.

Key architectural element: * A listing of the legacy systems that will 
not be part of the "To Be" environment and the schedule for terminating 
these systems; Element satisfied?: Yes: Transition plan: No; 
Element satisfied?: No: Transition plan: No; Element satisfied?: 
Partially: Transition plan: Yes; Transition plan: No; Explanation of 
partially satisfied: Transition plan: The transition plan identifies 
only the core financial legacy systems that have been or will be 
retired. It does not identify all legacy systems or provide a schedule 
for terminating these systems.

Key architectural element: * A description of the training strategy/
approach that will be implemented to address the changes made to the 
business operations (processes and systems) to promote operational 
efficiency and effectiveness. This plan should also address any changes 
to existing policies and procedures affecting day-to-day operations, as 
well as resource needs (staffing and funding); Element satisfied?: 
Yes: Transition plan: No; Element satisfied?: No: Transition plan: 
No; Element satisfied?: Partially: Transition plan: Yes; Transition 
plan: No; Explanation of partially satisfied: Transition plan: The 
transition plan provides a high-level description of a training 
strategy and references a change management strategy for IFMP. It also 
identifies a business driver for improving human capital management 
within the organization; ; However, the architecture does not 
(1) address training needs for nonfinancial business operations, 
(2) contain training plans, (3) identify changes to existing policies 
and procedures, or (4) estimate resource needs. Moreover, this generic 
strategy was developed without the benefit of a gap analysis.

Key architectural element: * A list of the systems to be developed/
acquired/modified to achieve business needs and a description of the 
relationship between the system and the business need(s); Element 
satisfied?: Yes: Transition plan: No; Element satisfied?: No: 
Transition plan: No; Element satisfied?: Partially: Transition 
plan: Yes; Transition plan: No; Explanation of partially satisfied: 
Transition plan: The transition plan notes that there is a list of 
project development initiatives, such as core financial and travel 
manager, but it does not provide a complete list of systems to be 
developed or acquired to achieve business needs (e.g., human resources 
and budget).

Key architectural element: * A strategy for employing enterprise 
application integration (EAI) plans, methods, and tools to, for 
example, provide for efficiently reusing applications that already 
exist concurrent with adding new applications and databases; Element 
satisfied?: Yes: Transition plan: No; Element satisfied?: No: 
Transition plan: No; Element satisfied?: Partially: Transition 
plan: Yes; Transition plan: No; Explanation of partially satisfied: 
Transition plan: The transition plan contains a description of an EAI 
strategy for IFMP applications. However, the transition plan does not 
state whether this strategy would be applied to other agencywide 
application systems.

Key architectural element: A technical migration plan (systems, 
infrastructure, and data) that shows:; Element satisfied?: Yes: 
Transition plan: No; Element satisfied?: No: Transition plan: 
No; Element satisfied?: Partially: Transition plan: No; 
Transition plan: No; Explanation of partially satisfied: 
Transition plan: No.

Key architectural element: (a) the transition from legacy to replacement 
systems with explicit "sunset" dates and intermediate systems that may 
be temporarily needed to sustain existing functionality during the 
transition period; Element satisfied?: Yes: Transition plan: No; 
Element satisfied?: No: Transition plan: Yes; Element satisfied?: 
Partially: Transition plan: No; Transition plan: No; 
Explanation of partially satisfied: Transition plan: No.

Key architectural element: (b) an analysis of system interdependencies, 
including the level of effort required to implement related systems in 
a sequenced portfolio of projects that includes milestones, timelines, 
costs, and capabilities; and; Element satisfied?: Yes: Transition plan: 
No; Element satisfied?: No: Transition plan: Yes; Element 
satisfied?: Partially: Transition plan: No; Transition plan: 
No; Explanation of partially satisfied: Transition plan: No.

Key architectural element: (c) a cost estimate for the initial phase(s) 
of the transition and high-level cost projection for transition to the 
target architecture; Element satisfied?: Yes: Transition plan: 
No; Element satisfied?: No: Transition plan: Yes; Element 
satisfied?: Partially: Transition plan: No; Transition plan: 
No; Explanation of partially satisfied: Transition plan: No.

Key architectural element: A description of the architecture governance 
and control structure and the integrated procedures, processes, and 
criteria (e.g., investment management, security) to be followed to 
ensure that the agency's business transformation effort remains 
compliant with the architecture; Element satisfied?: Yes: Transition 
plan: No; Element satisfied?: No: Transition plan: Yes; Element 
satisfied?: Partially: Transition plan: No; Transition plan: 
No; Explanation of partially satisfied: Transition plan: No.

Source: GAO analysis of NASA data.

[A] Acquisition/business strategy is a plan or action for achieving a 
specific goal or result through contracting for software products and 
services.

[End of table]

[End of section]

Appendix III: Assessment of NASA's EA Management Efforts against GAO's 
Architecture Management Maturity Framework:

Stage: Stage 1: EA awareness; Core element: Agency is aware of EA; 
Satisfied? Yes; Comments: In December 2002, the CIO issued a 
memorandum stating the agency's intent to develop and use an EA.

Stage: Stage 2: Building the EA management foundation; Core element: 
Adequate resources exist (funding, people, tools, and technology); 
Satisfied? Yes; Comments: According to the chief technology officer 
(CTO), the agency has adequate program funding. NASA estimates that it 
will cost $750,000 to develop its EA for fiscal years 2001 through 
2003. Further, the agency reports that it has skilled staff 
(government employees and contractors) for its architecture program. 
In addition, NASA is using automated tools and technology, such as 
Rational Rose by Rational Software Corporation/IBM Software Group.

Core element: Committee or group representing the enterprise is 
responsible for directing, overseeing, or approving the EA; 
Satisfied? No; Comments: NASA has not assigned responsibility for 
directing, overseeing, or approving the EA to a committee or group 
comprising representatives from across the agency.

Core element: Program office responsible for EA development and 
maintenance exists; Core element: Yes; Comments: In December 2002, 
NASA established a program office that is responsible for EA 
development and maintenance.

Core element: Chief architect exists; Satisfied? Yes; Comments: In 
January 2003, NASA designated the CTO as the chief architect.

Core element: EA is being developed using a framework, methodology, 
and automated tool; Core element: Yes; Comments: The EA is being 
developed using the Zachman framework. According to the CTO, the 
agency is also using a defined methodology to develop the EA.[A] In 
addition, NASA is using automated tools, such as Rational Rose by 
Rational Software Corporation/IBM Software Group, to build the EA.

Core element: EA 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."; Satisfied? Yes; 
Comments: According to the CTO, the plans[B] for the EA provide for 
describing both the "As Is" and the "To Be" environments and a 
sequencing plan.

Core element: EA plans call for describing both the "As Is" and the 
"To Be" environments in terms of business, performance, information/
data, application/service, and technology; Satisfied? Yes; Comments: 
According to the CTO, the plans[B] for the EA provide for describing 
both the "As Is" and the "To Be" environments in terms of business, 
performance, information/data, application/service, and technology.

Core element: EA plans call for business, performance, information/
data, application/service, and technology descriptions to address 
security; Satisfied? Yes; Comments: According to the CTO, the plans[B] 
for the EA provide for addressing security for the "As Is" and "To 
Be" environments.

Stage: Stage 2: Building the EA management foundation; Core element: 
EA plans call for developing metrics for measuring EA progress, 
quality, compliance, and return on investment; Satisfied? Yes; 
Comments: According to the CTO, the plans[B] for the EA provide for 
developing metrics to measure progress, quality, compliance, and 
return on investment.

Stage: Stage 3: Developing EA products (includes all elements from 
stage 2); Core element: Written/approved organization policy exists 
for EA development; Satisfied? No; Comments: According to the CTO, 
the agency is revising its existing policy to require the development 
of an EA. As written, the policy requires the CIO to develop an 
information technology (IT) architecture, which is one aspect of an 
EA.

Core element: EA products are under configuration management; 
Satisfied? No; Comments: According to the CTO, EA products are not 
currently under configuration management.

Core element: EA products describe or will describe both the "As Is" 
and the "To Be" environments of the enterprise, as well as a 
sequencing plan for transitioning from the "As Is" to the "To Be."; 
Satisfied? Yes; Comments: According to the CTO, the plans[B] for the 
EA products provide for describing the "As Is" and the "To Be" 
environments, as well as a sequencing plan.

Core element: Both the "As Is" and the "To Be" environments are 
described or will be described in terms of business, performance, 
information/data, application/ service, and technology; Satisfied? 
Yes; Comments: According to the CTO, the plans[B] for the EA provide 
for describing both the "As Is" and "To Be" environments in terms of 
business, performance, information/data, application/service, and 
technology.

Core element: Business, performance, information/data, application/
service, and technology descriptions address or will address 
security; Satisfied? Yes; Comments: According to the CTO, the plans[B] 
for the EA provide for the business, performance, information/data, 
application/service, and technology descriptions addressing security 
for the "As Is" and "To Be" environments.

Core element: Progress against EA plans is measured and reported; 
Satisfied? No; Comments: According to the CTO, the agency is 
measuring and reporting progress against EA plans; however, NASA was 
unable to provide evidence of these reports.

Stage: Stage 4: Completing EA products; (includes all elements from 
stage 3); Core element: Written/approved organization policy exists 
for EA maintenance; Satisfied? No; Comments: There is no written/
approved policy for EA maintenance.

Core element: EA products and management processes undergo independent 
verification and validation; Satisfied? No; Comments: According to the 
CTO, management processes are independently verified and validated, 
but EA products do not undergo independent verification and 
validation. According to the CTO, EA products will be subject to 
independent verification and validation in the future.

Core element: EA products describe both the "As Is" and the "To Be" 
environments of the enterprise, as well as a sequencing plan for 
transitioning from the "As Is" to the "To Be."; Satisfied? No; 
Comments: According to the CTO, the plans[B] for the EA provide 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." However, the initial version of NASA's EA was 
not provided to us in time to determine if its products address this 
core element. Therefore, our analysis is based on the products that 
were used to date to guide and constrain IFMP.

Core element: Both the "As Is" and the "To Be" environments are 
described in terms of business, performance, information/data, 
application/service, and technology; Satisfied? No; Comments: 
According to the CTO, the plans[B] for the EA provide for describing 
both the "As Is" and "To Be" environments in terms of business, 
performance, information/data, application/service, and technology. 
However, the initial version of NASA's EA was not provided to us in 
time to determine if its products address this core element. 
Therefore, our analysis is based on the products that were used to 
date to guide and constrain IFMP.

Core element: Business, performance, information/data, application/
service, and technology descriptions address security; Satisfied? No; 
Comments: According to the CTO, the plans[B] for the EA provide for 
the business, performance, information/data, application/service, and 
technology descriptions addressing security. However, the initial 
version of NASA's EA was not provided to us in time to determine if 
its products address this core element. Therefore, our analysis is 
based on the products that were used to date to guide and constrain 
IFMP.

Core element: Organization CIO has approved current version of EA; 
Satisfied? No; Comments: The CIO approved the initial version of the 
EA. However, the initial version of NASA's EA was not provided to us 
in time to determine if its products address this core element. 
Therefore, our analysis is based on the products that were used to 
date to guide and constrain IFMP.

Core element: Committee or group representing the enterprise or the 
investment review board has approved current version of EA; 
Satisfied? No; Comments: According to the CTO, the plans[B] for the 
EA do not provide for approval by a committee or group representing 
the enterprise or the investment review board.

Core element: Quality of EA products is measured and reported; 
Satisfied? No; Comments: According to the CTO, the quality of EA 
products is not measured and reported.

Stage: Stage 5: Leveraging the EA for managing change; (includes all 
elements from stage 4); Core element: Written/approved organization 
policy exists for IT investment compliance with EA; Satisfied? No; 
Comments: There is no written/approved policy requiring IT investment 
compliance with the EA. The current policy requires the CIO to ensure 
that new IT investments are in alignment with technology 
architectures, which are one aspect of an EA. According to the CTO, 
this policy is being revised.

Core element: Process exists to formally manage EA change; Satisfied? 
Yes; Comments: According to the CTO, there is a process for formally 
managing EA change.

Core element: EA is integral component of IT investment management 
process; Satisfied? No; Comments: Since the EA is currently being 
developed and has not been used to date in acquiring and implementing 
IFMP, it is not part of the investment management process.

Core element: EA products are periodically updated; Satisfied? Yes; 
Comments: According to NASA, it plans to update the EA quarterly 
through June 2004, and semiannually thereafter.

Core element: IT investments comply with EA; Satisfied? No; Comments: 
Since the EA is currently being developed and has not been used to 
date in acquiring and implementing IFMP, it is not part of the 
investment management process.

Core element: Organization head has approved current version of EA; 
Satisfied? No; Comments: The organization head has not approved the 
current version of the EA.

Core element: Return on EA investment is measured and reported; 
Satisfied? No; Comments: Metrics and processes for measuring EA 
benefits have not been developed, and an initial version of the EA 
has not been completed, thus precluding return-on-investment 
measurement.

Core element: Compliance with EA is measured and reported; Satisfied? 
No; Comments: Metrics for measuring EA compliance have not been 
developed, and an initial version of the EA has not been completed, 
thus precluding measuring and reporting on compliance. 

Source: GAO analysis of NASA data.

[A] According to NASA, its methodology is from the following: Melissa 
A. Cook, Building Enterprise Information Architectures: Reengineering 
Information Systems, Prentice Hall Inc. (1996).

[B] We requested NASA's architecture program plan, but NASA did not 
provide it.

[End of table]

[End of section]

Appendix IV: Comments from the National Aeronautics and Space 
Administration:

National Aeronautics and Space Administration:

Office of the Administrator 
Washington, DC 20546-0001:

October 31, 2003:

Mr. Randolph C. Hite: 
Director:

Information Technology and Systems Issues: 
United States General Accounting Office Washington, DC 20548:

Dear Mr. Hite:

Enclosed is the National Aeronautics and Space Administration's (NASA) 
response to the General Accounting Office (GAO) Draft Report, 
"Architecture Needed to Guide NASA's Financial Management 
Modernization," (GAO-04-43). The Agency concurs with your 
recommendations for corrective action. Please find enclosed our 
detailed comments on each individual recommendation.

My point-of-contact for enterprise architecture is Dr. John McManus, 
Chief Technology Officer, Office of the Chief Information Officer 
(CIO). He may be contacted by e-mail: jmcmanus@nasa.gov or by telephone 
at (202) 358-1802.

Cordially,

Signed by: 

Frederick D. Gregory: 
Deputy Administrator:

Enclosure:

Enclosure:

NASA Response to Draft General Accounting Office's (GAO) Report: 
"Architecture Needed to Guide NASA's Financial Management 
Modernization," (GAO-04-43):

1. GAO Recommendation: The Administrator establish a NASA Enterprise 
Architecture Policy and designate a NASA Architecture Board that is 
made up of Agency executives who are responsible and accountable for 
developing and maintaining the architecture.

NASA Response to GAO Recommendation 1: Concur. The NASA enterprise 
architecture policy guidance is contained in NPG 2800.1, Managing 
Information Technology. NPG 2800.1 is currently being updated; the next 
version is due for release in the first quarter of FY 2004. The updated 
NASA enterprise architecture policy will address the General Accounting 
Office's recommendations on the issue.

The NASA Chief Information Officer (CIO) is responsible and accountable 
for developing and maintaining the enterprise architecture. The NASA 
CIO has responsibility for ensuring that NASA's information assets are 
acquired and managed consistent with federal policies, procedures, and 
legislation and that the Agency's Information Resource Management (IRM) 
strategy and enterprise architecture are in alignment with NASA's 
vision, mission, and strategic goals.

The NASA CIO Board serves as the NASA Architecture Board. The NASA CIO 
Board is chaired by the NASA CIO and includes as members the CIO's from 
each of the 6 major NASA enterprises and the 10 Field Centers.

In March of 2003, the NASA CIO established a NASA Enterprise 
Architecture Working Group to develop and maintain future releases of 
the NASA Enterprise Architecture. The NASA Enterprise Architecture 
Working Group is led by the NASA CIO's Chief Technology Officer (Chief 
Enterprise Architect) and has representation from the 6 major NASA 
enterprises and the 10 Field Centers. The NASA Enterprise Architecture 
Working Group reports directly to the NASA CIO.

NASA's architectural development is an iterative and continuous 
process. NASA is fully committed to working with the Office of 
Management and Budget (OMB), the General Accounting Office (GAO), and 
other entities within the Federal Government to identify opportunities 
to collaborate, consolidate, and leverage investments to reach the goal 
of overall government improvement.

2. GAO Recommendation: The Administrator direct the architecture board, 
in collaboration with the CIO, to ensure that the architecture content 
requirements identified in this report are satisfied by first 
determining the extent to which:

NASA's initial release of an enterprise architecture satisfies these 
requirements, and then developing a plan for incorporating any content 
that is missing.

NASA Response to GAO Recommendation 2: Concur. On September 22, 2003, 
NASA delivered version 2.0 of the NASA Enterprise Architecture. NASA 
incorporated preliminary comments and suggestion from GAO in the 
drafting of Version 2.0 of the enterprise architecture. Version 2.0 
meets the content requirements outlined in the draft GAO report. NASA 
also delivered a revised Information Resources Management Strategic 
Plan and an updated Capital Planning and Investment Control Process.

Version 2.0 of the NASA Enterprise Architecture documents the complete 
Agency enterprise architecture, including the Infrastructure, Office 
Automation and Telecommunications segment, a representative set of 
elements from the Mission Specific Information Technology (IT) segment 
and the Financial Architectural Segment. NASA has determined that, in 
order to continue to meet its mission effectively and efficiently, and 
to facilitate better program, project and information technology 
decision-making, it is important to develop, communicate and manage a 
consistent agencywide enterprise architecture. NASA has made strong 
progress in developing and refining the Agency's enterprise 
architecture over the past year. The Agency enterprise architecture 
team has compiled the current "As-Is" architecture and is continuing 
refinement of the "To-Be" architecture. NASA has developed a detailed 
3-year plan for continued refinement of the NASA Enterprise 
Architecture. The plan is described in Appendix A of Version 2.0 of the 
NASA Enterprise Architecture.

NASA has adopted the GAO architecture maturity framework and is 
currently in the selection process phase for an outside organization 
which would provide annual Independent Verification and Validation 
(IV&V) capability for our Enterprise Architecture and annual 
assessments on NASA's progress against the GAO architecture maturity 
framework.

In the near-term (development stage), the NASA Enterprise Architecture 
will undergo quarterly updates for 1 year, starting with the September 
22, 2003, release of version 2.0. Version 2.1 will be released in 
December 2003, version 2.2 will be released in March 2004 and version 
2.3 will be released in June 2004. Starting with version 3.0, scheduled 
for release in September 2004, the NASA Enterprise Architecture will 
transition to a semi-annual release schedule. The document release 
schedule will be reviewed on a semi-annual basis and updated as 
required. The details of the "To-Be" state for the President's 
Management Agenda Electronic Government (E-Gov) initiatives will be 
defined in versions 2.1, 2.2, and 2.3 of this document, as NASA and the 
Managing Partners for each initiative develop detailed development and 
integration plans.

3. GAO Recommendation: The Administrator direct the architecture board, 
in collaboration with the CIO, to ensure that best practices involved 
with stages 3 through 5 of the GAO architecture maturity framework are 
implemented.

a. Establish a written and approved policy for architecture 
development.

b. Place enterprise architecture products under configuration 
management.

c. Ensure that progress against the architecture plan is measured and 
reported.

NASA Response to GAO Recommendation 3: Concur. NASA has adopted the GAO 
architecture maturity framework. Furthermore, NASA has made significant 
progress in developing and refining its Enterprise Architecture over 
the past year. NASA is currently interviewing potential vendors to 
provide an annual Independent Verification and Validation of the NASA 
Enterprise Architecture artifacts and annual assessments against the 
GAO architecture maturity framework.

NASA is also updating its published enterprise architecture development 
policy guidance, contained in NPG 2800.1, Managing Information 
Technology. NPG 2800.1 is currently in revision; the next version is 
due for release in the first quarter of FY 2004.

NASA placed all enterprise architecture products under configuration 
control and management in August 2003. All of the enterprise 
architecture artifacts are stored in a central repository managed by 
the NASA CIO's Chief Technology Officer (Chief Enterprise Architect) 
and the NASA Enterprise Architecture Working Group.

Over the past year, NASA developed a 3-year plan for continued 
refinement of the NASA Enterprise Architecture. The plan is described 
in Appendix A of Version 2.0 of the NASA Enterprise Architecture 
document. The detailed enterprise architecture plan established the 
NASA roadmap for progressing forward in the GAO architecture maturity 
framework. The NASA CIO's Chief Technology Officer (Chief Enterprise 
Architect) will provide quarterly updates on the progress against the 
architecture plan in FY 2004 and semi-annual reports starting in FY 
2005.

4. GAO Recommendation: The Administrator directs the architecture board 
and the CIO:

a. Establish a written and approved policy for architecture 
maintenance. b. Ensure that enterprise architecture products and 
management process undergo an independent verification and validation.

c. Ensure that architecture products describe the enterprise's business 
and the data, application(s) and technology that supports it.

d. Ensure that the enterprise architecture products describe the "As 
Is" environment, the "To Be" environment and a sequencing plan.

e. Ensure the business, performance, data, application, and technology 
descriptions address security.

f. Ensure the CIO approves the enterprise architecture.

g. Ensure the steering committee and/or the investment review board has 
approved the current version of the enterprise architecture.

h. Measure and report on the quality of the enterprise architecture 
products.

NASA Response to GAO Recommendation 4: Concur. As stated in our 
response to the first and third recommendations, the NASA enterprise 
architecture policy guidance is contained in NPG 2800.1, Managing 
Information Technology. NPG 2800.1 is currently in revision; the next 
version is due for release in the first quarter of FY 2004.

The NASA Enterprise Architecture is a strategic tool linking NASA's 
mission, business, and Information Technology (IT) strategies. The 
architecture provides the fundamental methodology and framework for 
defining how NASA's IT will be implemented and managed. Key elements of 
the architecture include a description of the current "As-Is" state and 
a projection of the "To-Be" state, a clear governance model, a Capital 
Planning and Investment Control Process, and Information Technology 
service delivery models. NASA has adopted the GAO architecture maturity 
framework and is currently interviewing potential vendors to provide an 
annual Independent Verification and Validation (IV&V) of the NASA 
Enterprise Architecture and annual assessments on NASA's progress 
against the GAO architecture maturity framework.

The NASA Enterprise Architecture is a central element in the Agency's 
cohesive strategy for managing the Agency's IT infrastructure as an 
integrated architecture that supports the One NASA strategy and the 
Agency's strategic plan, core missions and implementing strategies. The 
Enterprise Architecture provides a customer focus to the provisioning 
of common IT services across NASA. The NASA Enterprise Architecture 
will evolve, as required, to support enable effective and efficient 
integration with Federal E-Gov applications and the President's 
Management Agenda.

The NASA Enterprise Architecture provides the framework for NASA's 
information technology programs and projects. The information 
technology strategy provides both an overarching system of protection, 
and removes many of the current barriers to One NASA caused by the 
disparate set of systems that are in place today. The NASA Enterprise 
Architecture is decomposed into service elements, each of which 
integrates agency-level services while retaining appropriate local-
level operations. Through this approach, NASA can put into place the 
information systems and technologies that enable anywhere, anytime 
access to information and people, can gain more effective use of its IT 
investments, and create the environment necessary to meet NASA's 
mission objectives.

NASA has adopted the major elements of the Federal Enterprise 
Architecture and is supporting the ongoing development of the Federal 
Enterprise Architecture. As a part of the development of the revised 
NASA Enterprise Architecture document, NASA mapped all general purpose 
and a representative subset of mission specific IT investments to the 
Federal Enterprise Architecture reference models. NASA has also 
extended the Federal Enterprise Architecture reference models to 
capture the unique elements of NASA science and research and technology 
missions.

NASA's Information Resources Management Strategic Plan has been 
developed as a mechanism for documenting the NASA CIO's strategy for 
fulfilling these responsibilities, and to serve as a communication 
vehicle for sharing this strategy both internal and external to:

the Agency. The Information Resource Management Strategic Plan is a 
companion document to version 2.0 of the NASA Enterprise Architecture 
and serves as an overall roadmap that guides the Agency in using the 
NASA Enterprise Architecture as a framework for strengthening the 
management of NASA's information and technology resources through 
achievement of the Agency's strategic goals. The Information Resources 
Management Strategic Plan and the NASA Enterprise Architecture include 
the full spectrum of information resource management across the Agency, 
including business and administrative systems, mission specific 
systems, office automation, telecommunications, information technology 
infrastructure, security, and records management.

NASA recognizes that not only must there be alignment with the Agency's 
mission, program, and business needs, there must be alignment with 
governmentwide architectures and standards, as well as alignment with 
our strategic and industry partners. This broader alignment provides 
for greater interoperability, efficiencies, and quality of service. It 
is essential that NASA IT projects are planned and managed in a manner 
that integrates with mainstream Agency processes, including program/
project management and budget processes.

5. GAO Recommendation: The Administrator directs the architecture board 
and the CIO:

a. Establish a written and approved policy for IT investment compliance 
with the enterprise architecture.

b. Ensure that the enterprise architecture is an integral component of 
the IT investment management process.

c. Ensure that IT investments comply with the enterprise architecture.

d. Obtain Administrator approval of each enterprise architecture 
version. 

e. Measure and report enterprise architecture return on 
investment. 

f. Measure and report on enterprise architecture compliance.

NASA Response to GAO Recommendation 5: Concur. As written earlier in 
our responses to the first and third recommendations, the NASA 
enterprise architecture policy guidance is contained in NPG 2800.1, 
Managing Information Technology. NPG 2800.1 is currently in revision; 
the next version is due for release in the first quarter of 2004. NPG 
2800.1 and the revised Capital Planning and Investment Control Process, 
released on September 22, 2003, provide guidance for compliance with 
the NASA Enterprise Architecture and ensure that the NASA Enterprise 
Architecture is an integral component of the IT investment management 
process.

Within NASA, information technology has always been a critical enabling 
element of program development and management, as well as a pathway for 
improving business functions. Because IT is crucial to achieving NASA's 
strategic goals, IT projects must be aligned with the Agency's 
strategic direction and business plans in order to realize the value of 
each investment and take advantage of the opportunities that new 
information technologies promise. The Information Resources Management 
Strategic Plan directly supports the NASA Strategic Plan by clearly 
linking information resources management strategies to the NASA vision, 
mission, strategic goals, and implementing strategies.

The NASA Chief Information Officer (CIO) is responsible and accountable 
for developing and maintaining the NASA Enterprise Architecture. The 
NASA CIO has responsibility for ensuring that NASA's information assets 
are acquired and managed consistent with federal policies, procedures, 
and legislation and that the Agency's information resources management 
strategy and enterprise architecture are in alignment with NASA's 
vision, mission, and strategic goals. Based on these responsibilities, 
accountabilities and authority, the NASA CIO signs each version of the 
NASA Enterprise Architecture. Future versions will be routed to the 
NASA Administrator for approval before release.

The NASA CIO's Chief Technology Officer (Chief Enterprise Architect) 
has established enterprise architecture metrics for return on 
investment and compliance and will provide quarterly updates on the 
progress against the architecture plan in FY 2004 and semi-annual 
reports starting in FY 2005.

6. GAO Recommendation: The Administrator directs the architecture board 
in collaboration with the CIO, to:

a. Immediately map already implemented IFMP components to the agency's 
enterprise architecture.

b. Report to the IFM Program Executive Officer any instances of 
misalignment, the associated risks and proposed corrective actions.

NASA Response to GAO Recommendation 6: Concur. The alignment between 
the current and planned IFMP architecture and the current NASA 
Enterprise Architecture was validated as an integral phase of the 
development of version 2.0 of the NASA Enterprise Architecture. The 
IFMP Business Architecture is an integral element of the NASA 
Enterprise Architecture that was submitted to OMB by the NASA CIO on 
September 22, 2003. The NASA Enterprise Architecture Working Group will 
continue to work closely with the NASA CIO, the NASA CIO's Chief 
Technology Officer (Chief Enterprise Architect) and the IFM Program 
Executive Officer.

7. GAO Recommendation: The Administrator directs the IFM Program 
Executive Officer to appropriately limit acquisition and implementation 
activities until the agency ensures alignment of the program's plans 
with the initial release and subsequent versions of the enterprise 
architecture:

NASA Response to GAO Recommendation 7: Concur. At this time, there are 
no outstanding alignment issues between the current and planned IFMP 
architecture and the current NASA Enterprise Architecture. The IFMP 
Business Architecture has been evaluated as a part of the development 
of the current release of the overall NASA Enterprise Architecture. The 
IFMP Business Architecture is an integrated element included in the 
NASA Enterprise Architecture that was submitted to OMB by the NASA CIO 
on September 22, 2003. NASA concurs that alignment of the IFMP program 
plans and the NASA Enterprise Architecture is critical to the success 
of the IFM Program. As a part of NASA's continuing enterprise 
architecture refinement process, and the IFM Program Management Plan, 
NASA has validated the alignment of IFMP with the NASA Enterprise 
Architecture. The NASA Enterprise Architecture Working Group will 
continue to work closely with the NASA CIO, the NASA CIO's Chief 
Technology Officer (Chief Enterprise Architect) and the IFM Program 
Executive Officer.

GAO Recommendation: The Administrator directs the IFM Program Executive 
Officer to develop corrective action plans, as appropriate, that 
include specific milestones, cost estimates, and detailed actions to be 
taken to align the program with the enterprise architecture:

NASA Response to GAO Recommendation 8: Concur. Although at this time, 
there are no alignment issues between the current and planned IFMP 
architecture and the NASA Enterprise Architecture. NASA concurs that 
ongoing alignment of the IFMP program plans and the NASA Enterprise 
Architecture is critical to the success of the IFMP Program. As part of 
NASA's continuing enterprise architecture refinement process and the 
IFM Program Management Plan, NASA will continue to validate, on a 
quarterly basis, the alignment of IFMP with the NASA Enterprise 
Architecture. If, in the future, any misalignment should occur the IFM 
Program Executive Officer will direct the IFM Program to develop 
corrective action plans which would include, as appropriate, specific 
milestones, cost estimates, and detailed actions to be taken to align 
the program with the NASA Enterprise Architecture. The NASA Enterprise 
Architecture Working Group will continue to work closely with the NASA 
CIO, the NASA CIO's Chief Technology Officer (Chief Enterprise 
Architect) and the IFM Program Executive Officer.

[End of section]

Appendix V: GAO Contacts and Staff Acknowledgments:

GAO Contact:

Cynthia Jackson, (202) 512-5086:

Acknowledgments:

Staff making key contributions to this report were Sophia Harrison, Anh 
Le, Randolph Tekeley, William Wadsworth, and Lillian Whren.

(310256):

FOOTNOTES

[1] In 1990, we began a special effort to review and report on the 
federal program areas that our work had identified as high risk because 
of vulnerabilities to waste, fraud, abuse, and mismanagement. We first 
issued our High-Risk Series in December 1992 and have since continued 
to include NASA's contract management as an area of high risk. See U.S. 
General Accounting Office, High-Risk Series: NASA Contract Management, 
GAO/HR-93-11 (Washington, D.C.: December 1992) and High-Risk Series: 
NASA Contract Management, GAO-03-119 (Washington, D.C.: January 2003).

[2] An enterprise architecture is a blueprint that defines, both in 
logical terms (including integrated functions, applications, systems, 
users, work locations, and information needs and flows) and in 
technical terms (including hardware, software, data, communications, 
and security), how an organization's information technology systems 
operate today, how they are to operate in the future, and a road map 
for the transition. 

[3] U.S. General Accounting Office, Business Modernization: 
Improvements Needed in Management of NASA's Integrated Financial 
Management Program, GAO-03-507 (Washington, D.C.: Apr. 30, 2003). 

[4] U.S. General Accounting Office, Business Modernization: NASA's 
Integrated Financial Management Program Does Not Fully Address Agency's 
External Reporting Issues, GAO-04-151 (Washington, D.C.: Nov. 21, 2003) 
and Business Modernization: Disciplined Processes Needed to Better 
Manage NASA's Integrated Financial Management Program, GAO-04-118 
(Washington, D.C.: Nov. 21, 2003).

[5] U.S. General Accounting Office, Business Modernization: NASA 
Challenges in Managing Its Integrated Financial Management Program, 
GAO-04-255 (Washington, D.C.: Nov. 21, 2003).

[6] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 1.0 (2002); 
Chief Information Officer Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); and Office of 
Management and Budget, Management of Federal Information Resources, 
Circular No. A-130 (Nov. 28, 2000). 

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

[8] NASA has acquired and implemented five of the nine planned major 
components of IFMP and is in the process of implementing the sixth 
component.

[9] GAO-04-118. 

[10] National Aeronautics and Space Administration Office of Inspector 
General, Integrated Financial Management Program Core Financial Module 
Conversion to Full Cost Accounting, IG-03-015 (Washington, D.C.: May 
30, 2003).

[11] U.S. General Accounting Office, Major Management Challenges and 
Program Risks: National Aeronautics and Space Administration, GAO-03-
114 (Washington, D.C.: January 2003).

[12] NASA spends 90 percent or $12.7 billion of its annual budget for 
aeronautical and space-related projects on the work performed by its 
contractors.

[13] GAO-04-118.

[14] U.S. General Accounting Office, Business Modernization: 
Improvements Needed in Management of NASA's Integrated Financial 
Management Program, GAO-03-507 (Washington, D.C.: Apr. 30, 2003).

[15] National Aeronautics and Space Administration Office of Inspector 
General, Integrated Financial Management Program Core Financial Module 
Conversion to Full Cost Accounting, IG-03-015 (Washington, D.C.: May 
30, 2003).

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

[17] See, for example, U.S. General Accounting Office, DOD Business 
Systems Modernization: Improvements to Enterprise Architecture 
Development and Implementation Efforts Needed, GAO-03-458 (Washington, 
D.C.: Feb. 28, 2003); Information Technology: DLA Should Strengthen 
Business Systems Modernization Architecture and Investment Activities, 
GAO-01-631 (Washington, D.C.: June 29, 2001); and Information 
Technology: INS Needs to Better Manage the Development of Its 
Enterprise Architecture, AIMD-00-212 (Washington, D.C.: Aug. 1, 2000).

[18] OMB has identified 24 e-government initiatives that are expected 
to support the goal of the President's management agenda and ultimately 
provide improved government services to citizens, businesses, and other 
levels of government. Examples of these initiatives include: (1) e-
Grants, which will provide a single site intended to streamline the 
federal grants management process and allow customers of federal grants 
to find and apply for grants; (2) e-Payroll, which will simplify and 
integrate payroll systems across the federal government; and (3) e-
Travel, which will streamline the government's travel administration by 
creating a governmentwide Web-based travel management service.

[19] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 1.0 (2002); 
Chief Information Officer Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); Office of 
Management and Budget, Management of Federal Information Resources, 
Circular No. A-130 (Nov. 28, 2000); M.A. Cook, Building Enterprise 
Information Architectures: Reengineering Information Systems (Prentice 
Hall Inc.: 1996); and National Institute of Standards and Technology, 
Information Management Directions: The Integration Challenge, Special 
Publication 500-167 (September 1989).

[20] The architecture does not satisfy any aspects of this key 
architectural element.

[21] The architecture partially satisfies some aspects of this key 
architectural element but does not satisfy at least one significant 
aspect.

[22] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 1.0 (2002); 
Chief Information Officer Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); Office of 
Management and Budget, Management of Federal Information Resources, 
Circular No. A-130 (Nov. 28, 2000); M.A. Cook, Building Enterprise 
Information Architectures: Reengineering Information Systems (Prentice 
Hall Inc.: 1996); and National Institute of Standards and Technology, 
Information Management Directions: The Integration Challenge, Special 
Publication 500-167 (September 1989).

[23] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 1.0 (2002); 
Chief Information Officer Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); and Office of 
Management and Budget, Management of Federal Information Resources, 
Circular No. A-130 (Nov. 28, 2000).

[24] National Aeronautics and Space Administration Office of Inspector 
General, Integrated Financial Management Program Core Financial Module 
Conversion to Full Cost Accounting, IG-03-015 (Washington, D.C.: May 
30, 2003).

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

[26] We reviewed technology architectures and an enterprise 
architecture for the IFMP core financial module. 

[27] See, for example, Office of Management and Budget, Federal 
Enterprise Architecture Business Reference Model, Version 1.0 (2002); 
Chief Information Officers Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001); Office of 
Management and Budget, Management of Federal Information Resources, 
Circular No. A-130 (Nov. 28, 2000); M.A. Cook, Building Enterprise 
Information Architectures: Reengineering Information Systems (Prentice 
Hall Inc.: 1996); and National Institute of Standards and Technology, 
Information Management Directions: The Integration Challenge, Special 
Publication 500-167 (September 1989).

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

[29] IBM, NASA Enterprise Architecture: Roadmap for Building and 
Sustaining Business Value Through an Integrated EA, Sept. 6, 2002.

GAO's Mission:

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

Obtaining Copies of GAO Reports and Testimony:

The fastest and easiest way to obtain copies of GAO documents at no 
cost is through the Internet. GAO's Web site ( www.gao.gov ) contains 
abstracts and full-text 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, Waste, and Abuse in Federal Programs:

Contact:

Web site: www.gao.gov/fraudnet/fraudnet.htm E-mail: fraudnet@gao.gov

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

Public Affairs:

Jeff Nelligan, managing director, NelliganJ@gao.gov (202) 512-4800 U.S.

General Accounting Office, 441 G Street NW, Room 7149 Washington, D.C.

20548: