This is the accessible text file for GAO report number GAO-03-1018 
entitled 'DOD Business Systems Modernization: Important Progress Made 
to Develop Business Enterprise Architecture, but Much Work Remains' 
which was released on September 19, 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:

September 2003:

DOD BUSINESS SYSTEMS MODERNIZATION:

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

[Hyperlink, http://www.gao.gov/cgi-bin/getrpt?GAO-03-1018] GAO-03-
1018:

GAO Highlights:

Highlights of GAO-03-1018, a report to congressional committees

Why GAO Did This Study:

The National Defense Authorization Act for Fiscal Year 2003 directed 
the Department of Defense (DOD) to develop an enterprise architecture 
and a transition plan that meets certain requirements. The act also 
directed DOD to have a process for controlling its system investments. 
As required by the act, GAO assessed DODís actions to comply with the 
actís requirements and recently issued a report to congressional 
defense committees. This report provides further details of GAOís 
assessment results regarding (1) the extent to which DODís actions 
complied with the requirements of the act and (2) DODís plans for 
further development and implementation of its architecture. 

What GAO Found:

DOD has expended tremendous effort and resources and made important 
progress in complying with the actís requirements aimed at developing 
and effectively implementing a well-defined business enterprise 
architecture. Further, DODís initial version of its architecture 
provides a foundation from which to build and ultimately produce a 
well-defined architecture. For example, the ďAs IsĒ environment 
includes an inventory of about 2,300 existing systems and their 
characteristics that support DODís current business operations; and 
the ďTo BeĒ environment addresses, to at least some degree, how DOD 
intends to operate in the future, what information will be needed to 
support these future operations, and what technology standards should 
govern the design of future systems. Further, DOD has established some 
of the architecture management capabilities advocated by best 
practices and federal guidance, such as having a program office, 
designating a chief architect, and using an architecture development 
methodology and automated tool.

At the same time, DODís initial architecture does not yet adequately 
address the actís requirements and other relevant architectural 
requirements governing the scope and content. For example, critical 
federal requirements governing the ďTo BeĒ architecture, such as 
federal accounting requirements for recording revenue, are not 
included in the initial architecture. Other items not included are 

* descriptions of the current business operations in terms of entities 
and people who perform the functions, processes, and activities and 
the locations where these are performed; 
* descriptions of the systems to be developed or acquired to support 
future business operations; and
* time frames for phasing out existing systems. 

Furthermore, DOD has not yet implemented an effective investment 
management process for selecting and controlling ongoing and planned 
business system investments. Until it does, DOD remains at risk of 
spending billions of dollars on duplicative, stove-piped, 
nonintegrated systems that do not optimize mission performance and 
accountability and, therefore, do not support the departmentís 
business transformation goals. 

Overall, our findings indicate that DOD has taken positive first 
steps, but much remains to be accomplished before DOD will have the 
kind of blueprint and associated investment controls to successfully 
modernize its business operations and supporting systems. According to 
program officials and the initial version of the transition plan, DOD 
intends to extend and evolve the architecture to include the missing 
scope and detail; however, it has not yet defined specific plans 
outlining how this will be accomplished.

What GAO Recommends:

To further assist DOD in its efforts to effectively develop and 
implement an enterprise architecture and to guide and constrain its 
business system investments, GAO is making recommendations to the 
Secretary of Defense aimed at improving DODís plans for developing the 
next version of the architecture and implementing the institutional 
means for selecting and controlling both planned and ongoing business 
system investments. DOD concurred with 9 of our 10 recommendations, 
partially concurred with the remaining one, and described completed, 
ongoing, or planned actions to address them.

www.gao.gov/cgi-bin/getrpt?GAO-03-1018 
To view the full product, including the scope and methodology, click 
on the link above. For more information, contact Gregory Kutz, (202) 
512-9095 (kutzg@gao.gov) or Randolph Hite, (202) 512-3439 
(hiter@gao.gov).

[End of section]

Contents:

Letter: 

Results in Brief: 

Background: 

DOD Has Taken Positive First Steps in Complying with Enterprise 
Architecture Legislative Requirements, but Much Remains to be 
Accomplished: 

DOD's Plans for Evolving and Extending Its Enterprise Architecture and 
for Improving Business System Investment Decision Making Are Unclear: 

Conclusions: 

Recommendations: 

Agency Comments and Our Evaluation: 

Appendixes:

Appendix I: SEC. 1004. [of Public Law 107-314] Development and 
Implementation of Financial Management Enterprise Architecture: 

Appendix II: Scope and Methodology: 

Appendix III: Status of Prior Recommendations on DOD's Business 
Enterprise Architecture: 

Appendix IV: Comments from the Department of Defense: 

Appendix V: GAO Contacts and Staff Acknowledgments: 

GAO Contacts: 

Acknowledgments: 

Tables: 

Table 1: Interrelationship Between Domains and Business Process Areas: 

Table 2: Summary of GAO's Enterprise Architecture (EA) Maturity 
Framework Stages: 

Table 3: Assessment of DOD's Enterprise Architecture Efforts Against 
GAO's Enterprise Architecture Maturity Framework: 

Table 4: Summary of GAO Analysis of JFMIP Requirements: 

Table 5: Detailed Analysis of the Extent to Which DOD's "As Is" 
Architecture Satisfies Key Elements: 

Table 6: Detailed Analysis of the Extent to Which DOD's "To Be" 
Architecture Satisfies Key Elements: 

Table 7: Detailed Analysis of the Extent to Which DOD's Transition Plan 
Satisfies Key Architectural Elements: 

Figures: 

Figure 1: Interdependent C4ISR Views: 

Figure 2: Summary of Extent to Which Version 1.0 of DOD's Enterprise 
Architecture Satisfies Key Elements Governing Architectural Content: 

Letter September 19, 2003:

Congressional Committees:

Our research of successful public and private sector organizations 
shows that attempting a large-scale systems modernization program 
without having a well-defined modernization blueprint--commonly called 
an enterprise architecture--and effective investment management 
controls, results in systems that are duplicative, are not well-
integrated, are unnecessarily costly to maintain and interface, and do 
not effectively optimize mission performance. Accordingly, in May 
2001[Footnote 1] we recommended that the Department of Defense (DOD) 
develop an enterprise architecture to guide and constrain its almost 
$20 billion annual investment in business systems and establish the 
investment controls needed to implement this architecture. In July 
2001, DOD initiated a program to, among other things, address our 
recommendations, and began developing a DOD-wide business enterprise 
architecture (BEA) in April 2002. This effort is an essential part of 
the Secretary of Defense's broad initiative to "transform the way the 
department works and what it works on.":

The National Defense Authorization Act for Fiscal Year 2003[Footnote 2] 
required DOD to develop by May 1, 2003, a financial management 
enterprise architecture[Footnote 3] and a transition plan for 
implementing the architecture that meet certain requirements. The act 
also requires DOD to control expenditures for financial system 
improvements while the architecture and transition plan are being 
developed and after they are completed. The act states that the 
enterprise architecture shall describe an information infrastructure 
that, at a minimum, would enable DOD to achieve certain capabilities, 
such as complying with all federal accounting, financial management, 
and reporting requirements. The act also requires development of a 
transition plan for implementing the enterprise architecture that 
includes, among other things, a schedule for phasing out existing 
systems that will not become part of the "To Be" environment. Finally, 
before the architecture and transition plan are approved, the act 
requires DOD to review proposed obligations of funds in amounts 
exceeding $1 million for financial system improvements to determine if 
they meet specific conditions called for in the act. Once the 
architecture and transition plan are approved, the act requires DOD to 
ensure that obligations exceeding $1 million for financial system 
investments are consistent with the architecture and the transition 
plan.

The act also directs us to submit to congressional defense committees, 
within 60 days of DOD's approval of its enterprise architecture and its 
transition plan, an assessment of DOD's actions taken to comply with 
these requirements. (See app. I for a copy of section 1004 of the act.) 
We recently issued a report to satisfy this requirement.[Footnote 4] 
This report provides specific details on our assessment results 
regarding (1) the extent to which DOD's actions complied with the 
requirements of the act and (2) DOD's plans for further development and 
implementation of its enterprise architecture. It also makes 
recommendations to the Secretary of Defense for improving DOD's 
architecture development, maintenance, and implementation efforts, 
including restricting investments in systems until the architecture is 
sufficiently defined and effective controls are in place for ensuring 
new investments are aligned with it.

We performed our work from March 2003 through June 2003 in accordance 
with U.S. generally accepted government auditing standards. Details on 
our scope and methodology are included in appendix II. We requested 
comments on a draft of this report from the Secretary of Defense or his 
designee. Written comments from the Under Secretary of Defense 
(Comptroller) are addressed in the "Agency Comments and Our Evaluation" 
section of this report and are reprinted in appendix IV.

Results in Brief:

As we reported in February 2003,[Footnote 5] DOD undertook a 
challenging and ambitious task--to develop within 1 year a 
departmentwide architecture for modernizing its current financial and 
business operations and systems. Thus far, DOD has expended tremendous 
effort and resources and made important progress in complying with the 
legislative requirements aimed at developing and effectively 
implementing a well-defined enterprise architecture. Concerning 
progress, the department has established some of the architecture 
management capabilities advocated by best practices and federal 
guidance,[Footnote 6] such as having a program office, designating a 
chief architect, and using an architecture development methodology and 
automated tool. Further, DOD's initial version of its BEA provides a 
foundation from which to build and ultimately produce a well-defined 
business enterprise architecture. For example, the "As Is" descriptions 
include an inventory of about 2,300 systems in operation or under 
development, and their characteristics, that support DOD's current 
business operations. The "To Be" descriptions address, to at least some 
degree, how DOD intends to operate in the future, what information will 
be needed to support these future operations, and what technology 
standards should govern the design of future systems.

At the same time, the initial version does not yet adequately address 
the act's requirements and other relevant architectural 
requirements.[Footnote 7] For example,

* While DOD has incorporated many relevant external requirements from 
152 federal sources in developing its "To Be" architecture products, 
critical federal requirements governing the "To Be" architecture, such 
as federal accounting requirements for recording revenue, are not 
included. As a result, the architecture's descriptions of certain 
business processes, such as those associated with revenue accounting 
and reporting, which include over $70 billion earned annually by 
working capital fund activities, are not complete.

* The "As Is" environment provides little descriptive content and does 
not satisfy 90 percent of the architectural elements required by 
relevant guidance, such as descriptions of the current business 
operations in terms of the entities/people who perform the functions, 
processes, and activities, and the locations where the functions, 
processes, and activities are performed. As a result, DOD does not have 
a sufficiently described picture of its current environment to permit 
development of a meaningful and useful transition plan.

* The "To Be" architecture does not provide sufficient descriptive 
content related to future business operations and supporting technology 
to permit effective acquisition and implementation of system solutions 
and associated operational change. For example, it does not include 
descriptions of the actual systems to be developed or acquired to 
support future business operations and the physical infrastructure 
(e.g., hardware and software) that will be needed to support the 
business systems. As a result, the "To Be" environment lacks the 
details needed to provide DOD with a common vision and frame of 
reference for defining a transition plan to guide and constrain capital 
investments, and thus to effectively leverage technology to orchestrate 
logical, systematic change and optimize enterprisewide mission 
performance.

* The transition plan does not possess the attributes needed to provide 
a temporal roadmap for moving from the "As Is" to the "To Be" 
environment and is basically a plan to develop a transition plan. For 
example, such information as time frames for phasing out existing 
systems within DOD's current inventory of about 2,300 systems, and 
resource requirements for implementing the "To Be" architecture, are 
not part of the transition plan. As a result, DOD does not yet have a 
meaningful and reliable basis for managing the disposition of its 
existing inventory of about 2,300 systems or for sequencing the 
introduction of modernized business operations and supporting systems.

Moreover, DOD has not yet defined and implemented an effective approach 
to select and control business systems investments[Footnote 8] for 
obligations exceeding $1 million while the architecture is being 
developed and after it is completed. Since enactment of the act, as of 
June 6, 2003, DOD had approved one business system improvement for $10 
million that met this $1 million threshold and was currently reviewing 
four others. Our analysis of DOD's fiscal years 2003 and 2004 
information technology (IT) budget requests shows that over 200 
business systems in each year's budget, totaling about $4 billion per 
year, could involve obligations of funds that meet the $1 million 
threshold. This indicates that the majority of the billions of dollars 
that DOD invests in business system improvements annually have not been 
subject to the scrutiny of the DOD Comptroller now called for in the 
act. Overall, our findings indicate that DOD has taken positive first 
steps, but much remains to be accomplished before DOD will have the 
kind of blueprint and associated investment controls needed to 
successfully modernize its financial management operations and 
supporting business systems.

DOD's position is that, to varying degrees, the initial version of its 
architecture fully satisfies the act's requirements, but it also 
recognizes that the architecture needs to be expanded and extended to 
provide a sufficient basis for guiding and constraining investment 
decisions. DOD's position is also that it has taken steps to implement 
the act's requirements regarding approving system investments, but that 
it needs to do more to effectively select and control business system 
investments. DOD attributes the current state of its architecture and 
investment management processes to the limited time it has had to 
define and implement each, in part because it was overly optimistic in 
estimating what it could deliver by May 1, 2003. Until DOD develops and 
provides for effective implementation of a well-defined enterprise 
architecture, its ability to modernize its business and systems 
environments in a way that minimizes risk and maximizes return on 
investment will be severely hindered.

According to program officials and the initial version of the 
transition plan, DOD intends to extend and evolve the architecture to 
include the missing scope and detail. However, it has not defined 
specific plans outlining how this will be accomplished. Rather, DOD's 
current plan is to develop a strategy for producing the next version of 
its architecture, and managing ongoing and planned investments. Among 
other things, this strategy is to provide for:

* determining the resources needed to further develop the architecture;

* developing a methodology for integrating the architecture with other 
internal and external architectures;

* establishing an approach for maintaining its existing systems 
inventory; and:

* evaluating the architecture for completeness, accuracy, and 
integration of end-to-end business processes and system functions.

In addition, DOD program documentation provides for initiating pilot 
projects in the near term that are to demonstrate and implement a 
portion of the architecture and be usable across the department. 
However, DOD officials stated that the pilot projects are intended to 
validate departmentwide business processes and not to implement 
production systems. Because of these differing views of what the pilot 
projects are intended to achieve, the purpose and scope of these 
projects remain unclear, and specific projects have yet to be selected.

To assist DOD, we are making recommendations to the Secretary of 
Defense aimed at improving its plans for developing the next version of 
the architecture and implementing the institutional means for selecting 
and controlling both planned and ongoing system investments. DOD 
concurred with 9 of our 10 recommendations, partially concurred with 
the remaining one, and described actions recently completed, ongoing, 
or planned to implement them.

Background:

DOD is one of the largest and most complex organizations in the world. 
In fiscal year 2002, DOD reported that its operations involve about 
$700 billion in assets, nearly $1.5 trillion in liabilities, 
approximately 3.3 million military and civilian personnel, and 
disbursements of over $346 billion. Moreover, execution of these 
operations spans a wide range of defense organizations, including the 
military services and their respective major commands and functional 
activities, numerous large defense agencies and field activities, and 
various combatant and joint operational commands that are responsible 
for military operations for specific geographic regions or theaters of 
operations. To execute these military operations, the department 
performs an assortment of interrelated and interdependent business 
functions, including logistics management, procurement, healthcare 
management, and financial management.

The department's pervasive problems in performing these business 
functions are well chronicled by the DOD Inspector General, the 
military service audit agencies, and us. Of the 25 areas in the federal 
government that we have designated as high risk, 6 are DOD program 
areas (i.e., systems modernization management, financial management, 
contract management, inventory management, support infrastructure 
management, and weapon systems acquisition), and DOD shares 
responsibility for 3 of the governmentwide high-risk areas (i.e., 
strategic human capital management, protecting information systems and 
critical infrastructures, and federal real property).[Footnote 9] DOD's 
problems in each of these areas hinder the efficiency of operations, 
and leave the department vulnerable to fraud, waste, and abuse.

To support its business functions, DOD reports that it currently relies 
on about 2,300 systems, including accounting, acquisition, logistics, 
and personnel. As we have previously reported,[Footnote 10] this 
environment was not designed to be, but rather has evolved into, an 
overly complex, and error-prone IT environment, including (1) little 
standardization across DOD, (2) multiple systems performing the same 
tasks, (3) the same data stored in multiple systems, and (4) manual 
data entry into multiple systems. For fiscal year 2003, DOD requested 
approximately $26 billion in IT funding to support a wide range of 
military operations as well as DOD business system operations. 
Approximately $18 billion--nearly $5.2 billion for business systems and 
$12.8 billion primarily for business systems infrastructure--relates to 
the operation, maintenance, and modernization of DOD's business 
systems. The remaining $8 billion relates primarily to command and 
control systems, including the infrastructure to support these systems.

One of the seven key elements we have reported[Footnote 11] as 
necessary to successfully execute the department's business systems 
modernization program is establishing and implementing an enterprise 
architecture. Subsequently, in its fiscal year 2002 Performance and 
Accountability Report, DOD acknowledged that deficiencies in its 
systems and business processes hindered the department's ability to 
collect and report financial and performance information that is 
accurate, reliable, and timely. The report noted that to address its 
systemic problems and assist in the transformation of the department's 
business operations, the department had undertaken the development and 
implementation of a business enterprise architecture, or modernization 
blueprint. Table 1 shows the scope of DOD's business operations, 
including business domains owners, and related business process areas 
and supporting functions.

Table 1: Interrelationship Between Domains and Business Process Areas:

Domain: Acquisition/Procurement; Domain owner: Under Secretary of 
Defense (Acquisition, Technology and Logistics); Business process 
areas: Procurement and Acquisition; Business process functions: 
Identifying a need and procuring and acquiring goods and services to 
satisfy the need (includes managing contracts and purchase card 
programs).

Domain: Finance, Accounting Operations, and Financial Management; 
Domain owner: Under Secretary of Defense (Comptroller/Chief Financial 
Officer); Business process areas: Accounting; Collection, Accounts 
Receivable, and Cash Management; Payables and Disbursing; 
Financial and Management Reporting; Business process functions: 
Identifying, measuring, recording, and communicating economic 
information about an organization (includes developing and maintaining 
DOD standard accounting structure, policies, and cost accounting); 
Recording, tracking, managing, monitoring, liquidating, and collecting 
amounts due to DOD (includes reconciling fund balance with Treasury); 
Receiving payment requests, determining payment due dates, and 
issuing payment; Providing accurate, reliable, and timely financial 
and management information.

Domain: Human Resource Management; Domain owner: Under Secretary of 
Defense (Personnel and Readiness); Business process areas: Human 
Resource Management; Business process functions: Facilitating entry to 
the organization, developing and managing careers, managing benefits 
and pay, executing policies and procedures, and managing employee 
information.

Domain: Logistics; Domain owner: Under Secretary of Defense 
(Acquisition, Technology and Logistics); Business process areas: 
Logistics; Business process functions: Planning, controlling, and 
carrying out the efficient and effective movement and maintenance of 
forces (includes inventory and personal property management).

Domain: Strategic Planning and Budgeting; Domain owner: Under Secretary 
of Defense (Comptroller/Chief Financial Officer); Business process 
areas: Strategic Planning and Budgeting; Business process functions: 
Strategic planning, developing the programs and the budget, and 
executing the budget.

Domain: Installations and Environment; Domain owner: Under Secretary of 
Defense (Acquisition, Technology and Logistics); Business process 
areas: Real Property and Environmental Liabilities; Business process 
functions: Managing all real property and environmental controls.

Domain: Technical Infrastructure; Domain owner: Assistant Secretary of 
Defense (Networks and Information Integration)/Chief Information 
Officer[A]; Business process areas: All of the above; Business process 
functions: Providing foundation for enterprise data management, 
reporting, enterprise and technical services, and standards and policy 
(includes information assurance).

Source: GAO analysis of DOD data.

[A] Formerly known as Assistant Secretary of Defense (Command, Control, 
Communications and Intelligence)/Chief Information Officer.

[End of table]

Enterprise Architecture Is Critical to DOD's Ability to Improve Its 
Business Functions:

Effective use of enterprise architectures is a trademark of successful 
public and private organizations. For a decade, we have promoted the 
use of architectures, 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 also have recognized the importance 
of an architecture-centric approach to modernization. For example, the 
Clinger-Cohen Act of 1996[Footnote 12] mandates that an agency's CIO 
develop, maintain, and facilitate the implementation of an architecture 
within the agency and that the agency's decisions to invest in IT 
satisfy specified criteria and take into account the agency's business 
processes. Further, OMB has issued guidance[Footnote 13] that, among 
other things, requires system investments to be consistent with these 
architectures.

What Is an Enterprise Architecture?

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 roadmap 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 concept of enterprise architectures dates back to the mid-1980s. At 
that time, John Zachman, widely recognized as a leader in the field of 
enterprise architecture, identified the need to use a logical 
construction blueprint (i.e., an architecture) for defining and 
controlling the integration of systems and their components.[Footnote 
14] Accordingly, Zachman developed a structure or "framework" for 
defining and capturing an architecture. In his work, Zachman drew 
parallels to the field of classical architecture and later to the 
aircraft manufacturing industry, in which different work products 
(e.g., architect plans, contractor plans, shop plans, and bills of 
lading) represent different views of the planned building or aircraft. 
Similarly, Zachman's framework identified the kinds of work products 
needed for people to understand and thus build a given system or 
entity. This framework provides for six windows from which to view the 
enterprise, which Zachman terms "perspectives" on how a given entity 
operates: those of (1) the strategic planner, (2) the system user, 
(3) the system designer, (4) the system developer, (5) the 
subcontractor, and (6) the system itself. Zachman also proposed six 
abstractions or models associated with each of these perspectives: 
these models cover (1) how the entity operates, (2) what the entity 
uses to operate, (3) where the entity operates, (4) who operates the 
entity, (5) when entity operations occur, and (6) why the entity 
operates. Zachman's framework provides a way to identify and describe 
an entity's existing and planned component parts and the parts' 
relationships before one begins the costly and time-consuming efforts 
associated with developing or transforming the entity.

Since Zachman introduced his framework, a number of other frameworks 
have been proposed. In February 1998, DOD directed its components to 
use its Command, Control, Communications, Computers, Intelligence, 
Surveillance, and Reconnaissance (C4ISR) Architecture Framework, 
Version 2.0. The C4ISR architecture framework defines the type and 
content of architectural artifacts, as well as the relationships among 
artifacts, that are needed to produce a useful enterprise architecture. 
Briefly, the framework decomposes an enterprise architecture into three 
primary views (windows into how the enterprise operates): the 
operational, systems, and technical views. According to DOD, the three 
interdependent views are needed to ensure that IT systems are developed 
and implemented in an interoperable and cost-effective manner. (See 
fig. 1 for an illustration of the three views.):

Figure 1: Interdependent C4ISR Views:

[See PDF for image]

[End of figure]

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 type of data and information that support program 
and business line operations, and the relationships among these types.

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

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

These post-Zachman 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 both for the enterprise's "As Is" and "To Be" 
environments, 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 so as 
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 15]

Subsection 1004(b) of the act (see app. I) also defines elements 
required of DOD's enterprise architecture that are consistent with the 
above mentioned enterprise architecture guidance and requirements. 
Specifically, DOD's financial management enterprise architecture (its 
BEA) must define an information infrastructure that would enable DOD to 
meet certain requirements and it must include policies, procedures, 
data standards, and system interface requirements applicable uniformly 
throughout DOD.

Prior Reviews of DOD's Enterprise Architecture Efforts Have Identified 
Challenges and Weaknesses:

For the last 2 years, GAO has addressed the need for and reviewed DOD's 
efforts to develop an enterprise architecture for modernizing its 
business operations and systems and made recommendations to assist DOD 
in successfully developing the architecture and using it to gain 
control over its ongoing business system investments.

In particular, we reported in May 2001[Footnote 16] that the department 
had neither an enterprise architecture for its financial and financial-
related business operations, nor the management structure, processes, 
and controls in place to effectively develop and implement one. We also 
reported that the department planned to spend billions of dollars on 
new and modified business systems that would function independently 
from one another and outside the context of an enterprise architecture. 
We concluded that if the department continued down this path, it would 
only perpetuate its existing business operations and systems 
environment, which we described as duplicative, not interoperable, 
unnecessarily costly to maintain and interface, and not optimizing 
mission performance and accountability. We made eight recommendations 
to the Secretary of Defense aimed at providing the means for 
effectively developing and implementing an enterprise architecture. Of 
the eight recommendations, DOD has fully implemented one, partially 
implemented five, and has not yet implemented two.

In February 2003,[Footnote 17] we reported that while DOD is following 
some enterprise architecture and IT investment management processes and 
controls, it is not following others, in part, because it was focused 
on meeting an ambitious schedule. More specifically, with respect to 
developing the architecture, we reported that DOD had yet to (1) 
establish a governance structure and process controls needed to ensure 
ownership of and accountability for the architecture across the 
department, (2) clearly communicate to intended stakeholders its 
purpose, scope, and approach to developing the architecture, and (3) 
define and implement an independent quality assurance process.

We also reported in our February 2003 report that, while DOD had taken 
some initial steps aimed at improving its management of ongoing 
business system investments, DOD had yet to (1) establish an investment 
governance structure and process to align ongoing investments with its 
architectural goals and direction, (2) establish and apply common 
investment criteria to its ongoing IT system projects, and (3) conduct 
a comprehensive review of its ongoing IT investments to ensure they are 
consistent with architecture development efforts. We reiterated our 
earlier recommendations and made six new recommendations to the 
Secretary of Defense to assist DOD in successfully developing an 
enterprise architecture and using it to gain control over its ongoing 
business system investments. Of the six recommendations we made, DOD 
has partially implemented two but has not yet implemented the remaining 
four.

In March 2003,[Footnote 18] we reported on DOD's draft version of the 
BEA, dated February 7, 2003, and concluded that it did not include a 
number of items recommended by relevant architectural guidance and that 
DOD's plans would not fully satisfy the act's requirements. For 
example, the draft architecture did not include a "To Be" security 
view, which defines the security requirements, including relevant 
standards to be applied in implementing security policies, procedures, 
and controls. We did not make recommendations because this draft was a 
work in process that was changing daily. However, DOD officials agreed 
with our preliminary assessment of the architecture and stated that 
subsequent versions of the architecture would provide these missing 
details.

See appendix III for details on the status of all our recommendations, 
including our assessment of DOD's actions.

DOD Has Taken Positive First Steps in Complying with Enterprise 
Architecture Legislative Requirements, but Much Remains to be 
Accomplished:

DOD has made important progress in complying with the legislative 
requirements to develop and effectively implement a well-defined 
enterprise architecture. The department has (1) elected an incremental 
approach to developing its architecture, (2) adopted some of the 
architecture management capabilities advocated by best practices and 
federal guidance,[Footnote 19] such as designating a chief architect, 
and (3) developed initial versions of architecture products that 
provide a foundation upon which to build. Nevertheless, DOD's initial 
architecture lacks sufficient scope and content to fully satisfy 
legislative requirements, satisfy relevant architecture guidance, and 
make informed decisions about systems investments. Moreover, DOD has 
yet to implement an effective investment management process to select 
and control ongoing and planned business system investments.

DOD Is Following an Incremental Approach to Developing Its 
Architecture:

Our research and experience show that for major program investments, 
such as the development of an enterprise architecture, successful 
organizations approach product development in an incremental fashion, 
meaning that they initially develop a foundational product that is 
expanded and extended through a series of follow-on products that add 
more capability and value. In doing so, these organizations can 
effectively mitigate the enormous risk associated with trying to 
deliver a large and complex product that requires the execution of many 
activities over an extended period of time as a single monolithic 
product. In effect, this incremental approach permits a large 
undertaking to be broken into a series of smaller projects, or 
incremental versions, that can be better controlled to provide 
reasonable assurance that expectations are met.

For its enterprise architecture development program, we have recognized 
and told DOD that given its plans, capabilities, and status, it would 
not be able to produce and approve a complete version of its 
architecture by May 1, 2003. Accordingly, we advised DOD to adopt an 
incremental approach to developing and implementing its architecture 
and to represent its architecture product to stakeholders as an initial 
version and to define its plans for evolving and extending this initial 
version to satisfy the act and create a well-defined blueprint. 
Recognizing these obstacles, DOD has adopted an incremental approach. 
Specifically, DOD has designated its architecture as version 1.0 and 
has committed to building on this in producing subsequent versions. 
According to DOD, the next significant delivery of the BEA is currently 
planned for May 2004.

DOD Has Recently Adopted Some, but Not All Key Elements of Architecture 
Management Best Practices:

Effective process controls for managing architecture development, 
maintenance, and implementation are recognized hallmarks of successful 
public and private organizations. According to guidance published by 
the federal CIO Council,[Footnote 20]effective architecture management 
consists of a number of practices, conditions, and structures. In April 
2003, we published version 1.1 of our enterprise architecture 
management maturity framework, which arranges the core elements of the 
CIO Council's guidance into five hierarchical stages.[Footnote 21] The 
framework provides an explicit benchmark for gauging the effectiveness 
of architecture management and provides a roadmap for making 
improvements. Table 2 summarizes the framework's five stages of 
maturity.

Table 2: Summary of GAO's Enterprise Architecture (EA) Maturity 
Framework Stages:

Stage: Stage 1: Creating EA awareness; Description: 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 EA 
activity, these agencies' efforts are ad hoc and unstructured, lack 
institutional leadership and direction, and do not provide the 
management foundation necessary for successful EA development.

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

Stage: Stage 3: Developing the EA (includes all elements in stage 2); 
Description: 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 
EA products. The scope of the architecture has been defined to 
encompass the entire enterprise, whether organization-based or 
function-based.

Stage: Stage 4: Completing the EA (includes all elements in stage 3); 
Description: Organization has completed its EA products, meaning that 
the products have been approved by the EA 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 EA 
products. Additionally, evolution of the approved products is governed 
by a written EA maintenance policy approved by the head of the 
organization.

Stage: Stage 5: Leveraging the EA to manage change; (includes all 
elements in stage 4); Description: Organization has secured senior 
leadership approval of the EA 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 EA 
benefits or return on investment, and adjustments are continuously made 
to both the EA management process and the EA products.

Source: GAO.

[End of table]

The state of DOD's implementation of key enterprise architecture 
management practices, conditions, and structures currently places it at 
stage 1 of our maturity framework. Specifically, it has satisfied about 
80 percent of the core elements associated with building the enterprise 
architecture management foundation--stage 2 of our framework--but only 
about 41 percent (9 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.

With respect to stage 2 core elements, DOD has, for example, 
established a program office, assigned a chief architect, and selected 
a framework (C4ISR) and an automated tool (e.g., the System Architect 
by Popkin Software). However, the department has not satisfied two of 
the stage 2 core elements that are critical to effective enterprise 
architecture management. For example, a committee or group representing 
the enterprise has not yet been established to guide, direct, and 
approve the architecture. Instead, the current version of its 
architecture has been guided and directed by the Business Modernization 
and Systems Integration (BMSI) program office. Although the Secretary 
of Defense has established Financial Management Modernization Executive 
and Steering Committees for the enterprise architecture, which are made 
up of senior leaders from across the department, to provide program 
guidance, these committees are not accountable for approving the 
architecture. Instead, the responsibility of each committee is limited 
to providing guidance to the BMSI program office and advising the DOD 
Comptroller. However, DOD officials told us that the Executive 
Committee has approved the architecture; yet there were no minutes of 
the Executive Committee documenting this decision. Without an 
accountable corporate entity to lead 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 a 
departmentwide asset.

Further, DOD 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, DOD has been, and will continue to be, challenged in 
achieving departmentwide architecture commitment and support.

The department also has yet to implement numerous stage 4 and 5 core 
elements. For example, DOD has not (1) documented and approved a policy 
for architecture maintenance, (2) fully 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.

According to program officials, the department set overly optimistic 
expectations and time frames for its enterprise architecture program, 
which resulted in the need to establish architecture management process 
controls concurrent with developing architecture products. Until the 
department implements the core elements of our enterprise architecture 
management maturity framework, it is unlikely that it will be able to 
either produce and maintain a well-defined architecture or effectively 
implement what is produced.

Table 3 provides the results of our assessment of DOD's satisfaction of 
each of the core elements of our maturity framework.

Table 3: Assessment of DOD's Enterprise Architecture Efforts Against 
GAO's Enterprise Architecture Maturity Framework:

[See PDF for image]

Source: GAO analysis of DOD data.

[A] DOD defines the GIG as the globally interconnected, end-to-end set 
of information, capabilities, associated processes, and personnel for 
collecting, processing, storing, disseminating, and managing 
information on demand to warfighters, policy makers, and support 
personnel.

[B] GAO-03-458.

[End of table]

Initial Version of Architecture Provides a Foundation Upon Which to 
Build:

DOD has expended tremendous effort and resources and made important 
progress in complying with the legislative requirements aimed at 
developing and implementing a well-defined enterprise architecture. 
Further, DOD's initial version of its BEA provides a foundation from 
which to build and ultimately produce a well-defined business 
enterprise architecture. However, the initial architecture does not 
adequately address the act's requirements and other relevant 
architectural requirements.[Footnote 22] Specifically, the initial 
version of the architecture does not adequately describe the accounting 
and financial management requirements, and the "As Is" and "To Be" 
environments and the transition plan are not sufficiently complete to 
provide a basis for guiding and constraining investment decisions.

Architecture Does Not Adequately Address Federal Requirements and 
Accounting Standards:

DOD elicited and incorporated about 4,000 external requirements in its 
"To Be" architecture from 152 federal sources. Our review of 1,767 of 
the external requirements--specifically those that were elicited from 
the Joint Financial Management Improvement Program (JFMIP)[Footnote 
23]--identified 340 JFMIP requirements (about 19 percent) that were not 
adequately addressed in version 1.0 of the "To Be" architecture. 
Specifically, DOD (1) omitted some JFMIP requirements that are 
significant, (2) included some that are invalid, and (3) included some 
that are not appropriate to its business operations.

Mission requirements are one of the key bases for determining the scope 
and content for enterprise architectures. One source of requirements is 
the legal, regulatory, and other external constraints that define the 
environment within which an enterprise, such as DOD, must operate. If a 
given architecture is not developed to adequately recognize these 
constraints, and these missing constraints are significant, the 
architecture will not provide a sufficient frame of reference for 
informed decision making. The act specifies that the architecture 
should enable DOD to comply with all federal accounting, financial 
management, and reporting requirements. JFMIP requirements arise from 
various public laws, regulations, bulletins, circulars, federal 
accounting standards, and leading practices and are applicable 
government wide. Agencies must use these requirements, in addition to 
agency-unique mission requirements, in planning and implementing their 
financial management improvement projects.

DOD's "To Be" architecture omitted significant JFMIP requirements. For 
example, DOD's architecture did not include any relevant revenue 
requirements. These requirements are significant to DOD because they 
affect the accounting of and reporting for DOD's revenue, which include 
at least $70 billion earned annually by DOD working capital fund 
activities. Department and contractor officials agreed that these 
system requirements were either excluded or not adequately addressed 
and stated that a subsequent version of the architecture would include 
or modify the requirements. Table 4 summarizes the JFMIP requirements 
that we reviewed and the numbers of missing or incomplete requirements 
we identified.

Table 4: Summary of GAO Analysis of JFMIP Requirements:

JFMIP requirements: Revenue; Number of JFMIP: requirements: 220; Number 
of missing or incomplete requirements: 220; Percent of missing or 
incomplete requirements: 100.

JFMIP requirements: Acquisition; Number of JFMIP: requirements: 112; 
Number of missing or incomplete requirements: 10; Percent of missing or 
incomplete requirements: 9.

JFMIP requirements: Core Financial; Number of JFMIP: requirements: 430; 
Number of missing or incomplete requirements: 4; Percent of missing or 
incomplete requirements: 1.

JFMIP requirements: Human Resources and Payroll; Number of JFMIP: 
requirements: 203; Number of missing or incomplete requirements: 37; 
Percent of missing or incomplete requirements: 18.

JFMIP requirements: Managerial Cost Accounting; Number of JFMIP: 
requirements: 67; Number of missing or incomplete requirements: 30; 
Percent of missing or incomplete requirements: 45.

JFMIP requirements: Inventory; Number of JFMIP: requirements: 141; 
Number of missing or incomplete requirements: 7; Percent of missing or 
incomplete requirements: 5.

JFMIP requirements: Travel; Number of JFMIP: requirements: 166; Number 
of missing or incomplete requirements: 12; Percent of missing or 
incomplete requirements: 7.

JFMIP requirements: Property Management; Number of JFMIP: requirements: 
78; Number of missing or incomplete requirements: 0; Percent of missing 
or incomplete requirements: 0.

JFMIP requirements: Benefit; Number of JFMIP: requirements: 350; Number 
of missing or incomplete requirements: 20; Percent of missing or 
incomplete requirements: 6.

JFMIP requirements: Total; Number of JFMIP: requirements: 1,767; Number 
of missing or incomplete requirements: 340; Percent of missing or 
incomplete requirements: 19.

Source: GAO analysis of DOD data.

[End of table]

As another example, the "To Be" architecture did not include 
requirements governing accounting for and reporting of national defense 
plant, property, and equipment (PP&E)[Footnote 24] that became valid 
shortly before the architecture was approved. These requirements 
significantly affect the accounting of and reporting requirements for a 
reported 600,000 aircraft, ships, combat vehicles, missiles and other 
weapons systems, and related equipment. The architecture did not 
incorporate requirements for these accounting standards[Footnote 25] 
even though (1) the Federal Accounting Standards Advisory Board and the 
three sponsoring agencies[Footnote 26] responsible for federal 
accounting standards approved them in October 2002 and (2) DOD already 
recognized these new PP&E requirements in its fiscal year 2002 
Performance and Accountability Report and has begun to implement them. 
According to DOD and contractor officials, they used outdated 
requirements because the new standard was not in effect when they were 
identifying and linking national defense PP&E requirements to 
activities, processes, and entities depicted by the architecture. As a 
result, DOD must now revise its architecture to reflect these 
requirements, activities, and processes to ensure compliance with the 
new accounting standard.

Lastly, the architecture includes options for doing business at the 
federal level that were not appropriate to DOD's business operations 
(i.e., do not reflect external requirements constraining DOD's 
operations). For example, Statement of Federal Financial Accounting 
Standards (SFFAS) No. 3, Accounting for Inventory and Related Property, 
requires operating materials and supplies to be primarily accounted for 
using the consumption method and allows the purchases method to be used 
as an exception only under certain conditions.[Footnote 27] Because 
DOD's operating supplies and materials are considered significant, DOD 
reports the value of its almost $91 billion of operating materials and 
supplies using the consumption method of accounting. Developing the 
architecture to allow DOD to use the purchases method to account for 
its inventory and related property may result in inappropriate use of 
this method and, therefore, inconsistent practices and supporting 
system solutions among DOD components.

According to DOD and contractor officials, both the omission and 
limited definition of relevant federal requirements is partly due to 
not having a fully functioning quality assurance process to verify and 
validate the requirements when the requirements were elicited. In March 
2003, following our previous recommendation to strengthen quality 
assurance activities, DOD increased its quality assurance activities. 
These officials stated that, as part of their current quality assurance 
process, they are identifying additional requirements and deleting 
existing requirements that are duplicative or deemed not mandatory. As 
a result, version 1.0 of the BEA does not adequately reflect and 
recognize critical external requirements, and thus is not yet 
sufficiently complete for making informed decisions about system 
investments.

Initial Version of DOD Architecture Is Not Sufficiently Complete to 
Satisfy Act and Guide and Constrain Modernization Investments:

As previously discussed, the various frameworks used to develop an 
enterprise architecture consistently (1) describe the architectures for 
both the enterprise's "As Is" and "To Be" environments in logical 
(e.g., business, performance, application, information) as well as 
technical (e.g., hardware, software, data) terms, and (2) define 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 depend on the architecture's intended purpose.

In the case of DOD, the act specifies that its enterprise architecture 
should enable the department to (1) comply with all federal accounting, 
financial management, and reporting requirements, (2) routinely produce 
timely, accurate, and reliable financial information for management 
purposes, (3) integrate budget, accounting, and program information and 
systems, and (4) provide for the systematic measurement of performance. 
Moreover, DOD's stated intention is to use the architecture as the 
basis for departmentwide business transformation and systems 
modernization.

Collectively, these purposes necessitate that the architecture provide 
considerable depth and detail, as well as logical and rational 
structuring and internal linkages. More specifically, they mean that 
the architecture should contain sufficient scope and detail to permit, 
for example, (1) elimination of duplicative business operations and 
systems, (2) standardization and integration of business operations and 
interoperability of supporting systems, (3) maximum use of 
enterprisewide services, and (4) alignment with related shared 
solutions, like OMB's e-gov initiatives. Moreover, this scope and 
detail[Footnote 28] 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/stakeholders, and (3) provides for 
properly sequencing investments to recognize, for example, the 
investments' respective dependencies and relative business value.

Version 1.0 of DOD's enterprise architecture does not contain 
sufficient scope and detail to either satisfy the act's requirements or 
effectively guide and constrain departmentwide business transformation 
and systems modernization. This is based on our decomposition of 
version 1.0 into various parts and components and comparison of it 
against relevant benchmarks. More specifically, we first divided the 
architecture into the three primary component parts specified in the 
act and recognized in best practices and federal guidance: the "As Is" 
architecture, the "To Be" architecture, and the transition plan. We 
then divided the "As Is" and the "To Be" architectures 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 version 1.0 to relevant:

criteria[Footnote 29] governing the content of key architectural 
elements for the transition plan and these six components of the "As 
Is" and "To Be" architectures. Based on this comparison, we determined 
whether version 1.0 of the architecture generally satisfied, did not 
satisfy,[Footnote 30] or partially satisfied[Footnote 31] each 
architectural element.

Overall, DOD's "As Is" architecture did not satisfy 26 of 29 key 
elements, and partially satisfied the remaining 3; its "To Be" 
architecture did not satisfy 4 of 30 key elements, and partially 
satisfied the remaining 26; and its transition plan partially satisfied 
2 of the 3 elements, but did not satisfy the remaining 1 (see fig. 2). 
This means that version 1.0 of DOD's enterprise architecture does not 
satisfy the requirements of the act and is not sufficiently complete to 
provide an adequate basis for guiding and constraining investments in 
modernized systems. Program officials agreed that this version of the 
architecture is not complete, but stated that it fully satisfies the 
act, because it addresses, to at least some degree, each of the act's 
requirements. They added that they have accomplished as much in 
completing the architecture as was possible in the time available, and 
that the department was overly optimistic in estimating what it could 
produce by May 1, 2003. We agree that DOD set unrealistic expectations 
of the scope and level of architectural definition it could provide by 
this time, but do not agree, as discussed in detail in the previous 
section and the sections that follow, that it satisfies the act's 
requirements. We also believe that the state of DOD's architecture is 
also due to weaknesses in its architecture development management 
controls that are discussed in the previous section, and that our prior 
recommendations were aimed at correcting.

Figure 2: Summary of Extent to Which Version 1.0 of DOD's Enterprise 
Architecture Satisfies Key Elements Governing Architectural Content:

[See PDF for image]

[End of figure]

In addition, the structure of the "To Be" architecture contains 
internal linkage, consistency, and navigation limitations that 
constrain its ease of use and understandability. For example, explicit 
linkages among (1) services/applications, (2) organizations using the 
services/applications, and (3) technical standards governing the 
services/applications were missing, as were linkages between certain 
business and information/data artifacts. This is important because 
dependencies exist among these architectural components and a well-
defined architecture makes such dependencies explicit to ensure that 
systems are implemented in a nonduplicative and integrated fashion. We 
also found instances of internal inconsistencies. For example, one 
artifact (a table) indicated that DOD had not selected any standards 
for certain security services, while another artifact identified 
selected standards for these services. In another instance, four 
artifacts listed identified requirement sources for security, such as 
the Computer Security Act of 1987[Footnote 32] and OMB Circular A-130; 
however, the artifacts' respective lists varied and no single list 
included all the requirement sources. In another instance, some terms 
contained within the architecture (e.g., availability, integrity 
checks, confidentiality, and authentication) were not consistently 
defined, and the architecture did not explain the basis for these 
inconsistencies. For example, one artifact defined authentication as 
the "standard practices followed to authenticate the identity of system 
users," while another artifact defined it as a "security measure 
designed to establish the validity of a transmission, message, or 
originator, or a means of verifying an individual's authorization to 
receive specific categories of information.":

Such inconsistencies in the architecture can in turn lead to 
misinterpretations, and thus incompatibilities, in how systems are 
implemented. Additionally, the architecture did not include user 
instructions or guidance, making it difficult to navigate and use. For 
example, (1) certain artifacts (e.g., diagrams) could not be read on-
line because there was no "zoom" capability enabling enlargement, and 
(2) specific content, such as the applicability of security standards 
to specific security services, took three persons several days to 
locate. The complete results of our analysis of each of version 1.0's 
parts and related components are discussed in detail below.

"As Is" Architecture: This architecture is intended to capture the 
current state of enterprise operations in sufficient scope and detail 
to permit meaningful analysis of gaps between such things as current 
and future processes, data, standards, and systems. It thus should 
describe, for those areas of the enterprise that are likely to change, 
the current set of business processes and performance measures that are 
in place and operating and, among other things, the information/data, 
services/applications, and technology that are in place to support 
these processes and measures. According to relevant guidance,[Footnote 
33] the "As Is" architecture should contain, for example, a description 
of (1) the actual business operations currently being performed to 
support the organization's mission, including the entities/people that 
perform the functions, processes, and activities, and the locations 
where the functions, processes, and activities are being performed, (2) 
the information/data used by the functions, processes, and activities, 
(3) the systems that support the functions, processes, and activities, 
including system interfaces, (4) the types of technology (e.g., 
hardware and software) and associated technical standards that comprise 
the physical systems environment, (5) the security standards and tools 
used to secure and protect systems and data, and (6) the metrics for 
evaluating the effectiveness of mission operations and supporting 
system performance in achieving mission goals and objectives. Without 
this information, an enterprise would be extremely challenged in 
identifying the proper sequence of changes needed to move from its 
current operating environment to its future, target environment. As 
stated by one leading industry authority on enterprise 
architecture,[Footnote 34] an organization will be unable to 
effectively plan and manage its modernization efforts, and will waste 
IT dollars, if it does not have a clear picture of its "As Is" 
environment.

Version 1.0 of DOD's "As Is" architecture provides little of this 
descriptive content. On the positive side, it includes an inventory of 
about 2,300 existing systems that support DOD's current business 
operations, including certain characteristics about each (e.g., system 
owner, purpose and business process it supports, and vendor). However, 
the majority of systems do not have descriptions of system interfaces, 
and the inventory has not been validated and continues to change 
significantly. For example, DOD's current "As Is" systems inventory of 
about 2,300 systems has increased approximately 35 percent when 
compared to its "As Is" inventory of about 1,700 business systems in 
October 2002. In addition, DOD's architecture does not describe (1) the 
current business operations in terms of the entities/people who perform 
the functions, processes, and activities, and the locations where the 
functions, processes, and activities are performed, (2) the data/
information being used by the functions, processes, and activities, (3) 
the types of technology and associated technical standards being 
employed, (4) the security standards and tools being used, and (5) the 
performance metrics being used. Instead, it merely provides a listing 
of the names of the current business processes. As a result, DOD does 
not have a sufficiently described picture of its current environment to 
permit development of a meaningful and useful transition plan. See 
table 5 for the detailed results of our analysis of DOD's "As Is" 
architecture.

Table 5: Detailed Analysis of the Extent to Which DOD's "As Is" 
Architecture Satisfies Key Elements:

Key architectural element: Business:

Key architectural element: A description of the strategic goals, which 
defines what an organization wants to achieve; Element satisfied?: No.

Key architectural element: A business strategy, which defines how the 
strategic goals and objectives will be achieved; Element satisfied?: 
No.

Key architectural element: An inventory of key policies, procedures, 
and standards governing how business operations are executed and 
managed; Element satisfied?: 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 are being performed; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture contains (1) a list of the names of the business processes 
and (2) a high-level (1-page) graphical depiction of these processes. 
It does not contain detailed descriptions of existing business 
operations that include, for example, information flows among 
activities, organizational units and locations that perform the 
business processes, and the technological characteristics of the 
systems that perform these processes.

Key architectural element: An analysis of deficiencies in the "As Is" 
business environment that are to be addressed, as well as obstacles to 
addressing these deficiencies, plans for addressing them, and a 
business case for addressing them. An example is an analysis of the 
quality of existing data to determine their completeness and accuracy; 
Element satisfied?: Partially; Explanation of partially satisfied: 
The architecture contains an analysis of process area deficiencies. 
However, this analysis does not include the business case(s) for 
addressing the deficiencies.

Key architectural element: A description of organizational 
accountability for execution of current business policies, procedures, 
and standards; Element satisfied?: No.

Key architectural element: Information/Data: 

Key architectural element: A description of the data management 
policies, processes, procedures, and tools (e.g., CRUD Matrix[A] ) for 
analyzing, designing, building, and maintaining existing databases; 
Element satisfied?: 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?: No.

Key architectural element: A data dictionary, which is a repository of 
standard data definitions for applications; Element satisfied?: 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 and how they are used, 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?: No.

Key architectural element: A logical database model that provides the 
data structures that support information flows, and that provides the 
basis for developing the schemas for designing, building, and 
maintaining the existing physical databases; Element satisfied?: Yes: 
[Empty]; Element satisfied?: No.

Key architectural element: A metadata[C] model that specifies the rules 
and standards for access to information; Element satisfied?: Yes: 
[Empty]; Element satisfied?: No.

Key architectural element: A description of information flows and 
relationships between organizational units, business operations, and 
applications; Element satisfied?: No.

Key architectural element: Services/Applications: 

Key architectural element: A stable listing of business application 
systems and system components and their interfaces; Element 
satisfied?: Partially; Explanation of partially satisfied: There is 
a list of systems, but the respective interfaces have not been 
described. Further, this list continues to change.

Key architectural element: A description of the common technical 
approach, policies, and procedures for developing/acquiring business 
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?: No.

Key architectural element: Technical.

Key architectural element: Descriptions of the enterprise 
infrastructure services[D] to include specific details regarding the 
functionality and capabilities that these services provide to enable 
systems applications; Element satisfied?: No.

Key architectural element: Identification of the technical standards[E] 
implemented for each enterprise service; Element satisfied?: Yes: 
[Empty]; Element satisfied?: No.

Key architectural element: A description of the physical IT 
infrastructure needed to support the current and any newly developed 
and/or acquired systems outside the scope of the architecture, 
including the relationships among hardware, software, and 
communications devices; Element satisfied?: No.

Key architectural element: Common policies and procedures for 
developing/acquiring infrastructure systems throughout their life 
cycle, including requirements management, design, implementation, 
testing, deployment, operations, and maintenance; Element satisfied?: 
No.

Key architectural element: Security: 

Key architectural element: A description of the policies, procedures, 
goals, strategies, and requirements relevant to information assurance 
and security; Element satisfied?: No.

Key architectural element: A listing of security and information 
assurance related terms; Element satisfied?: No.

Key architectural element: A listing of accountable organizations and 
their respective responsibilities for implementing enterprise security 
services; Element satisfied?: No.

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

Key architectural element: A description of enterprise security 
infrastructure services (e.g., identification and authentication) 
needed to protect the department's assets, and the means for 
implementing such a service (e.g., firewalls and intrusion detection 
software); Element satisfied?: No.

Key architectural element: A description of the security standards[F] 
implemented for each enterprise service to secure assets. These 
standards should be derived from security requirements; Element 
satisfied?: No.

Key architectural element: A description of the protection mechanisms 
implemented to secure the department's assets, such as firewalls and 
intrusion detection software, including a description of the 
relationships among these protection mechanisms; Element satisfied?: 
No.

Key architectural element: Performance.

Key architectural element: A description of the performance management 
process, including how the organization measures, tracks, evaluates, 
and predicts business performance with respect to business functions, 
baseline data, and service levels; Element satisfied?: No.

Key architectural element: A description of customer-focused, 
measurable goals and outcomes for business products and services; 
Element satisfied?: No.

Key architectural element: A description of measurable goals and 
outcomes for managing technology to enable the achievement of business 
goals and outcomes; Element satisfied?: No.

Source: GAO analysis of DOD 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 access of 
data), and actions that should or should not occur such as updating or 
deleting data.

[C] Metadata are "data about data" that enable automation and 
consistent management and use of information, such as rules and 
standards.

[D] Examples of enterprise services include application services, such 
as web services, and collaboration services, such as instant messaging 
or voice conferencing.

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

[F] Security standards cover such services as identification and 
authentication, audit trail creation, access controls, virus 
prevention, and intrusion prevention and detection.

[End of table]

"To Be" Architecture: This architecture is intended to capture the 
vision of future business operations and supporting technology. It 
should describe the desired capabilities and 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 it should be fiscally and technologically 
achievable. According to relevant guidance,[Footnote 35] 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/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, the architecture would allow DOD to satisfy the act's 
requirements, such as routinely providing timely, accurate, and 
reliable information for management decision making.

Version 1.0 of DOD's "To Be" architecture provides some of this 
descriptive content, but not to the extent needed to meet the act's 
requirements and permit effective acquisition and implementation of 
system solutions and associated operational change. On the positive 
side, it contains a description of the future business operations and a 
logical database model. However, the future business operations are not 
described in terms of the entities/people who will perform the 
functions, processes, and activities, and the locations where the 
functions, processes, and activities will be performed. Further, we 
found no linkage between the logical database model and the conceptual 
data model, which raises concerns regarding the utility of this model 
in supporting information flows for business operations and systems. In 
addition, it does not describe (1) the actual systems to be developed 
or acquired to support future business operations, (2) the physical 
infrastructure (e.g., hardware and software) that will be needed to 
support the business systems, (3) the organizations that will be 
accountable for implementing security and the tools to be used to 
secure and protect systems and data, and (4) 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 capital investment, and thus will be unable to effectively 
leverage technology to orchestrate logical and systematic change and 
optimize enterprisewide mission performance. See table 6 for the 
results of our analysis of DOD's "To Be" architecture.

Table 6: Detailed Analysis of the Extent to Which DOD's "To Be" 
Architecture Satisfies Key Elements:

Key architectural element: Business:

Key architectural element: A description of the strategic goals, which 
define what an organization wants to achieve; Element satisfied?: 
Partially; Explanation of partially satisfied: The architecture 
contains a description of the strategic goals, but does not address 
how it will support the department's warfighter goals.

Key architectural element: A business strategy, which defines how the 
strategic goals and objectives will be achieved; Element satisfied?: 
Partially; Explanation of partially satisfied: The architecture lists 
business strategies, such as utilizing more commercial practices to 
promote private sector partnerships, but does not describe how these 
strategies will be implemented.

Key architectural element: Common policies, procedures, and business 
rules for consistent implementation of architecture; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture does not have common policies and procedures, nor has it 
defined a plan for achieving this. It does, however, recognize the 
need for such policies, procedures, and business rules, and provides a 
general time frame for when they will be developed; The architecture 
includes high-level descriptions of business rules, but does not 
formally define how these rules will be automated and implemented.

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 are performed; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture has a high-level description of processes, without a 
specific identification of organizations and locations.

Key architectural element: A description of the architecture 
governance structure and processes to ensure that the department's 
business transformation effort remains compliant with the 
architecture; Element satisfied?: Partially; Explanation of partially 
satisfied: The architecture has a draft concept for governance, but 
does not describe, 
for example, the process for ensuring compliance with the architecture 
and the processes for managing risks and approving the architecture and 
systems investments.

Key architectural element: A listing of opportunities to unify and/or 
simplify systems and processes across the agency; Element satisfied?: 
Partially; Explanation of partially satisfied: The architecture 
contains a list of deficiencies for the operational activities, but 
not 
for systems. For example, it does not identify the specific pilot 
projects that will be conducted, nor does it identify the resources 
(funding and staffing) needed for conducting these pilots.

Key architectural element: A description of the organizational 
approach for communications and interactions among business lines and 
program areas for management reporting, operational functions, and 
architecture development and use; Element satisfied?: Partially; 
Explanation 
of partially satisfied: The architecture has a notional organizational 
structure for communications and interactions among departmental 
entities for reporting and management purposes.

Key architectural element: Information/Data.

Key architectural element: Description of data management policies, 
processes, procedures, and tools (e.g., CRUD Matrix) for analyzing, 
designing, building, and maintaining databases in an enterprise 
architected environment; Element satisfied?: Partially; Explanation of 
partially satisfied: The architecture contains a high-level data 
management strategy, including guidelines, and an approach for managing 
the data in an EA environment. However, it does not identify the 
policies, processes, procedures, and tools to be used.

Key architectural element: A description of the business and 
operational rules 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?: 
Partially; Explanation of partially satisfied: The architecture 
contains descriptions of data standards upon which business rules can 
later be developed. The architecture contains rules for security, but 
lacks the details needed to consistently enforce these rules (e.g., the 
rules do not always identify the event, entity name, and the action to 
occur). In addition, the architecture does not provide any evidence as 
to whether these business rules have been verified and validated for 
completeness.

Key architectural element: A data dictionary, which is a repository of 
standard data definitions for applications; Element satisfied?: 
Partially; Explanation of partially satisfied: The architecture 
contains a data dictionary comprised of a list of terms and their 
respective definitions. However, the architecture does not have a 
complete list of terms nor does it contain a list of the data 
elements[A] needed to support systems and database design.

Key architectural element: A conceptual data model that describes the 
fundamental things/objects (e.g., invoices, financial statements, 
inventory) that make up the business and how they are used, 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?: Partially; Explanation of partially 
satisfied: The architecture contains a high-level conceptual data model 
that does not specify how the business objects are used by applications 
(i.e., does not show how the information is used by the enterprise). 
Further, this model does not show a consolidated view of the data 
(business objects) to be used by applications.

Key architectural element: A logical database model that provides the 
data structures that support information flows, and that provides the 
basis for developing the schemas for designing, building, and 
maintaining the physical databases; Element satisfied?: Partially; 
Explanation of partially satisfied: The architecture contains data 
structures, which describe, for example, data entities, attributes, 
and relationships among data. However, the model has not been verified 
or validated for completeness with respect to business relevance (i.e., 
business scenarios do not show evidence of this validation), nor are 
there criteria for defining the number of business scenarios that have 
to be completed. In addition, it does not show the relationship among 
the data structures in this data model nor the data structure 
underlying the data/information flows for business operations and 
systems. Further, the architecture does not contain a unified 
enterprise data model that reconciles the independent data models that 
have been developed for each business process area.

Key architectural element: A metadata model that specifies the rules 
and standards for access to information; Element satisfied?: 
Partially; Explanation of partially satisfied: The architecture notes 
that an approach, strategy, and plan for creating and managing 
metadata have not yet been developed. However, it notes that these 
documents will be created at a later time.

Key architectural element: A description of information flows and 
relationships between organizational units, business operations, and 
system elements; Element satisfied?: Partially; Explanation of 
partially 
satisfied: The architecture contains notional system-to-system 
relationships, including how the system may support business 
activities, which can be used to extend development of the 
architecture, but the architecture does not link organizational units 
to business operations and system elements (e.g., hardware and 
software).

Key architectural element: Services/Applications.

Key architectural element: A description of the business application 
systems and system components and their interfaces; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture has grouped business functions into system entities[B] and 
identified the communication paths between these entities; however, 
these entities are notional.

Key architectural element: A description of the common technical 
approach, policies, and procedures for developing/acquiring business 
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?: Partially; Explanation 
of partially satisfied: The architecture does not have a common 
technical approach and policies and procedures, nor has it defined a 
plan for achieving this. It does, however, recognize the need for 
having an approach and policies and procedures, and provides a general 
time frame for when they will be developed.

Key architectural element: Technical.

Key architectural element: Descriptions of the enterprise 
infrastructure services to include specific details regarding the 
functionality and capabilities these services will provide to enable 
systems applications; Element satisfied?: Partially; Explanation 
of partially satisfied: The architecture contains high-level 
definitions for the enterprise services. However, the specific 
enterprise services for this architecture are to be developed within 
the context of the GIG's enterprise services, and, according to DOD, 
the GIG is not complete and is still evolving.

Key architectural element: Identification of the technical standards to 
be implemented for each enterprise service; Element satisfied?: 
Partially; Explanation of partially satisfied: DOD has identified 
enterprise infrastructure services for system entities. However, 
standards profiles that support the services, and commonly apply to all 
system entities, are not clearly identified and described. DOD has not 
yet defined standards profiles to be employed in the conduct of 
business processes.

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?: No.

Key architectural element: Common policies and procedures for 
developing/acquiring 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?: Partially; Explanation 
of partially satisfied: The architecture does not have common policies 
and procedures, nor has it defined a plan for achieving this. It does, 
however, recognize the need for having these policies and procedures, 
and provides a general time frame for when they will be developed.

Key architectural element: Security.

Key architectural element: A description of the policies, procedures, 
goals, strategies, and requirements relevant to information assurance 
and security; Element satisfied?: Partially; Explanation of partially 
satisfied: The architecture refers to policies, but application of the 
policies is inconsistent within the architecture. It does not contain 
procedures; but recognizes the need for them and provides a general 
time frame for when they will be developed. The architecture contains 
hypothetical security goals for such attributes as risk and impact 
assessments. It also contains a high-level strategy that explains where 
information assurance should be addressed in the architecture and the 
target capabilities needed for information assurance (e.g., threat/
vulnerability assessments). In addition, the architecture lists 
relevant security requirements; However, the goals, strategies, and 
requirements have not been mapped to specific physical security systems 
solutions. It is also unclear how information assurance activities will 
support the department's warfighter goals.

Key architectural element: A listing of security and information 
assurance related terms; Element satisfied?: Partially; Explanation of 
partially satisfied: The data dictionary does list some security-
related terms (e.g., availability, integrity, and authentication); 
however, the definitions for these terms are inconsistent with the 
definitions contained in the existing policy; In addition, some of 
the terms that are not listed (e.g., need-to-know and nonrepudiation) 
are critical to implementing effective information assurance controls.



Key architectural element: A listing of accountable organizations and 
their respective responsibilities for implementing enterprise security 
services; Element satisfied?: No.

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

Key architectural element: A description of enterprise security 
infrastructure services (e.g., identification and authentication) that 
will be needed to protect the department's assets, and the means for 
implementing such services (e.g., firewalls and intrusion detection 
software); Element satisfied?: Partially; Explanation of partially 
satisfied: The architecture contains generic descriptions of enterprise 
security services, but does not specify the means for implementation.

Key architectural element: A description of the security standards to 
be implemented for each enterprise service to secure assets. These 
standards should be derived from security requirements; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture describes the enterprise services and associated standards 
that apply to individual system entities. However, it does not link 
requirements to standards and vice versa.

Key architectural element: A description of the protection mechanisms 
that will be implemented to secure the department's assets, such as 
firewalls and intrusion detection software, including a description of 
the relationships among these protection mechanisms; Element 
satisfied?: No.

Key architectural element: Performance.

Key architectural element: A description of the performance management 
process, including how the organization will measure, track, evaluate, 
and predict business performance with respect to business functions, 
baseline data, and service levels; Element satisfied?: Partially; 
Explanation of partially satisfied: The architecture contains a high-
level proposal to develop this process; however, buy-in has not been 
achieved. Until buy-in is obtained, the development of such a process 
will not be an architectural requirement.

Key architectural element: A description of customer-focused measurable 
goals and outcomes for business products and services; Element 
satisfied?: Partially; Explanation of partially satisfied: The 
architecture contains performance metrics for operational activities 
and notional systems; however, these metrics are not linked to 
measurable goals associated with business products and services.

Key architectural element: A description of measurable goals and 
outcomes for managing technology to enable the achievement of business 
goals and outcomes; Element satisfied?: Partially; Explanation of 
partially satisfied: The architecture contains plans to establish 
baseline measures that can be used to establish technical performance 
measures, but it does not yet recognize the need to tie these measures 
to the business goals/outcomes.

Source: GAO analysis of DOD data.

[A] Data elements are basic units of information that cannot be further 
subdivided. For example, you may create a data structure called 
'Address,' which contains the data elements 'Street Address, City, 
State, and Zip Code.':

[B] System entities are logical groups of system functions (e.g., 
general ledger, payroll) representing "To Be" capabilities and 
requirements.

[End of table]

Transition Plan: According to relevant guidance and best 
practices,[Footnote 36] the transition plan should provide a temporal 
roadmap for moving from the "As Is" to the "To Be" environment. An 
important step in the development of a well-defined transition plan is 
a gap analysis that compares the "As Is" and "To Be" architectures to 
identify differences. Other important steps include analyses of 
technology opportunities and market place trends as well as assessments 
of fiscal and budgetary realities and institutional acquisition and 
development capabilities. Using 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 either 
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. Furthermore, they do so 
in light of resource constraints, such as budget, people, acquisition/
development process maturity, and associated time frames. Recognizing 
the importance of a well-defined transition plan, the act[Footnote 37] 
also required DOD to identify (1) all mission-critical or mission-
essential operational and developmental financial and nonfinancial 
systems, (2) the actual costs to operate and maintain these systems 
during fiscal year 2002, and (3) the estimated costs for fiscal year 
2003.

DOD's transition plan generally does not possess these attributes, and 
is basically a plan to develop a transition plan. Specifically, it does 
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 identification of 
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. Further, while the transition 
plan contained system cost information for fiscal years 2002 and 2003, 
it did not associate this information, as specified in the act, with 
mission-critical or mission-essential operational and developmental 
financial and nonfinancial systems.

DOD attributed the state of its transition plan to attempting to 
develop this plan concurrently with developing its "As Is" and "To Be" 
architectures, which it found was not feasible. As a result, DOD does 
not yet have a meaningful and reliable basis for managing the 
disposition of its existing inventory of about 2,300 systems or for 
sequencing the introduction of modernized business operations and 
supporting systems. See table 7 for the detailed results of our 
analysis of DOD's transition plan.

Table 7: Detailed Analysis of the Extent to Which DOD's Transition Plan 
Satisfies Key Architectural Elements:

[See PDF for image]

Source: GAO analysis of DOD data.

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

[End of table]

Contractor Review of Version 1.0 of the Architecture Also Identified 
Weaknesses:

DOD's verification and validation contractor assessed Version 1.0 of 
its architecture against relevant best practices to determine its 
quality. In June 2003,[Footnote 38] consistent with our assessment, 
this contractor reported that while DOD's architecture contained 
significant content, it lacked the depth and detail needed to begin 
building and implementing modernized systems and making operational 
changes. Further, the contractor reported that the architecture was not 
easily understandable and that its utility to stakeholders in system 
acquisition planning was limited. According to the contractor, these 
conclusions were based on the following findings.

* Linkages among architecture products had not been defined, making it 
difficult to navigate through the architecture.

* Architecture products did not adequately describe the "As Is" 
environment, including business processes and existing business 
application systems and supporting technology, which would make it 
difficult for DOD to perform a gap analysis to support development of a 
transition plan.

* Architecture products did not adequately describe the "To Be" 
environment, including (1) business rules governing how data are to be 
accessed and used within the automated environment, (2) migration and 
target systems and applications, (3) enterprise infrastructure services 
and the technical standards relevant to each service, (4) security 
needs, including standards and protection mechanisms (e.g., firewalls), 
and (5) performance metrics.

* The transition plan was merely a plan to develop a transition plan.

As a result, the contractor recommended, among other things, that the 
department discontinue further development of the "To Be" architecture 
until it addressed identified deficiencies. Program officials stated 
that they will address these comments in subsequent versions of the 
architecture. However, they could not provide us with any written plans 
governing the scope of comments to be addressed, and how they will be 
addressed and validated.

DOD Has Yet to Establish an Effective Investment Management Process for 
Selecting and Controlling Business System Investments:

Using the architecture as an integral investment management frame of 
reference is essential to effectively selecting and controlling 
business system investments and to moving the organization toward the 
target architecture. Such use of an architecture is provided for in 
legislation, federal guidance, and best practices. In addition, 
subsection 1004(d) of the act stipulates that any amount in excess of 
$1 million may be obligated for system improvements only if the DOD 
Comptroller makes a determination that the improvement is necessary for 
(1) critical national security capability or critical safety and 
security requirements or (2) prevention of significant adverse effect 
on a project that is needed to achieve an essential capability. The act 
further states that once the architecture is approved, the DOD 
Comptroller must determine that expenditures for system improvements 
are consistent with the enterprise architecture and the transition 
plan. These legislative requirements are consistent with our open 
recommendations to DOD for selecting and controlling business systems 
investments. Specifically, we recommended that DOD gain control over 
business system investments by establishing a hierarchy of investment 
review boards from across the department, establishing a standard set 
of criteria to ensure alignment and consistency with the architecture, 
and directing the boards to perform a comprehensive review of all 
ongoing business system investments. (App. III contains details on the 
status of DOD's efforts to address our open recommendations.):

To comply with the legislative requirement and address our 
recommendations, the DOD Comptroller issued a memorandum on March 7, 
2003, to DOD's component organizations stating that the BMSI office--
which is responsible for overseeing the development and implementation 
of the architecture--must review all system initiatives with 
expenditures in excess of $1 million. In addition, the memorandum 
directs the DOD components, as an integral part of the review and 
approval process, to present information to DOD Comptroller officials 
and relevant domain owners that demonstrates that each investment (1) 
complies with the architecture, and (2) is economically justified.

DOD has not yet defined and implemented an effective investment 
management process to proactively identify and control system 
investments exceeding $1 million while the architecture is being 
developed and after it is completed. Based on DOD data, as of June 6, 
2003, the DOD Comptroller had approved one system initiative with 
expenditures exceeding $1 million since enactment of the act, and was 
reviewing four others. The one system approval for $10 million was an 
enhancement to the Mechanization of Contract Administrative Services 
(MOCAS) system--which is DOD's primary contractor pay system and is 
used to maintain data on the majority of DOD's weapons systems as well 
as service contracts administered by the Defense Contract Management 
Agency. According to DOD, the enhancements to MOCAS are essential 
because the system intended to replace MOCAS--Defense Procurement 
Payment System--was terminated in December 2002 by the DOD Comptroller 
after 7 years of effort and an investment of $126 million because of 
poor program performance and increasing costs. In approving the 
enhancements to MOCAS, the DOD Comptroller determined that it was 
needed to assure continued system operations and that the failure of 
MOCAS would jeopardize DOD's ability to pay contractors on time, which 
is one of the criteria in the act.

BMSI officials stated that the department's current process for 
selecting and controlling business system investments depends on the 
system owners coming forward with the request for approval, and that it 
has not established the means to determine which systems should be 
submitted for review. In response to our prior open recommendations, 
the DOD Comptroller states that the department is currently 
establishing a governance structure that includes an investment review 
board and making the domain owners an integral part of the review and 
approval process for selecting and controlling business system 
investments. According to DOD officials, the board is to utilize a 
portfolio management approach based on established approval thresholds 
to address investment decisions across the department. Further, DOD 
officials state that the department is developing standard criteria to 
be used by the investment boards to assess business system investments, 
including consistency with the architecture. However, this proposed 
governance concept has not yet been adopted. We discuss this process in 
more detail later in this report.

Our analysis of DOD's fiscal years 2003 and 2004 IT budget requests 
shows that over 200 systems in each year's budget, totaling about $4 
billion per year, could involve obligations of funds that meet the $1 
million threshold. This indicates that the majority of the billions of 
dollars that DOD invests in business system improvements annually have 
not been subjected to the scrutiny of the DOD Comptroller as now called 
for in the act. The act places limitations on the legal authority of 
individual program and government contracting officials to obligate 
funds in support of the systems for which they are responsible, but DOD 
has yet to proactively manage investments to avoid violations of the 
limitations and to review investments in any meaningful way to enforce 
these statutory limitations. Program officials acknowledge that the 
department, at a minimum, could use DOD's IT budget documentation to 
proactively fulfill the act's requirements. Until DOD strengthens its 
process for selecting and controlling business system investments and 
adopts an effective governance concept, it remains exposed to the risk 
of spending billions of dollars on duplicative, stove-piped, 
nonintegrated systems that do not optimize mission performance and 
accountability and, therefore, do not support the department's 
transformation goals.

DOD's Plans for Evolving and Extending Its Enterprise Architecture and 
for Improving Business System Investment Decision Making Are Unclear:

According to DOD officials, it intends to (1) further develop, evolve, 
and extend the architecture, including the transition plan, and issue a 
revised version, and (2) improve processes for selecting and 
controlling business systems investments. However, DOD's plans for this 
next phase have not been explicitly defined. Until they are clearly and 
completely defined and effectively implemented, the department risks 
perpetuating past business system investment practices and spending 
tens of billions of dollars on incompatible, duplicative, and 
nonintegrated systems.

DOD's Plans for Issuing Next Version of Architecture Products Are 
Unclear:

According to DOD, it intends to issue its next significant version of 
the architecture in May 2004 and this update is to extend and evolve 
the architecture. To accomplish this, program documentation states that 
DOD will, among other things,

* determine the contractor resources needed to evolve and extend the 
architecture;

* develop a methodology for integrating the architecture with DOD's GIG 
and OMB's Federal Enterprise Architecture;[Footnote 39]

* establish an approach for maintaining its existing systems inventory; 
and:

* evaluate the architecture for completeness, accuracy, and integration 
of end-to-end business processes and system functions.

However, how DOD will accomplish these and other activities associated 
with effectively updating its architecture has not been defined, nor 
have such things as roles and responsibilities for executing 
activities, dependencies among activities, and measures of activity 
progress. Rather, the department basically has plans to develop a 
strategy that will define this next phase of activities. By following 
this approach, DOD will again be setting unrealistic expectations; and 
without clearly defined plans for evolving and extending the 
architecture, the department is at risk of falling short of its 
intended goals to centrally guide and direct its architecture efforts.

DOD's Plans for Improving Controls over Ongoing and Planned Business 
System Investments Are Unclear:

As previously described, DOD has a proposed governance concept that 
describes how and by whom business transformation requirements 
identified by the architecture will be implemented in the department. 
This proposal vests the business line representatives or domain owners 
with the authority, responsibility, and accountability for business 
transformation, implementation of the architecture, development and 
execution of the transition plan, and portfolio management within their 
domains. This proposal also designates the domain owners of the 
business process areas and provides them a high-level description of 
their roles and responsibilities. In addition, the proposal allocates 
the current inventory of about 2,300 systems to these domain owners as 
portfolios of investments to manage.

However, it is not clear how the proposed approach will be implemented, 
and how it will satisfy the act's investment selection and control 
requirements. Further, it is also not clear how the proposed approach 
will address our recommendations for establishing a hierarchy of 
investment review boards and an explicit set of standard criteria for 
selecting, controlling, and evaluating IT investments as a portfolio of 
options, with one criterion to ensure consistency and compliance with 
ongoing architecture development efforts.

According to DOD officials, as a first step, the domain owners will 
validate cost and other functional information associated with the 
existing inventory of about 2,300 systems and identify those 
inventoried systems that will not become part of the "To Be" 
architecture. According to DOD, these efforts will evolve over time 
and, therefore, its plans do not include a completion date.

Moreover, DOD program documentation provides for initiating pilot 
projects in the near term that are to demonstrate and implement a 
portion of the architecture and be usable across the department. In 
contrast, DOD officials stated that the pilot projects are intended to 
validate departmentwide business processes and not to implement 
production systems. Thus, the purpose and scope of these projects 
remain unclear and specific projects have yet to be selected. If DOD 
intends for these projects to demonstrate or validate an enterprisewide 
business process to address a current deficiency in DOD's business 
operations and systems, such as the lack of common data standards, 
these projects could help DOD improve its architecture and thus could 
be reasonable investments. However, if the pilot projects are to be 
used to acquire and implement system solutions and place them into 
production to achieve an operational capability, it is unclear how DOD 
will ensure architecture alignment and manage the risk associated with 
investing in more systems before it has a well-defined blueprint and an 
effective investment management process to guide and control them.

Conclusions:

Recent legislation and our past recommendations to DOD recognize that 
it is absolutely essential to have and use a well-defined enterprise 
architecture to guide and constrain DOD's business systems 
modernization program. DOD's efforts to date to develop such an 
architecture, and satisfy its legislative mandate, are good first steps 
to this end, but more steps are needed before it will have an adequate 
basis for acquiring and implementing its desired systems environment. 
In our view, DOD's BEA (version 1.0) provides a foundation for it to 
move forward in adding missing architectural scope and detail, and 
ultimately validating that the architecture is sufficiently complete 
and correct.

DOD has not, however, made similar strides in its efforts to control 
its ongoing and planned systems investments. In effect, nothing 
significant has changed since our prior review in the way that DOD is 
investing billions of dollars annually in existing and new systems. 
This means that the department has yet to implement our prior 
recommendations for controlling systems funding, and it has not yet 
defined and implemented an effective approach to satisfy legislative 
requirements for approving systems investments over $1 million. As a 
result, billions of dollars continue to be at risk of being spent on 
more systems that are duplicative, are not interoperable, cost more to 
maintain than necessary, and do not optimize mission performance and 
accountability.

The future of DOD's architecture development and implementation 
activities is difficult to understand because DOD's near-term plans are 
unclear. As a result, DOD's business systems modernization efforts 
remain exposed to considerable risk. It is critical for DOD to 
effectively expand and extend its architecture to the point that it 
provides a sound basis for departmentwide investment decision making, 
and that in doing so, it continue to centrally guide and direct its 
architecture development efforts and not allow DOD domain owners to 
proceed independently. Similarly, it is critical for DOD to immediately 
gain control over near-term investments pending the architecture's 
completion. This includes justifying further investment in each ongoing 
system project beyond fiscal year 2003 and not starting any new 
projects that are intended to be put into production and provide 
operational capabilities, pilot or otherwise, until the (1) 
architecture has been sufficiently completed and (2) DOD has 
established an effective institutional approach to make informed 
systems investment decisions, including ensuring that each investment 
is architecturally aligned. To do less continues to put billions of 
dollars at unnecessary risk of perpetuating today's legacy systems 
environment.

Recommendations:

Because our open recommendations to DOD for managing the development, 
maintenance, and implementation of its BEA, including effectively 
controlling ongoing investment in business systems, are critical to the 
success of its modernization and transformation efforts, we reiterate 
the recommendations that we made in our May 2001[Footnote 40] and 
February 2003[Footnote 41] reports. To further assist the department in 
effectively implementing these recommendations, we are augmenting them 
by providing the following more specific implementation steps. 
Specifically, we recommend to the Secretary of Defense that he or his 
appropriate designee,

* define and implement an effective investment management process to 
proactively identify, control, and obtain DOD Comptroller review and 
approval of expenditures for new and ongoing business system 
investments exceeding $1 million while the architecture is being 
developed and after it is completed, and which includes clearly defined 
domain owners' roles and responsibilities for selecting and controlling 
ongoing and planned system investments;

* implement the core elements in our EA Framework for Assessing and 
Improving Enterprise Architecture Management that we identify in this 
report as not satisfied, including ensuring that minutes of the 
executive body charged with directing, overseeing, and approving the 
architecture are prepared and maintained;

* update version 1.0 of the architecture to include the 340 Joint 
Financial Management Improvement Program requirements that our report 
identified as omitted or not fully addressed;

* update version 1.0 of the architecture to include the 29 key elements 
governing the "As Is" architectural content that our report identified 
as not being fully satisfied;

* update version 1.0 of the BEA to include the 30 key elements 
governing the "To Be" architectural content that our report identified 
as not being fully satisfied;

* update version 1.0 to ensure that "To Be" architecture artifacts are 
internally consistent, to include addressing the inconsistencies 
described in this report, as well as including user instructions or 
guidance for easier architecture navigation and use;

* update version 1.0 of the architecture to include (1) the three key 
elements governing the transition plan content that our report 
identified as not being fully satisfied and (2) those system 
investments that will not become part of the "To Be" architecture, 
including time frames for phasing out those systems;

* update version 1.0 of the architecture to address comments made by 
the verification and validation contractor;

* develop a well-defined near-term plan for extending and evolving the 
architecture and ensure that this plan includes addressing our 
recommendations, defining roles and responsibilities of all 
stakeholders involved in extending and evolving the architecture, 
explaining dependencies among planned activities, and defining measures 
of activity progress; and:

* limit the pilot projects to small, low-cost, low-risk prototype 
investments that are intended to provide knowledge needed to extend and 
evolve the architecture, and are not to acquire and implement 
production version system solutions or to deploy an operational system 
capability.

Agency Comments and Our Evaluation:

In written comments on a draft of this report (reprinted in app. IV), 
the department concurred with 9 of our 10 recommendations, partially 
concurred with the remaining one, and described recently completed, 
ongoing, or planned efforts to address them. We will evaluate whether 
DOD's efforts fully address our recommendations in future BEA reviews.

DOD partially concurred with our recommendation regarding the 
architectural content of the "As Is" environment stating that because 
the current operating environment is dynamic, complete satisfaction of 
the 29 key elements that our report identified is not realistically 
achievable. DOD stated that such data, even if they were possible to 
obtain, would be obsolete upon arrival and, therefore, the department 
does not deem the data collection effort to be cost effective. DOD 
stated that it is currently analyzing the 29 key elements and that as 
part of its incremental development approach, it will collect relevant 
"As Is" documentation, where appropriate, and will include the data in 
future releases of the BEA.

We agree that architectural information that does not provide value 
commensurate with cost should not be captured in the BEA. However, 
DOD's comments concerning the missing 29 "As Is" key elements do not 
contain sufficient context, detail, and explanation to understand which 
key elements DOD proposes to satisfy and which it does not. Further, 
its comments do not adequately explain and justify why key elements 
should be waived. As noted in our report, DOD's "As Is" architecture 
products provide little descriptive content and do not satisfy 90 
percent of the architectural elements required by relevant guidance 
needed to permit development of a meaningful and useful transition 
plan. Further, as noted in our March 2003 report,[Footnote 42] while 
further development of the "As Is" environment can coincide with the 
development of the transition plan, not having defined the "As Is" 
operations and technology at this juncture is risky because it defers 
until too late in the architecture development cycle creation of 
sufficient descriptive content and context to develop an effective 
transition plan.

We are sending copies of this report to interested congressional 
committees; the Director, Office of Management and Budget; the 
Secretary of Defense; the Under Secretary of Defense (Comptroller); the 
Assistant Secretary of Defense (Networks and Information Integration)/
Chief Information Officer; the Under Secretary of Defense (Acquisition, 
Technology, and Logistics); the Under Secretary of Defense (Personnel 
and Readiness); and the Director, Defense Finance and Accounting 
Service. This report will also be available at no charge on our Web 
site at [Hyperlink, http://www.gao.gov] http://www.gao.gov.

If you or your staff have any questions on matters discussed in this 
report, please contact Gregory D. Kutz at (202) 512-9095 or [Hyperlink, 
kutzg@gao.gov] kutzg@gao.gov, or Randolph C. Hite at (202) 512-3439 or 
[Hyperlink, hiter@gao.gov] hiter@gao.gov. Major contributors to this 
report are acknowledged in appendix V.

Gregory D. Kutz 
Director 
Financial Management and Assurance:

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

Signed by Gregory D. Kutz and Randolph C. Hite:

List of Committees:

The Honorable John W. Warner 
Chairman 
The Honorable Carl Levin 
Ranking Minority Member 
Committee on Armed Services 
United States Senate:

The Honorable Ted Stevens 
Chairman 
The Honorable Daniel K. Inouye 
Ranking Minority Member 
Subcommittee on Defense 
Committee on Appropriations 
United States Senate:

The Honorable Duncan Hunter 
Chairman 
The Honorable Ike Skelton 
Ranking Minority Member 
Committee on Armed Services 
House of Representatives:

The Honorable Jerry Lewis 
Chairman 
The Honorable John P. Murtha 
Ranking Minority Member 
Subcommittee on Defense 
Committee on Appropriations 
House of Representatives:

[End of section]

Appendixes: 

Appendix I: SEC. 1004. [of Public Law 107-314] Development and 
Implementation of Financial Management Enterprise Architecture:

SEC. 1004. (of Public Law 107-314] DEVELOPMENT AND IMPLEMENTATION OF 
FINANCIAL MANAGEMENT ENTERPRISE ARCHITECTURE:

(a) REQUIREMENT FOR ENTERPRISE ARCHITECTURE AND FOR TRANSITION 
PLAN-:

Not later than May 1. 2003, the Secretary of Defense shall develop-:

(1) a financial management enterprise architecture for all budgetary, 
accounting, finance, enterprise resource planning, and mixed 
information systems of the Department of Defense; and:

(2) a transition plan for implementing that financial management 
enterprise architecture.

(b) COMPOSITION OF ENTERPRISE ARCHITECTURE-:

(]) The financial management enterprise architecture developed under 
subsection (a)(1) shall describe an information infrastructure that, at 
a minimum, would enable the Department of Defense to-:

(A) comply with all Federal accounting, financial management, and 
reporting requirements;

(B) routinely produce timely, accurate, and reliable financial 
information for management purposes;

(C) integrate budget, accounting, and program information and systems; 
and:

(D) provide for the systematic measurement of performance, including 
the ability to produce timely, relevant, and reliable cost information.

(2) That enterprise architecture shall also include policies, 
procedures, data standards, and system interface requirements that are 
to apply uniformly throughout the Department of Defense.

(c) COMPOSITION OF TRANSITION PLAN-The transition plan developed under 
subsection (a)(2) shall include the following:

(1) The acquisition strategy for the enterprise architecture, including 
specific time-phased milestones, performance metrics, and financial and 
nonfinancial resource needs.

(2) A listing of the mission critical or mission essential operational 
and developmental financial and nonfinancial management systems of the 
Department of Defense, as defined by the Under Secretary of Defense 
(Comptroller), consistent with budget justification documentation, 
together with--:

(A) the costs to operate and maintain each of those systems during 
fiscal year 2002; and:

(B) the estimated cost to operate and maintain each of those systems 
during fiscal year 2003.

(3) A listing of the operational and developmental financial management 
systems of the Department of Defense as of the date of the enactment of 
this Act (known as `legacy systems') that will not be part of the 
objective financial and nonfinancial management system, together with 
the schedule for terminating those legacy systems that provides for 
reducing the use of those legacy systems in phases.

(d) CONDITIONS FOR OBLIGATION OF SIGNIFICANT AMOUNTS FOR FINANCIAL 
SYSTEM IMPROVEMENTS-
An amount in excess of $1,000,000 may be 
obligated for a defense financial system improvement only if the Under 
Secretary of Defense (Comptroller) makes a determination regarding that 
improvement as follows: (l) Before the date of an approval specified in 
paragraph (2), a determination that 
the defense financial system improvement is necessary for either of the 
following reasons:

(A) To achieve a critical national security capability or address a 
critical requirement in an area such as safety or security.

(B) To prevent a significant adverse effect (in terms of a technical 
matter, cost, or schedule) on a project that is needed to achieve an 
essential capability, taking into consideration in the determination 
the alternative solutions for preventing the adverse effect.

(2) On and after the date of any approval by the Secretary of Defense 
of a financial management enterprise architecture and a transition plan 
that satisfy the requirements of this section, a determination that the 
defense financial system improvement is consistent with both the 
enterprise architecture and the transition plan.

(e) CONGRESSIONAL REPORTS-Not later than March 15 of each year from 
2004 through 2007, the Secretary of Defense shall submit to the 
congressional defense committees a report on the progress of the 
Department of Defense in implementing the enterprise architecture and 
transition plan required by this section. Each report shall include, at 
a minimum-:

(1) a description of the actions taken during the preceding fiscal year 
to implement the enterprise architecture and transition plan (together 
with the estimated costs of such actions);

(2) an explanation of any action planned in the enterprise architecture 
and transition plan to be taken during the preceding fiscal year that 
was not taken during that fiscal year;

(3) a description of the actions taken and planned to be taken during 
the current fiscal year to implement the enterprise architecture and 
transition plan (together with the estimated costs of such actions); 
and:

(4) a description of the actions taken and planned to be taken during 
the next fiscal year to implement the enterprise architecture and 
transition plan (together with the estimated costs of such actions).

(f) COMPTROLLER GENERAL REVIEW-Not later than 60 days after the 
approval of an enterprise architecture and transition plan in 
accordance with the requirements of subsection (a), and not later than 
60 days after the submission of an annual report required by subsection 
(e), the Comptroller General shall submit to the congressional defense 
committees an assessment of the extent to which the actions taken by 
the Department comply with the requirements of this section.

(g) DEFINITIONS-In this section:

(1) The term `defense financial system improvement' means the 
acquisition of a new budgetary, accounting, finance, enterprise 
resource planning, or mixed information system for the Department of 
Defense or a modification of an existing budgetary, accounting, 
finance, enterprise resource planning, or mixed information system of 
the Department of Defense. Such term does not include routine 
maintenance and operation of any such system.

(2) The term `mixed information system' means an information system 
that supports financial and non-financial functions of the Federal 
Government as defined in Office of Management and Budget Circular A-127 
(Financial management Systems).

(h) REPEAL-(1) Section 2222 of title 10, United States Code, is 
repealed. The table of sections at the beginning of chapter 131 of such 
title is amended by striking the item relating to such section.

(2) Section 185(d) of such title is amended by striking `has the 
meaning given that term in section 2222(c)(2) of this title' and 
inserting `means an automated or manual system from which information 
is derived for a financial management system or an accounting system'.

[End of section]

Appendix II: Scope and Methodology:

To accomplish our objectives for determining (1) the extent to which 
DOD's actions complied with the requirements of section 1004 of Public 
Law 107-314 and (2) DOD's plans for further development and 
implementation of the architecture, we assessed DOD's initial 
architecture, which, according to DOD, was approved by the DOD 
Comptroller and transmitted to the Comptroller General on May 8, 2003. 
This report provides specific details on our assessment results. Our 
overall assessment of DOD's initial architecture was issued on July 7, 
2003,[Footnote 43] which satisfied the legislative requirement that we 
submit a report to congressional defense committees within 60 days of 
the architecture's approval.

Consistent with the act and as agreed with congressional defense 
committees' staffs, this assessment focused on (1) compliance with all 
federal accounting, financial management, and reporting requirements, 
(2) the content of the "As Is" and "To Be" environments, (3) the 
content of the transition plan to include time-phased milestones for 
phasing out existing systems, resource needs for implementing the "To 
Be" environment, and information on the systems inventory, and (4) the 
extent to which DOD is controlling its business system investments. In 
addition, we used our Enterprise Architecture Management Maturity 
Framework[Footnote 44] that describes the five stages of management 
maturity to determine the extent to which DOD has adopted key elements 
of architecture management best practices. To make this determination, 
we reviewed program documentation, such as program policies and 
procedures, steering and executive committee charters, and architecture 
products, and compared them to the elements in the framework. We did 
not validate the cost and budget information provided by the program's 
budget analyst.

Specific to our review of federal requirements, we could not determine 
whether the architecture contained all federal accounting, financial 
management, and reporting requirements because a central repository of 
all such requirements does not exist. Nevertheless, to assess the 
completeness of the federal requirements, we compared the about 4,000 
external requirements[Footnote 45] contained in the architecture to 
those listed in selected JFMIP federal systems requirements 
publications.[Footnote 46] Of the 4,000 external requirements 
incorporated in the initial architecture, we performed a detailed 
review of 1,767 (about 45 percent), all of which were JFMIP 
requirements. Specifically, we identified whether these requirements 
were incorporated in the initial architecture, relevant to DOD's 
business operations, or were current. To supplement our documentation 
review, we held interviews with government and contractor officials 
from the Office of the Under Secretary of Defense (Comptroller) and 
IBM.

For our review of the architecture,[Footnote 47] our internal team of 
architecture experts identified relevant criteria to be used to assess 
the architecture products, including best practices and federal 
guidance.[Footnote 48]

In reviewing the criteria, these experts categorized the key 
requirements according to their relevance to the three primary 
component parts of the architecture specified in the act and recognized 
in best practices and federal guidance: the "As Is" architecture, the 
"To Be" architecture, and the transition plan. For ease of reporting, 
they further divided the "As Is" and "To Be" architectures into five 
architectural components similar to OMB's architecture reference 
models: business, information/data, services/applications, technical, 
and performance. We added security as a sixth component because of its 
recognized importance in the various architecture frameworks and 
relevance to the other five architectural components. For each of these 
six architectural components, we identified the key architectural 
requirements that would need to be addressed for the "As Is" and "To 
Be" environments for the department to create an architecture that 
would be effective in facilitating its business modernization efforts 
and documented this information in detailed matrices. These experts 
also identified the key architectural requirements for the transition 
plan component of the architecture, which were also documented in a 
detailed matrix. We then compared the architecture products including 
the transition plan against the identified criteria governing their 
content and documented the results of our analysis in the matrices.

We interviewed program officials, including the program director, the 
Chief Architect, and contractor staff (IBM and MITRE) to discuss our 
preliminary findings and to clarify the intended scope and purpose of 
this version of the architecture. We also participated in a 2-day 
architecture walkthrough in which DOD officials provided a progress 
update on the department's development of the architecture and future 
plans for further evolution and implementation of the architecture. In 
addition, we reviewed the program's verification and validation 
contractor's (MITRE) report[Footnote 49] documenting its assessment of 
version 1.0 of the architecture including the transition plan. We also 
interviewed program officials as to the department's plans for 
addressing MITRE's comments.

To review DOD's actions to comply with the conditions for obligations 
in excess of $1 million for financial system improvements, we obtained 
and reviewed memorandums and other documentation regarding the approval 
of expenditures for system investments in excess of $1 million. We also 
reviewed and analyzed the DOD IT budget requests for fiscal years 2003 
and 2004 to identify systems that met the $1 million threshold and 
compared this to the total number of systems DOD reviewed and approved 
to measure DOD's progress in reviewing those systems that meet the 
legislative threshold. To augment our document reviews and analyses, we 
interviewed officials from various DOD organizations, including the 
Office of the Under Secretary of Defense (Comptroller); Office of the 
Under Secretary of Defense (Acquisition, Technology, and Logistics); 
and the Office of the Under Secretary of Defense (Personnel and 
Readiness).

To determine DOD's plans for further development and implementation of 
the architecture, we reviewed the initial transition plan and IBM's 
statement of work, DOD's proposed governance concept, and program 
documentation pertaining to plans for implementing pilot projects. We 
also reviewed DOD's response to the recommendations we made in our 
February 2003 report[Footnote 50] pertaining to controlling ongoing and 
planned IT systems investments. To augment our document reviews and 
analyses, we interviewed government and contractor officials from the 
Office of the Under Secretary of Defense (Comptroller) and IBM.

We conducted our work primarily at DOD headquarters offices in 
Washington, D.C., and Arlington, Virginia, and we performed our work 
from March 2003 through June 2003 in accordance with U.S. generally 
accepted government auditing standards. We requested comments on a 
draft of this report from the Secretary of Defense or his designee. 
Written comments from the Under Secretary of Defense (Comptroller) are 
addressed in the "Agency Comments and Our Evaluation" section of this 
report and are reprinted in appendix IV.

:

[End of section]

Appendix III: Status of Prior Recommendations on DOD's Business 
Enterprise Architecture:

[See PDF for image]

Source: GAO analysis of DOD data.

[End of table]

[End of section]

Appendix IV: Comments from the Department of Defense:

COMPTROLLER:

UNDER SECRETARY OF DEFENSE 1 100 DEFENSE PENTAGON WASHINGTON DC 20301-
1100:

AUG 1 8 2003:

Mr. Gregory Kutz Director:

Financial Management and Assurance United States General Accounting 
Office Washington, DC 20548:

Dear Mr. Kutz:

Enclosed is the Department of Defense (DoD) response to the General 
Accounting Office (GAO) Draft Report, "DoD Business Systems 
Modernization: Important Progress Made to Develop Business Enterprise 
Architecture, But Much Work Remains," dated July 21, 2003, (GAO-03-
1018). The Department concurs or partially concurs with all 10 of the 
GAO's recommendations for corrective action.

My point of contact for this matter is Ms. Marilyn Fleming, Chief 
Architect, Directorate for Business Modernization and Systems 
Integration. She may be contacted by email: flemingm@osd.pentagon.mil 
or by telephone at (703) 607-3367.

Sincerely,

Signed by: 

Dov S. Zakheim:

Enclosure: As stated:

DoD Response to Draft GAO Report: "DoD Business Systems Modernization: 
Important Progress Made to Develop Business Enterprise Architecture, 
But Much Work Remains," dated July 21, 2003, (GAO-03-1018):

1. GAO Recommendation: The Secretary of Defense implement the core 
elements in our EA Framework for Assessing and Improving Enterprise 
Architecture Management that we identify in this report as not 
satisfied, including ensuring that minutes of the executive body 
charged with directing, overseeing, and approving the architecture are 
prepared and maintained.

DoD Response to GAO Recommendation 1: Concur. The Department of Defense 
(DoD) is taking steps to meet our near-term goal of achieving Stage 2 
compliance with the GAO Enterprise Architecture Framework. A letter has 
been prepared that designates the Business Management Modernization 
Program (BMMP) Executive Committee as the body responsible for guiding, 
directing, and approving the Business Enterprise Architecture (BEA). 
Minutes of future Executive Committee meetings will be prepared and 
maintained. In addition, while the Department believes that policy for 
the DoD BEA already exists, the Information Technology Portfolio 
Management (ITPM) policy currently being developed will identify the 
major proponents in the architecture process and further define 
responsibilities. Also in development are charters for the BEA 
Architecture Review Board and the Configuration Control Board. For 
those framework elements related to the "As-Is" architecture that the 
GAO has noted as not satisfied, the Department intends to address those 
elements, as deemed necessary, when we extend the architecture within 
our overall incremental approach.

2. GAO Recommendation: The Secretary of Defense update version 1.0 of 
the architecture to include the 340 Joint Financial Management 
Improvement Program (JFMIP) requirements that our report identified as 
omitted or not fully addressed.

DoD Response to GAO Recommendation 2: Concur. The Department has 
updated version 1.0 of the architecture, to address basic errors and 
omissions. Version 1.1 of the BEA now includes JFMIP requirement 
controls (such as revenue and other controls) that were identified by 
GAO as being missing or only partially addressed. Furthermore, Version 
1.1 of the BEA includes the new FASAB Standard #23.

3. GAO Recommendation. The Secretary of Defense update version 1.0 of 
the architecture to include the 29 key elements governing the "As Is" 
architectural content that our report identified as not being fully 
satisfied.

DoD Response to GAO Recommendation 3: Partially concur. Because the 
current operating environment is dynamic, complete satisfaction of the 
29 key elements governing the "As Is" architectural content is not 
realistically achievable. Such data, if it were possible to obtain, 
might be obsolete upon arrival. The Department, therefore, does not 
deem the effort to obtain such data to be cost effective. The DoD 
currently is analyzing the referenced 29 key elements, and will 
leverage them effectively, where appropriate, in the further 
development of the architecture. The Department will collect relevant 
"As Is" documentation as part of its incremental 
development of the BEA. This "As Is" data also will be included in 
future incremental releases of the architecture.

4. GAO Recommendation: The Secretary of Defense update version 1.0 of 
the business enterprise architecture to include the 30 key elements 
governing the "To Be" architectural content that our report identified 
as not being fully satisfied.

DoD Response to GAO Recommendation 4: Concur. The Department is 
developing the BEA on an incremental basis in accordance with the 
Architecture Development Methodology (ADM). (The Architecture 
Methodology Report for Global Information Grid/Federal Enterprise 
Architecture (GIG/FEA) Integration describes the Department's 
methodology for alignment of the BEA with FEA reference models.) The 
DoD currently is analyzing the 30 key elements governing the "To Be" 
architectural content, and will satisfy fully all or most of these 
elements by the next significant delivery of the BEA (currently planned 
for May 2004). The DoD will incorporate pertinent elements of the FEA 
reference models during the planned extension and evolution of the 
architecture. Each increment of the BEA will align more fully with the 
FEA reference models, so that by the time the BEA is complete, it will 
contain all pertinent elements of the FEA reference models.

5. GAO Recommendation: The Secretary of Defense update version 1.0 to 
ensure that "To Be" architecture artifacts are internally consistent, 
to include addressing the inconsistencies described in this report, as 
well as including user instructions or guidance for easier architecture 
navigation and use.

DoD Response to GAO Recommendation 5: Concur. The Department will 
investigate all deliverables to determine what inconsistencies 
materially impact the BEA, and DoD will correct those inconsistencies. 
As future increments of the BEA are released, the Department will 
ensure that no inconsistencies exist between dependencies, such as 
between the narrative and the models. The DoD currently provides 
instruction for navigating the BEA to users, such as System Architect 
Users Guide, Extensibility Guide, Conversion Guide, Popkin Process 
Guide, and a Tutorial Guide. This instruction is available on the BEA 
web portal. During the architecture refinement process, DoD will assess 
various architectural tool mixes to determine if we could make 
navigation of the BEA easier.

6. GAO Recommendation: The Secretary of Defense update version 1.0 of 
the architecture to include (1) the 3 key elements governing the 
transition plan content that our report identified as not being fully 
satisfied and (2) those system investments that will not become part of 
the "To Be" architecture, including timeframes for phasing out those 
systems.

DoD Response to GAO Recommendation 6: Concur. Our transition approach 
focuses on deploying the architecture in increments by reengineering 
DoD's current inefficient business processes and installing system 
solutions that implement leading business practices. We will eliminate 
from our current inventory of systems those that have redundant 
capability and those that are not compliant with the BEA. Based on best 
business practices, this reengineering effort and acquiring and 
deploying systems will be done incrementally, and based on the size and 
complexity of DoD, we expect it will take about ten years.

The first increment will begin implementing the architecture and its 
key business processes and technical standards. Examples of the 
processes and standards in the first increment include the United 
States Standard General Ledger, a standard accounting code structure, 
data standards, data storage and retrieval, and the integration of 
logistics business processes with the related acquisition and 
accounting processes.

As the Department moves into the reengineering phase for each 
Increment, the updated BEA Transition Plan will continue to identify 
the needed changes to current business processes and systems by 
Increment. As both the BEA and the Transition Plan mature for each 
Increment, the analysis will become more specific and refined. As a 
result, DoD will then identify which business systems will not be part 
of the "To Be" architecture. At that time, a plan for phasing out those 
systems will be completed.

7. GAO Recommendation: The Secretary of Defense update version 1.0 of 
the architecture to address comments made by the verification and 
validation contractor.

DoD Response to GAO Recommendation 7: Concur. The Department has 
reviewed and agrees with the comments provide by MITRE, the referenced 
Independent Verification and Validation (IV&V) contractor. The BEA 
Version 1.0 will be updated, in subsequent versions, to address the 
comments provided by MITRE.

8. GAO Recommendation: The Secretary of Defense define and implement an 
effective investment management process to proactively identify, 
control, and obtain DoD Comptroller review and approval of expenditures 
for new and ongoing business system investments exceeding $1 million 
while the architecture is being developed and after it is completed, 
and which includes clearly defined domain owners' roles and 
responsibilities for selecting and controlling ongoing and planned 
system investments.

DoD Response to GAO Recommendation 8: Concur. The Department is 
finalizing the "Information Technology Portfolio Management (ITPM)" 
policy for managing information technology (IT) investments. The 
document establishes policies and assigns responsibilities for the 
management of DoD IT and associated investments. This policy will be 
supplemented by a DoD Instruction, which will provide detailed guidance 
and procedures for implementing the ITPM. Implementation of the ITPM 
policy and procedures will take place in FY 2004.

9. GAO Recommendation: The Secretary of Defense develop a well-defined 
near-term plan for extending and evolving the architecture and ensure 
that this plan includes addressing our recommendations, defining roles 
and responsibilities of all stakeholders involved in extending and 
evolving the architecture, explaining dependencies among planned 
activities, and defining measures of activity progress.

DoD Response to GAO Recommendation 9: Concur. The Department is 
developing a detailed plan for Increment 1 (business process 
reengineering). First, DoD is finalizing the Architecture Development 
Methodology (ADM). The ADM is the near-term plan to extend and 
evolve the architecture. It explains the dependencies among the planned 
activities for architecture evolution. The ADM also discusses the task 
to define measures of activity progress.

The Department also is developing Domain Plans, which extend the ADM 
into the Domains. The Domain Plans also define roles and 
responsibilities of all Domain Owner stakeholders. A framework Domain 
Plan was delivered in August 2003. We are working on developing a 
detailed plan of action and milestones for extending the Increment I of 
the BEA into the Domains. The first version of Domain-specific plans 
are planned to be completed by the end of the first quarter of FY 2004.

10. GAO Recommendation: The Secretary of Defense limit the pilot 
projects to small, low-cost, low-risk prototype investments that are 
intended to provide knowledge needed to extend and evolve the 
architecture, and are not to acquire and implement production version 
system solutions or to deploy an operational system capability.

DoD Response to GAO Recommendation 10: Concur. The Department's pilot 
initiatives will test and prove the ADM through a limited number of 
small, low cost, low risk prototype investments. These pilot 
initiatives also will demonstrate how Increment I of the BEA has 
achieved improvements in DoD operations.

[End of section]

Appendix V: GAO Contacts and Staff Acknowledgments:

GAO Contacts:

Jenniffer Wilson, (202) 512-9192 Cynthia Jackson, (202) 512-5086:

Acknowledgments:

In addition to the individuals named above, key contributors to this 
report included Beatrice Alff, Nabajyoti Barkakati, Justin Booth, 
Francine Delvecchio, Francis Dymond, Jason Kelly, Neelaxi Lakhmani, Anh 
Le, Evelyn Logue, Mai Nguyen, Darby Smith, Stacey Smith, Alan Steiner, 
Randolph Tekeley, William Wadsworth, and James Weidner.

(192100):

FOOTNOTES

[1] U.S. General Accounting Office, Information Technology: 
Architecture Needed to Guide Modernization of DOD's Financial 
Operations, GAO-01-525 (Washington, D.C.: May 17, 2001).

[2] Bob Stump National Defense Authorization Act for Fiscal Year 2003, 
Pub. L. No. 107-314, ß 1004, 116 Stat. 2458, 2629, Dec. 2, 2002.

[3] In May 2003, the DOD Comptroller changed the architecture name from 
the Financial Management Enterprise Architecture to the BEA to reflect 
the transformation of departmentwide business operations and supporting 
systems, including accounting and finance, budget formulation, 
acquisition, inventory management, logistics, personnel, and property 
management systems.

[4] U.S. General Accounting Office, Business Systems Modernization: 
Summary of GAO's Assessment of Department of Defense's Initial Business 
Enterprise Architecture, GAO-03-877R (Washington, D.C.: July 7, 2003).

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

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

[7] 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 Circular A-130, Management of Federal Information 
Resources (Nov. 28, 2000); M.A. Cook, Building Enterprise Information 
Architectures: Reengineering Information Systems (Upper Saddle River, 
N.J., Prentice Hall: 1996); and National Institute of Standards and 
Technology, Information Management Directions: The Integration 
Challenge, Special Publication 500-167 (September 1989).

[8] Business systems include financial and nonfinancial systems, such 
as civilian personnel, finance, health, logistics, military personnel, 
procurement, and transportation, with the common element being the 
generation or use of financial data to support DOD's business 
operations.

[9] U.S. General Accounting Office, High Risk Series: An Update, GAO-
03-119 (Washington, D.C.: January 2003); U.S. General Accounting 
Office, High Risk Series: Strategic Human Capital Management, GAO-03-
120 (Washington, D.C.: January 2003); U.S. General Accounting Office, 
High Risk Series: Protecting Information Systems Supporting the Federal 
Government and the Nation's Critical Infrastructures, GAO-03-121 
(Washington, D.C.: January 2003); and U.S. General Accounting Office, 
High Risk Series: Federal Real Property, GAO-03-122 (Washington, D.C.: 
January 2003).

[10] U.S. General Accounting Office, DOD Financial Management: 
Important Steps Underway But Reform Will Require a Long-term 
Commitment, GAO-02-784T (Washington, D.C.: June 4, 2002).

[11] U.S. General Accounting Office, Department of Defense: Status of 
Financial Management Weaknesses and Progress Toward Reform, GAO-03-931T 
(Washington D.C.: June 25, 2003).

[12] The Clinger-Cohen Act of 1996, Pub. L. No. 104-106, Div. E, Title 
LI, sections 5122 and 5125, 110 Stat. 679, 683-85, Feb. 10, 1996 
(codified, as amended, at 40 U.S.C. sections 11312 and 11315(b)(2)).

[13] OMB Circular No. A-130, Management of Federal Information 
Resources (Nov. 28, 2000).

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

[15] 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.: February 2003); U.S. General Accounting Office, Information 
Technology: DLA Should Strengthen Business Systems Modernization 
Architecture and Investment Activities, GAO-01-631 (Washington, D.C.: 
June 2001); and U.S. General Accounting Office, Information Technology: 
INS Needs to Better Manage the Development of Its Enterprise 
Architecture, AIMD-00-212 (Washington, D.C.: August 2000).

[16] GAO-01-525.

[17] GAO-03-458.

[18] U.S. General Accounting Office, Information Technology: 
Observations on Department of Defense's Draft Enterprise Architecture, 
GAO-03-571R (Washington, D.C.: Mar. 28, 2003).

[19] GAO-03-584G.

[20] Chief Information Officer Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001).

[21] GAO-03-584G.

[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 Circular A-130, Management of Federal Information 
Resources (Nov. 28, 2000); M.A. Cook, Building Enterprise Information 
Architectures: Reengineering Information Systems (Upper Saddle River, 
N.J., Prentice Hall: 1996); and National Institute of Standards and 
Technology, Information Management Directions: The Integration 
Challenge, Special Publication 500-167 (September 1989).

[23] JFMIP is a joint undertaking of the Department of the Treasury, 
GAO, the Office of Management and Budget, and the Office of Personnel 
Management, working with each other, other agencies, and the private 
sector to improve financial management in the federal government. JFMIP 
issues a series of requirements in support of agency operations.

[24] National Defense PP&E assets include weapons systems and support 
PP&E owned by DOD or its component entities for use in the performance 
of military missions.

[25] SFFAS No. 23, Eliminating the Category National Defense Property, 
Plant, and Equipment, May 2003.

[26] The three sponsoring agencies are the Department of the Treasury, 
the Office of Management and Budget, and the General Accounting Office.

[27] The consumption method of accounting requires operating materials 
and supplies to be capitalized when purchased and reported as an 
operating expense when they are consumed. Under the purchases method, 
operating materials and supplies are reported as an operating expense 
when they are purchased if their amounts are insignificant, they are in 
the hands of the end user for use in normal operations, or it is not 
cost effective to apply the consumption method.

[28] Subsection 1004(b)(2) of the act also specifies that DOD's 
enterprise architecture shall "include policies, procedures, data 
standards, and system interface requirements that are to apply 
uniformly throughout the Department."

[29] 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); Cook, M.A., 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).

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

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

[32] The Computer Security Act of 1987, Pub. L. No. 100-235, 101 Stat. 
1724, Jan. 8, 1988.

[33] 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); Cook, M.A., 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).

[34] Troux Technologies, Inc. http://www.eacommunity.com/sponsor/
troux_061903.htm.

[35] 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); Cook, M.A., 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).

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

[37] Section 1004 of Public Law 107-314.

[38] MITRE Technical Report: Review of Financial Management Enterprise 
Architecture (FMEA), Version 1.0 (June 2003).

[39] See the background section of this report for a description of 
OMB's Federal Enterprise Architecture.

[40] GAO-01-525.

[41] GAO-03-458.

[42] GAO-03-571R.

[43] GAO-03-877R.

[44] GAO-03-584G.

[45] External requirements are those that are obtained from 
authoritative sources and constrain various aspects of the 
architecture.

[46] We used nine JFMIP systems requirements documents: JFMIP-SR-03-01, 
Revenue System Requirements (January 2003); JFMIP-SR-02-02, 
Acquisition/Financial Systems Interface Requirements (June 2002); 
JFMIP-SR-02-01, Core Financial System Requirements (November 2001); 
JFMIP-SR-99-5, Human Resources & Payroll Systems Requirements (April 
1999); JFMIP-FFMSR-8, System Requirements for Managerial Cost 
Accounting (February 1998); JFMIP-FFMSR-7, Inventory System 
Requirements (June 1995); JFMIP-SR-99-9, Travel System Requirements 
(July 1999); JFMIP-SR-00-4, Property Management Systems Requirements 
(October 2000); JFMIP-SR-01-01, Benefit System Requirements (September 
2001).

[47] We reviewed version 1.0 of DOD's BEA including the transition 
plan, which was completed on April 30, 2003, and according to program 
officials, approved on May 8, 2003, by the department's Comptroller.

[48] 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 (Upper 
Saddle River, N.J., Prentice Hall: 1996); and National Institute of 
Standards and Technology, Information Management Directions: The 
Integration Challenge, Special Publication 500-167 (September 1989).

[49] MITRE Technical Report: Review of Financial Management Enterprise 
Architecture (FMEA), Version 1.0 (June 2003).

[50] GAO-03-458.

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: