This is the accessible text file for GAO report number GAO-06-219 
entitled 'DOD Business Systems Modernization: Important Progress Made 
in Establishing Foundational Architecture Products and Investment 
Management Practices, but Much Work Remains' which was released on 
November 23, 2005. 

This text file was formatted by the U.S. Government Accountability 
Office (GAO) to be accessible to users with visual impairments, as part 
of a longer term project to improve GAO products' accessibility. Every 
attempt has been made to maintain the structural and data integrity of 
the original printed product. Accessibility features, such as text 
descriptions of tables, consecutively numbered footnotes placed at the 
end of the file, and the text of agency comment letters, are provided 
but may not exactly duplicate the presentation or format of the printed 
version. The portable document format (PDF) file is an exact electronic 
replica of the printed version. We welcome your feedback. Please E-mail 
your comments regarding the contents or accessibility features of this 
document to Webmaster@gao.gov. 

This is a work of the U.S. government and is not subject to copyright 
protection in the United States. It may be reproduced and distributed 
in its entirety without further permission from GAO. Because this work 
may contain copyrighted images or other material, permission from the 
copyright holder may be necessary if you wish to reproduce this 
material separately. 

Report to Congressional Committees: 

November 2005: 

DOD Business Systems Modernization: 

Important Progress Made in Establishing Foundational Architecture 
Products and Investment Management Practices, but Much Work Remains: 

GAO-06-219: 

GAO Highlights: 

Highlights of GAO-06-219, a report to congressional committees. 

Why GAO Did This Study: 

For many years, the Department of Defense (DOD) has been attempting to 
modernize its business systems, and GAO has made numerous 
recommendations to help it do so. To further assist DOD, Congress 
included provisions in the Ronald W. Reagan National Defense 
Authorization Act for Fiscal Year 2005 aimed at ensuring that DOD 
develop a well-defined business enterprise architecture and transition 
plan by September 30, 2005, as well as establish and implement 
effective structures and processes for managing information technology 
(IT) business system investments. 

In response to the act’s mandate, GAO is reporting on DOD’s compliance 
with requirements relating to DOD’s architecture, transition plan, 
budgetary disclosure, and business system review and approval 
structures and processes. Given GAO’s existing recommendations, it is 
not making additional recommendations at this time. In comments on a 
draft of this report, DOD recognized that GAO has been a constructive 
player in its business transformation efforts. While not specifically 
commenting on most of the report’s findings and its conclusions, DOD 
also said that it disagreed with two points: the level of development 
for its “As Is” architecture and instances of nonintegration within the 
architecture and transition plan. However, it also commented that it is 
committed to addressing what GAO views to be the underlying basis of 
both points. 

What GAO Found: 

In its efforts to comply with the act’s provisions, DOD has made 
important progress in establishing needed modernization management 
capabilities. However, much more remains to be done. 
* The latest version of the business enterprise architecture (Version 
3.0), which the department approved on September 28, 2005, partially 
satisfies the conditions of the act, but not entirely. For example, 
while Version 3.0 includes a target or “To Be” architecture, as 
required, it does not include a current (“As Is”) architecture. Without 
this element, DOD could not analyze the gaps between the two 
architectures—critical input to a comprehensive transition plan. 
However, this version of the architecture represents significant 
progress and provides a foundation upon which the department can build.
* The transition plan associated with the current version of the 
architecture partially satisfies the act, but improvements are needed. 
Specifically, although it includes certain required information (such 
as milestones for major projects), it is inconsistent with the 
architecture in various ways. For instance, it identifies target 
systems (those that are to be included in the “To Be” architecture), 
but these are not always the same as those identified in the 
architecture itself. In addition, the transition plan does not include 
system performance metrics aligned with the plan’s strategic goals and 
objectives.
* The department’s fiscal year 2006 budget discloses some but not all 
required information. For example, it does not identify the approval 
authority for all business systems investments.
* DOD has satisfied some of the act’s requirements regarding its 
business systems investments, but it either has not satisfied or is 
still in the process of satisfying others. For example, the department 
has fulfilled the act’s requirement for delegating IT system 
responsibility and accountability to designated approval authorities as 
specified. In addition, DOD has largely satisfied the act’s requirement 
to establish certain structures and define certain processes to review 
and approve IT investments. However, some of these structures are not 
yet in place, and some reviews and approvals to date have not followed 
the criteria in the act. 
DOD agrees that additional work is required and states that under its 
incremental approach to developing the architecture and transition 
plan, and under its tiered accountability structure for reviewing and 
approving business system investments, improvements will occur in its 
architecture, transition plan, budgetary disclosure, and investment 
management and oversight. If these improvements do not occur, DOD’s 
business systems modernization will continue to be a high-risk program. 

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

[End of section] 

Contents: 

Letter: 

Results in Brief: 

Background: 

DOD Has Satisfied Requirements in Its Fiscal Year Authorization Act to 
Varying Degrees: 

Conclusions: 

Agency Comments and Our Evaluation: 

Appendixes: 

Appendix I: Objective, Scope, and Methodology: 

Appendix II: Comments from the Department of Defense: 

Appendix III: Summary of Several Architecture Frameworks: 

Appendix IV: List of the DOD Architecture Framework Products: 

Appendix V: GAO Contact and Staff Acknowledgments: 

Tables: 

Table 1: Compliance with Act's Provisions: 

Table 2: Roles and Responsibilities of Governance Entities: 

Table 3: Core Business Missions and Associated Principal Staff 
Assistants: 

Table 4: Descriptions of Business Enterprise Priorities: 

Table 5: DOD Architecture Framework Products Included in Version 3.0: 

Table 6: Systems Receiving DBSMC Approval under Prior Criteria: 

Figures: 

Figure 1: Interdependent DODAF Views of an Architecture: 

Abbreviations: 

ASD(NII)/CIO: Assistant Secretary of Defense (Networks and Information 
Integration)/Chief Information Officer: 

AV: all view: 

BEIS: Business Enterprise Information Services: 

BTA: Business Transformation Agency: 

CIO: Chief Information Officer: 

DBSMC: Defense Business Systems Management Committee: 

DCAS: Defense Cash Accountability System: 

DIMHRS: Defense Integrated Military Human Resources System: 

DITPR: DOD Information Technology Portfolio Data Repository: 

DOD: Department of Defense: 

DODAF: Department of Defense Architecture Framework: 

ECSS: Expeditionary Combat Support System: 

FEA: Federal Enterprise Architecture: 

FEAF: Federal Enterprise Architecture Framework: 

FMSE: Financial Management System Entity: 

IT: information technology: 

JFMIP: Joint Financial Management Improvement Program: 

MOCAS: Mechanization of Contract Administration Services:: 

OMB: Office of Management and Budget: 

OPM: Office of Personnel Management: 

OV: operational view: 

SACS: Standard Accounting Classification Structure: 

SFIS: Standard Financial Information Structure: 

SV: systems view: 

TV: technical standards view: 

Letter:

November 23, 2005: 

Congressional Committees: 

For decades, the Department of Defense (DOD) has not been successful in 
repeated attempts to modernize its timeworn business systems[Footnote 
1] and operations. In 2001, the Secretary of Defense launched the 
latest attempt as part of a broad initiative to "transform the way the 
department works and what it works on." The Secretary has estimated 
that successful improvements to DOD business systems and operations 
could save the department 5 percent of its budget a year--potentially 
more than $20 billion a year in savings. 

In 1995, we first designated DOD's business systems modernization as 
high risk, and it remains so today.[Footnote 2] In May 2001, to help 
DOD transform its operations, we made eight recommendations to the 
Secretary of Defense that were aimed at providing the means for 
effectively developing and implementing an enterprise 
architecture[Footnote 3] and limiting systems investments by DOD 
components[Footnote 4] until the department had a well-defined 
architecture and the means to enforce it.[Footnote 5] We also 
recommended that DOD establish a corporate approach to investment 
control and decision making. In July 2001, the department initiated a 
business management modernization program with the aim, among others, 
of developing a business enterprise architecture and establishing the 
investment controls needed to effectively implement this architecture. 

In response to DOD's challenges on its modernization efforts, Congress 
included provisions in the defense authorization act for fiscal year 
2005[Footnote 6] that were aimed at ensuring DOD's development of a 
well-defined business enterprise architecture and associated enterprise 
transition plan by September 30, 2005, as well as establishment and 
implementation of effective information technology (IT) business system 
investment management structures and processes by various dates. More 
specifically, the act required the department to, among other things, 
(1) develop a business enterprise architecture, (2) develop a 
transition plan to implement the architecture, (3) establish a system 
investment approval and accountability structure, (4) establish an 
investment review process, (5) approve and certify system 
modernizations in excess of $1 million, and (6) include systems 
information in its annual budget submission. The act also directed us 
to submit to congressional defense committees--within 60 days of the 
Secretary of Defense's approval of the department's enterprise 
architecture and its transition plan--an assessment of DOD's actions 
taken to comply with these requirements. 

As agreed with your offices, our overall objective was to assess DOD's 
efforts to comply with the act's requirements. We performed our work 
from August through November 2005, in accordance with U.S. generally 
accepted government auditing standards. Details on our objective, 
scope, and methodology are contained in appendix I. 

Results in Brief: 

DOD has either complied, partially complied, or is in the process of 
complying with six requirements--related to strengthening its 
institutional approach to managing its business systems modernization 
efforts--that are specified in the Ronald W. Reagan National Defense 
Authorization Act for Fiscal Year 2005. Our assessment of DOD's degree 
of compliance with each is summarized in table 1. 

Table 1: Compliance with Act's Provisions: 

Summary of provision: By September 30, 2005, the department must 
develop a business enterprise architecture that meets certain 
requirements;
Satisfaction [A]: Partial.

Summary of provision: By September 30, 2005, the department must 
develop a transition plan for implementing the architecture that meets 
certain requirements;
Satisfaction [A]: Partial. 

Summary of provision: The department must identify each business system 
proposed for funding in its budget submission for fiscal year 2006 and 
subsequent fiscal years and identify funds for current services and for 
business systems modernization;
Satisfaction [A]: Partial. 

Summary of provision: The department must delegate the responsibility 
for business systems to designated approval authorities within the 
Office of the Secretary of Defense;
Satisfaction [A]: Yes.

Summary of provision: By March 15, 2005, the department must require 
each approval authority to establish an investment review process;
Satisfaction [A]: Partial.

Summary of provision: Effective October 1, 2005, the department may not 
obligate funds for a business system modernization with a cost 
exceeding $1 million unless it is certified by the approval authority 
and the certification is approved by the Defense Business Systems 
Management Committee as meeting specific requirements;
Satisfaction [A]: In process.

Source: GAO. 

[A] "Yes" means that the department has satisfied the act's 
requirements. "Partial" means that the department has satisfied some, 
but not all, aspects of the act's requirements. "In process" means that 
the department is taking steps to satisfy the act's requirements.

[End of table] 

The department's efforts to comply with the act represent important 
progress, but further steps are needed, particularly with regard to 
adding needed content and scope to the architecture and transition plan 
and ensuring that corporate investment management structures and 
processes are effectively implemented and full budgetary disclosure 
occurs. According to DOD, these additional steps will be taken as part 
of its incremental approach to developing the architecture and plan, 
and through the accountability framework that it has established for 
managing business system investments. Because our prior recommendations 
to the department already provide a roadmap for ensuring that these 
steps occur, we are not making additional recommendations at this time. 

In its written comments on a draft of this report, signed by the Deputy 
Under Secretary of Defense (Business Transformation) and reprinted in 
appendix II, the department recognized that our analysis, 
recommendations, guidance, and educational activities have made us a 
constructive player in DOD's business transformation efforts. The 
department also commented that it disagreed with two of our points. 

First, DOD commented that development of a "comprehensive 'As Is' 
architecture" would not be an effective use of time and resources and 
that the results of its examination of its "As Is" conditions are not 
required to be in the enterprise architecture. Notwithstanding these 
comments, DOD added that it understood that there needs to be an 
"easily traceable direct link" between the results of examining its "As 
Is" conditions and the "To Be" solutions, and that it was committed to 
documenting the "As Is" and "To Be" relationship in an appropriate 
manner. DOD's comments are largely consistent with our findings and 
prior recommendations. Specifically, we agree that DOD needs to 
document its "As Is" architecture, as we have previously recommended. 
Moreover, our prior recommendations have neither presumed nor 
prescribed a "comprehensiveness" standard in doing so, as we recognize 
that overdevelopment of an architecture would not be a cost-effective 
use of resources. Rather, our prior recommendations have focused on 
developing "As Is" architectural products in a manner that is 
consistent with widely accepted best practice and federal guidance. 

Second, DOD stated that most of our examples demonstrating a lack of 
integration within and between the business enterprise architecture and 
the transition plan are due to misunderstandings, and that it is 
committed to correcting them. We understand DOD's point, but would add 
that in cases where these examples (some explicit and others implicit) 
arise from lack of clarity in the architecture and transition plan, 
they would be more appropriately described as miscommunications. 
Moreover, we would emphasize that such miscommunications are directly 
attributable to ambiguity and inconsistencies in the architecture 
products and the transition plan that blur their intended meaning, 
which can lead to misunderstanding by both internal and external 
stakeholders. Given that a well-defined architecture is, among other 
things, clear and internally aligned, such ambiguity and inconsistency 
limit the utility and effectiveness of the products as reference tools 
for guiding and constraining system investment decisions. Accordingly, 
we agree with DOD's comment that addressing these limitations will 
create better transformation tools that will benefit all stakeholders, 
most importantly those within the department. 

Background: 

DOD is a massive and complex organization. In fiscal year 2004, the 
department reported that its operations involved $1.2 trillion in 
assets, $1.7 trillion in liabilities, over 3.3 million military and 
civilian personnel, and over $605 billion in net cost of operations. 
For fiscal year 2005, the department received appropriations of about 
$417 billion. The department comprises a wide range of organizations, 
including the military services and their respective major commands and 
functional activities, numerous defense agencies and field activities, 
and various combatant and joint operational commands, which are 
responsible for military operations for specific geographic regions or 
theaters of operations. 

In support of its military operations, the department performs an 
assortment of interrelated and interdependent business functions, 
including logistics management, procurement, health care management, 
and financial management. Earlier this year, DOD reported that, in 
order to support these business functions, it relied on about 4,200 
business systems, for which the department received approximately $13.3 
billion in fiscal year 2005 for operations, maintenance, and 
modernization. For fiscal year 2006, DOD received approximately $15.5 
billion to operate, maintain, and modernize its business systems. As we 
have previously reported,[Footnote 7] DOD's systems environment is 
overly complex and error prone and is characterized by (1) little 
standardization across the department, (2) multiple systems performing 
the same tasks, (3) the same data stored in multiple systems, and (4) 
the need for manual data entry into multiple systems. In addition, our 
reports[Footnote 8] continue to show that the department's 
nonintegrated and duplicative systems contribute to fraud, waste, and 
abuse. Of the 25 areas on GAO's governmentwide high-risk list, 8 are 
DOD program areas, and the department shares responsibility for 6 other 
governmentwide high-risk areas.[Footnote 9] DOD's business systems 
modernization is one of the high-risk areas. 

Enterprise Architecture and Information Technology Investment 
Management Are Critical to Achieving Successful Systems Modernization: 

Effective use of an enterprise architecture, or a modernization 
blueprint, is a hallmark of successful public and private 
organizations. For more than a decade, we have promoted the use of 
architectures to guide and constrain systems modernization, recognizing 
them as a crucial means to a challenging goal: agency operational 
structures that are optimally defined in both the business and 
technological environments. Congress, the Office of Management and 
Budget (OMB), and the federal Chief Information Officer (CIO) Council 
have also recognized the importance of an architecture-centric approach 
to modernization, and OMB and the CIO Council, in collaboration with 
us, have issued enterprise architecture guidance.[Footnote 10] The 
Clinger-Cohen Act of 1996[Footnote 11] mandates that an agency's CIO 
develop, maintain, and facilitate the implementation of an IT 
architecture. Further, the E-Government Act of 2002[Footnote 12] 
requires OMB to oversee the development of enterprise architectures 
within and across agencies. In addition, we and OMB have issued 
guidance that, among other things, emphasizes the need for system 
investments to be consistent with these architectures.[Footnote 13] 

A corporate approach to IT investment management is also characteristic 
of successful public and private organizations. Recognizing this, 
Congress developed and enacted the Clinger-Cohen Act in 1996,[Footnote 
14] which requires OMB to establish processes to analyze, track, and 
evaluate the risks and results of major capital investments in 
information systems made by executive agencies.[Footnote 15] In 
response to the Clinger-Cohen Act and other statutes, OMB developed 
policy for planning, budgeting, acquisition, and management of federal 
capital assets and issued guidance.[Footnote 16] We have also issued 
guidance in this area,[Footnote 17] which defines institutional 
structures, such as investment review boards, and associated processes, 
such as common investment criteria. 

Enterprise Architecture: A Brief Description: 

An enterprise architecture provides a clear and comprehensive picture 
of an entity, whether it is an organization (e.g., a federal 
department) 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" environment and 
its target or "To Be" environment. These snapshots consist of "views," 
which are one or more architecture products (e.g., models, diagrams, 
matrixes, and text) that provide logical or technical representations 
of the enterprise. The architecture also includes a transition or 
sequencing plan, which is based on an analysis of the gaps between the 
"As Is" and "To Be" environments; this plan provides a temporal roadmap 
for moving between the two environments that incorporates such 
considerations as technology opportunities, marketplace trends, fiscal 
and budgetary constraints, institutional system development and 
acquisition capabilities, new and legacy system dependencies and life 
expectancies, and the projected value of competing investments. 

The suite of products produced for a given entity's enterprise 
architecture, including their structure and content, are largely 
governed by the framework used to develop the architecture. Since the 
1980s, various architecture frameworks have emerged and been applied. 
Appendix III provides a discussion of these various frameworks. 

The importance of developing, implementing, and maintaining an 
enterprise architecture is a basic tenet of both organizational 
transformation and systems modernization. Managed properly, an 
enterprise architecture can clarify and help to optimize the 
interdependencies and relationships among an organization's business 
operations and the underlying IT infrastructure and applications that 
support these operations. To support effective architecture management 
in the federal government, we have issued architecture management 
guidance, as has the federal CIO Council and OMB.[Footnote 18] This 
guidance recognizes that when an enterprise architecture is 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 an organization's operational and 
IT environments will be configured to optimize its 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 19] 

IT Investment Management: A Brief Description: 

IT investment management is a process for linking IT investment 
decisions to an organization's strategic objectives and business plans. 
Generally, it includes structures (including decision-making bodies 
known as Investment Review Boards), processes for developing 
information on investments (such as costs and benefits), and practices 
to inform management decisions (such as whether a given investment is 
aligned with an enterprise architecture). The federal approach to IT 
investment management is based on establishing systematic processes for 
selecting, controlling, and evaluating investments that provides a 
systematic way for agencies to minimize risks while maximizing the 
returns of investments.[Footnote 20] 

* During the selection phase, the organization (1) identifies and 
analyzes each project's risks and returns before committing significant 
funds to any project and (2) selects those IT projects that will best 
support its mission needs. 

* During the control phase, the organization ensures that, as projects 
develop and investment expenditures continue, the project is continuing 
to meet mission needs at the expected levels of cost and risk. If the 
project is not meeting expectations or if problems have arisen, steps 
are quickly taken to address the deficiencies. 

* During the evaluation phase, actual versus expected results are 
compared once a project has been fully implemented. This is done to (1) 
assess the project's impact on mission performance, (2) identify any 
changes or modifications to the project that may be needed, and (3) 
revise the investment management process based on lessons learned. 

Consistent with our architecture management framework,[Footnote 21] our 
investment management framework[Footnote 22] recognizes the importance 
of an enterprise architecture as a critical frame of reference for 
organizations making IT investment decisions, stating that only 
investments that move the organization toward its target architecture, 
as defined by its sequencing plan, should be approved, unless a waiver 
is provided or a decision is made to modify the architecture. Moreover, 
this framework states that an organization's policies and procedures 
should describe the relationship between its architecture and its 
investment decision-making authority. 

Our experience has shown that mature and effective management of IT 
investments can vastly improve government performance and 
accountability, and can help to avoid wasteful IT spending and lost 
opportunities for improving delivery of services to the public. 

DOD's Business Systems Modernization Program History and Structure: 

The Business Management Modernization Program was established in July 
2001 in order to improve the efficiency and effectiveness of DOD's 
business operations through, among other things, the development and 
implementation of an architecture. When the program was initially 
established, the Secretary assigned oversight responsibility to the 
Under Secretary of Defense (Comptroller), in coordination with the 
Under Secretary of Defense for Acquisition, Technology, and Logistics 
and the Assistant Secretary of Defense (Networks and Information 
Integration)/Chief Information Officer. 

In 2001, the Comptroller established several governance bodies and 
assigned them responsibilities associated with developing, maintaining, 
and implementing the architecture. Specifically, the Comptroller 
established (1) the Executive and Steering Committees-- which were made 
up of senior leaders from across the department--to provide program 
guidance; (2) a program office to execute daily program activities 
necessary to develop, maintain, and implement the architecture; and (3) 
domain owners,[Footnote 23] who were responsible for achieving business 
transformation, implementing the architecture, developing and executing 
the transition plan, and performing portfolio management. In 2003, the 
Comptroller also established the Domain Owners Integration Team, which 
comprised various senior executives from each domain and the director 
of the program office. This team reported to the steering committee and 
was responsible for facilitating communication and coordination across 
the domains for program activities, including extending and evolving 
the architecture. 

In 2005, the department revised the program's governance structure. 
Program direction and oversight is now provided by the Deputy Secretary 
through the dual leadership of the Under Secretary of Defense for 
Acquisition, Technology, and Logistics and the Under Secretary of 
Defense (Comptroller). In addition, DOD has reassigned responsibility 
for providing executive leadership for the direction, oversight, and 
execution of its business transformation and systems modernization 
efforts to several entities. These entities include the Defense 
Business Systems Management Committee (DBSMC), which serves as the 
highest ranking governance body for business systems modernization 
activities; the Principal Staff Assistants, who serve as the 
certification authorities for business system investments in their 
respective core business missions; and the Investment Review Boards, 
which form the review and decision-making bodies for business system 
investments in their respective areas of responsibility. Table 2 lists 
these entities and their roles and responsibilities. 

Table 2: Roles and Responsibilities of Governance Entities: 

Entity: Defense Business Systems Management Committee (DBSMC);
Roles and responsibilities: 
* Provides strategic direction and plans for the business mission area, 
in coordination with the warfighting and enterprise information 
environment mission areas;
* Approves business mission area transformation plans and coordinates 
transition planning in a documented program baseline with critical 
success factors, milestones, metrics, deliverables, and periodic 
program reviews;
* Establishes key metrics and targets by which to track business 
transformation progress;
* Establishes policies and approves the business mission area strategic 
plan, the transition plan for implementation for business systems 
modernization, the transformation program baseline, and the business 
enterprise architecture;
* Executes a comprehensive communications strategy;

Membership: Chaired by the Deputy Secretary of Defense;
Vice Chair is the Under Secretary of Defense for Acquisition, 
Technology, and Logistics;
Includes senior leadership in the Office of the Secretary of Defense, 
the military services' secretaries, and defense agencies' heads, such 
as the Assistant Secretary of Defense (Networks and Information 
Integration)/Chief Information Officer (ASD(NII)/CIO), the Vice 
Chairman of the Joint Chiefs of Staff, and the Commanders of the U.S. 
Transportation Command and Joint Forces Command. 

Entity: Principal Staff Assistants;
Roles and responsibilities: 
* Support the DBSMC's management of enterprise business information 
technology investments;
* Serve as the certification authorities accountable for obligation of 
funds for respective business system investments within designated core 
business missions.[A];
* Provide the DBSMC with recommendations for system investment approval;

Membership: Officials who report directly to the Secretary or Deputy 
Secretary of Defense. These include the Under Secretaries of Defense;
the Assistant Secretaries of Defense;
the General Counsel of the Department of Defense;
the Assistants to the Secretary of Defense;
and the Directors of the Office of the Secretary of Defense. 

Entity: Investment Review Boards;
Roles and responsibilities: 
* Serve as the oversight and investment decision-making bodies for 
those business capabilities that support activities under their 
designated areas of responsibility;
* Assess investments relative to their impact on end-to-end business 
process improvements supporting warfighter needs;
* Certify that all business systems investments over $1 million are 
integrated and compliant with the business enterprise architecture;

Membership: Include the Deputy Secretary of Defense;
the Under Secretary of Defense (Comptroller);
Under Secretary of Defense for Acquisition, Technology, and Logistics;
Assistant Secretary of Defense (Personnel and Readiness);
ASD(NII)/CIO; military services; defense agencies; and combatant 
commands. 

Source: DOD. 

[A] The five core business missions are described in table 3.

[End of table] 

DOD has defined five departmentwide core business missions to be 
addressed through identification of corporate business needs and 
analysis of capability gaps. The core business missions transcend DOD's 
various functional areas (e.g., planning, budgeting, information 
technology, procurement, and maintenance) and are intended to be the 
means through which end-to-end warfighter support is delivered. 
Responsibility for the core business missions is assigned to specific 
Principal Staff Assistants. Table 3 provides descriptions of the core 
business missions and associated responsible parties. 

Table 3: Core Business Missions and Associated Principal Staff 
Assistants: 

DOD core business mission: Human Resources Management;
Description: This mission includes all human resources-related 
processes necessary to recruit, train, and prepare personnel for 
warfighter organizations. It also includes providing trained, healthy, 
and ready personnel to combatant and combat support organizations and 
ensuring timely and accurate access to compensation and benefits for 
all DOD personnel;
Principal Staff Assistants: Under Secretary of Defense (Personnel and 
Readiness). 

DOD core business mission: Weapon System Lifecycle Management;
Description: This mission includes full life-cycle management of 
Defense acquisition of weapons systems and automated information 
systems, including requirements, technology, development, production, 
and sustainment;
Principal Staff Assistants: Under Secretary of Defense for Acquisition, 
Technology, and Logistics. 

DOD core business mission: Materiel Supply and Service Management;
Description: This mission includes the management of supply chains of 
materiel supply and services to maintain the readiness of nondeployed 
and deployed warfighters to support operations. It also includes all 
aspects associated with acquiring, storing, and transporting all 
classes of supplies;
Principal Staff Assistants: Under Secretary of Defense for Acquisition, 
Technology, and Logistics. 

DOD core business mission: Real Property and Installations Lifecycle 
Management;
Description: This mission includes the provision of installations and 
facilities to house military forces, to store and maintain military 
equipment, and to serve as training and deployment platforms for 
dispatch of warfighter units;
Principal Staff Assistants: Under Secretary of Defense for Acquisition, 
Technology, and Logistics. 

DOD core business mission: Financial Management;
Description: This mission includes the provision of accurate and 
reliable financial information in support of the planning, programming, 
budgeting, and execution process to ensure adequate financial resources 
for warfighting mission requirements. It also includes providing 
information to reliably cost the conduct, output, and performance of 
DOD operations and missions and the programs to support them;
Principal Staff Assistants: Under Secretary of Defense (Comptroller). 

Source: DOD.

[End of table] 

On October 7, 2005, DOD established the Business Transformation Agency 
(BTA) to advance DOD-wide business transformation efforts, particularly 
with regard to business systems modernization. The BTA reports directly 
to the vice chair of the DBMSC.[Footnote 24] Among other things, the 
BTA includes a Defense Business Systems Acquisition Executive who is to 
be responsible for centrally managing 28 DOD-wide business projects, 
programs, systems, and initiatives.[Footnote 25] In addition, the BTA 
is to be responsible for integrating and supporting the work of the 
Office of the Secretary of Defense Principal Staff Assistants, who 
include the approval authorities that chair the business system 
investment review boards. Until a permanent director is named, the 
Deputy Under Secretary of Defense for Business Transformation and the 
Deputy Under Secretary of Defense for Financial Management will jointly 
function as directors and will report to the vice chair of the DBSMC. 

According to a program official, the department has spent approximately 
$440 million on the Business Management Modernization Program since it 
was established in 2001. 

Recent Reviews Have Assessed DOD's Efforts to Develop, Maintain, and 
Implement an Architecture: 

Since 2001, we have regularly reported on DOD's efforts to develop an 
architecture and to establish and implement effective investment 
management structures and processes.[Footnote 26] Our reports have 
continued to identify problems and raise concerns about the 
department's architecture program, the quality of the architecture and 
the transition plan, and the lack of an investment management structure 
and controls to implement the architecture. Our most recent reports, 
which were issued in the third and fourth quarters of fiscal year 2005, 
made the following points: 

* DOD had not established effective structures and processes for 
managing the development of its architecture. For example, the 
department had yet to finalize, approve, and effectively implement its 
plan, procedures, and charter governing the configuration management 
process.[Footnote 27] In addition, DOD had yet to establish an 
independent quality assurance function that addressed process standards 
and program performance. 

* DOD had not developed a well-defined architecture. The products that 
it had produced did not provide sufficient content and utility to 
effectively guide and constrain ongoing and planned systems 
investments. For example, the latest versions of the architecture did 
not include products describing the "As Is" business and technology 
environments. Further, although these versions included products 
describing the "To Be" environment, the descriptions were inadequate 
because the descriptions (1) did not have a clearly defined purpose 
that linked to the goals and objectives of the architecture; (2) were 
missing important content, such as the actual systems to be developed 
or acquired to support future business operations and the physical 
infrastructure needed to support the business systems; and (3) 
contained products that were neither consistent nor integrated. In 
short, the "To Be" environment lacked the detail needed to provide DOD 
with a common vision for defining the transition plan and informing 
investment decision making. 

* DOD had not developed a plan for transitioning from the "As Is" to 
the "To Be" architectural environments. The transition plan is based on 
an analysis of the gaps between these two environments and serves as an 
enterprisewide IT capital investment plan and acquisition strategy. 

* DOD did not have an effective departmentwide management structure for 
controlling its business investments. Although the department had 
established organizations to oversee its business system investments, 
these organizations were unable to do so, because the components 
controlled budget authority and continued to make their own parochial 
investment decisions. 

* DOD had not established common investment criteria for system 
reviews, and as a result different organizations were using different 
criteria. DOD also had not conducted a comprehensive review of its 
ongoing business system investments. 

* DOD had not included all of the reported systems in its fiscal year 
2005 IT budget request. It lacked accurate information on the costs and 
number of its business systems. 

* The Under Secretary of Defense (Comptroller) had not certified all 
systems investments with reported obligations exceeding $1 million, as 
required by the fiscal year 2003 National Defense Authorization 
Act.[Footnote 28] Obligations totaling about $243 million were made for 
systems modernizations in fiscal year 2004 that were not referred to 
the DOD Comptroller for the required review. 

DOD Has Satisfied Requirements in Its Fiscal Year Authorization Act to 
Varying Degrees: 

Section 2222 of Title 10, United States Code, as added by section 332 
of the defense authorization act for fiscal year 2005, cites six 
requirements that DOD is required to meet.[Footnote 29]Generally, these 
are as follows: 

1. By September 30, 2005, develop a business enterprise architecture 
that meets certain requirements. 

2. By September 30, 2005, develop a transition plan for implementing 
the architecture that meets certain requirements. 

3. Identify each business system proposed for funding in DOD's fiscal 
year 2006 and subsequent budget submissions and identify funds for 
current services and business systems modernization. 

4. Delegate the responsibility for business systems to designated 
approval authorities within the Office of the Secretary of Defense. 

5. By March 15, 2005, require each approval authority to establish a 
business system investment review process.[Footnote 30] 

6. Effective October 1, 2005, obligate funds for business system 
modernizations with a total cost exceeding $1 million only after the 
system is certified by the designated approval authority and the 
certification is approved by the DBSMC. 

DOD has partially satisfied the four legislative provisions relating to 
architecture development, transition plan development, budgetary 
disclosure, and investment review; it has satisfied the provision 
concerning designated approval authorities; and it is in the process of 
satisfying the provision for systems costing in excess of $1 million. 
According to DOD, the requirements of each provision will be fully 
implemented under its incremental approach to developing the 
architecture and transition plan, and its tiered accountability 
approach to business system investment management. Until they are, the 
department's business systems modernization program will continue to be 
a high-risk endeavor. 

Latest Version of Enterprise Architecture Partially Satisfies Act and 
Provides a Foundation upon Which to Add Missing Scope and Content: 

The defense authorization act for fiscal year 2005 requires DOD to 
develop a business enterprise architecture by September 30, 2005. 
According to the act, the architecture must satisfy three major 
requirements:[Footnote 31] 

1. It must include an information infrastructure that, at a minimum, 
would enable DOD to: 

* comply with all federal accounting, financial management, and 
reporting requirements; 

* routinely produce timely, accurate, and reliable financial 
information for management purposes; 

* integrate budget, accounting, and program information and systems; 
and: 

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

2. The architecture must include policies, procedures, data standards, 
and system interface requirements that are to be applied uniformly 
throughout the department. 

3. The architecture must be consistent with OMB policies and 
procedures. 

On September 28, 2005, the Acting Deputy Secretary of Defense approved 
Version 3.0 of the business enterprise architecture. According to DOD, 
this version is intended to provide a blueprint to help ensure near- 
term delivery of the right capabilities, resources, and materiel to the 
warfighter. To do so, this version focused on six business enterprise 
priorities, which DOD states are short-term objectives to achieve 
immediate results. These priorities are Personnel Visibility, 
Acquisition Visibility, Common Supplier Engagement, Materiel 
Visibility, Real Property Accountability, and Financial Visibility. 
According to DOD, these priorities will evolve and expand in future 
versions of the architecture. Table 4 provides a brief description of 
each of the six business enterprise priorities. 

Table 4: Descriptions of Business Enterprise Priorities: 

Business enterprise priority: Personnel Visibility;
Description of priority and expected benefits of achieving it: 
Providing access to reliable, timely, and accurate personnel 
information for warfighter mission planning. Benefits include accurate 
and timely access to compensation, decreased operation costs, reduced 
cycle times, and better management of DOD human resources in a combined 
(military, civilian, and contract support) environment. 

Business enterprise priority: Acquisition Visibility;
Description of priority and expected benefits of achieving it: 
Providing transparency and access to acquisition information that is 
critical to supporting life-cycle management of the department's 
processes for delivering weapon systems and automated information 
systems. Benefits include cost savings in consumables, manpower, and 
infrastructure; ability to share information that is accurate, 
relevant, and consistent; and reduced acquisition and management 
oversight workloads at all levels. 

Business enterprise priority: Common Supplier Engagement;
Description of priority and expected benefits of achieving it: Aligning 
and integrating policies, processes, data, technology, and people to 
simplify and standardize the methods that DOD uses to interact with 
commercial and government suppliers. Benefits include reliable and 
accurate delivery of acceptable goods and services to the warfighter, 
reduced backlogs, and the elimination of redundant program-specific 
reporting systems. 

Business enterprise priority: Materiel Visibility;
Description of priority and expected benefits of achieving it: 
Improving supply chain performance. Benefits include timely and 
accurate information on the location, movement, status, and 
identification of materiel and supplies for the warfighter. 

Business enterprise priority: Real Property Accountability;
Description of priority and expected benefits of achieving it: 
Acquiring access to real-time information on DOD real property assets. 
Benefits include increased access to more reliable, accurate real 
property information and decreased operational costs. 

Business enterprise priority: Financial Visibility;
Description of priority and expected benefits of achieving it: 
Providing immediate access to accurate and reliable financial 
information that will enhance efficient and effective decision making. 
Benefits include standardized financial data and reporting processes 
that enable decision makers to reliably evaluate program options and 
resource constraints. 

Source: DOD.

[End of table] 

In addition to focusing the scope of Version 3.0 of the architecture on 
these priorities, the extent to which each priority was to be 
addressed, according to DOD, was limited to answering four key 
questions: 

* Who are our people, what are their skills, and where are they 
located? 

* Who are our industry partners, and what is the state of our 
relationship with them? 

* What assets are we providing to support the warfighter, and where are 
these assets deployed? 

* How are we investing our funds to best enable the warfighting 
mission? 

To produce a version of the architecture according to the above scope, 
DOD created 12 of the 26 recommended products identified in the DOD 
Architecture Framework (DODAF)--the structural guide that the 
department has established for developing an architecture[Footnote 32]-
-including 7 products that the DODAF designates as essential. Table 5 
shows the DODAF products included in the architecture. (See app. IV for 
a complete list of the DODAF products.) 

Table 5: DOD Architecture Framework Products Included in Version 3.0: 

Product: All views (AV);
Product: AV-1[A];
Product title: Overview and Summary Information;
Product description: Executive-level summary information on the scope, 
purpose, and context of the architecture. 

Product: All views (AV);
Product: AV-2[ A];
Product title: Integrated Dictionary;
Product description: Architecture data repository with definitions of 
all terms used in all products. 

Product: Operational view (OV);
Product: OV-2[ A];
Product title: Operational Node Connectivity Description;
Product description: Graphic depiction of the operational nodes (or 
organizations) with needlines that indicate a need to exchange 
information. 

Product: Operational view (OV);
Product: OV-3[ A];
Product title: Operational Information Exchange Matrix;
Product description: Information exchanged between nodes and the 
relevant attributes of that exchange. 

Product: Operational view (OV);
Product: OV-5[ A];
Product title: Operational Activity Model;
Product description: Operations that are normally conducted in the 
course of achieving a mission or a business goal, such as capabilities, 
operational activities (or tasks), input and output flows between 
activities, and input and output flows to and from activities that are 
outside the scope of the architecture. 

Product: Operational view (OV);
Product: OV-6a;
Product title: Operational Rules Model;
Product description: One of three products used to describe operational 
activity--identifies business rules that constrain operations. 

Product: Operational view (OV);
Product: OV-6c;
Product title: Operational Event-Trace Description;
Product description: One of three products used to describe operational 
activity--traces actions in a scenario or sequence of events. 

Product: Operational view (OV);
Product: OV-7;
Product title: Logical Data Model;
Product description: System data requirements and structural business 
process rules of the operational view. 

Product: Systems view (SV);
Product: SV-1[A];
Product title: Systems Interface Description;
Product description: Systems nodes, systems, and systems items and 
their respective interconnections. 

Product: Systems view (SV);
Product: SV-5;
Product title: Operational Activity to Systems Function Traceability 
Matrix;
Product description: Mappings of relationships between the set of 
operational activities and the set of system functions. 

Product: Systems view (SV);
Product: SV-6;
Product title: Systems Data Exchange Matrix;
Product description: Characteristics of the data exchanged between 
systems. 

Product: Technical standards view (TV);
Product: TV-1[ A];
Product title: Technical Standards Profile;
Product description: Listing of standards that apply to SV elements. 

Source: DOD. 

[A] Product that the DODAF designates as essential. 

[End of table] 

Version 3.0 of DOD's business enterprise architecture partially 
satisfies each of the three major requirements specified in the act. 

With respect to the first requirement, regarding an information 
infrastructure, the act cites four requirements, each of which Version 
3.0 partially addresses, as described below. 

* Comply with federal accounting, financial management, and reporting 
requirements. 

Partial compliance is achieved based on the architecture's inclusion of 
the Standard Financial Information Structure (SFIS), which includes a 
Standard Accounting Classification Structure (SACS) that can allow DOD 
to standardize financial data elements necessary to support budgeting, 
accounting, cost/performance management, and external reporting. The 
SFIS and SACS are based upon mandated requirements defined by external 
regulatory entities, such as the U.S. Treasury, OMB, the Federal 
Accounting Standards Advisory Board, and the Joint Financial Management 
Improvement Program.[Footnote 33] As a result, SFIS can enable 
compliance with these entities' requirements if implemented properly. 
SFIS, while not complete, has been used to develop and incorporate 
business rules in the architecture for such areas as managerial cost 
accounting, general ledger, and federally owned property. Business 
rules are important because they explicitly translate important 
business policies and procedures into specific, unambiguous rules that 
govern what can and cannot be done. 

However, the architecture does not provide for compliance with all 
federal accounting, financial, and reporting requirements. For example, 
it does not do the following: 

* It does not contain the information needed to achieve compliance with 
the Department of the Treasury's United States Standard General 
Ledger.[Footnote 34] In particular, the logical data model (OV-7) does 
not contain all the data elements or attributes that are needed to 
facilitate information sharing and reconciliation with the Treasury. 
The architecture also does not include a strategy for achieving 
compliance with the Treasury's general ledger. For example, it does not 
state whether DOD will adopt the Treasury data model or simply map its 
data model to the one for the Treasury. Program officials agreed and 
stated that this limitation is being reviewed and may be addressed in 
Version 3.1 of the architecture. 

* It does not address the locations where specified activities are to 
occur and where the systems are to be located. Program officials 
agreed; however, they stated that the architecture is not intended to 
include this level of detail because it is capabilities-based rather 
than solutions-based and that this information will be contained either 
within the department's Global Information Grid[Footnote 35] or 
individual system programs' documentation. We disagree with the 
department's position that information pertaining to locations is 
better captured in a solutions-based architecture rather than in the 
business enterprise architecture. The identification of operationally 
significant and strategic business locations, as well as the need for a 
business logistics model, is a generally accepted best practice for 
defining the business operations.[Footnote 36] This is because the cost 
and performance of implemented business operations and technology 
solutions are affected by where they are located, and thus need to be 
examined, assessed, and decided in an enterprise context, rather than 
in a piecemeal systems-specific fashion. 

* Routinely produce timely, accurate, and reliable financial 
information for management purposes. 

Partial compliance is achieved in light of the financial information 
that is to be produced through (1) SFIS, which can support data 
accuracy, reliability, and integrity requirements for budgeting, 
financial accounting, cost and performance management, and external 
reporting across DOD, and (2) a "Manage Business Enterprise Reporting" 
system function, which is intended to support the reporting of 
financial management and program performance information, including 
agency financial statements. 

However, as previously discussed, SFIS is not complete and has yet to 
be implemented. Moreover, accurate and reliable information depends, in 
part, on using standard definitions of key terms in the architecture. 
The architecture does not include definitions for all such terms. In 
particular, the department has yet to define all enterprise-level 
terms, meaning terms relating to information that needs to be 
aggregated to support DOD-wide reporting. For example, in Version 3.0 
of the architecture, terms such as "balance forwarded" and "receipt 
balances" were not defined in the integrated dictionary, even though 
these terms were used in process descriptions. In the absence of these 
definitions, component organizations (military services, defense 
agencies, and field activities) could continue to use local terms and 
definitions. Such locally meaningful terms cannot be reliably and 
accurately aggregated to permit DOD-wide visibility, as defined by the 
department's business enterprise priorities. This inability to 
aggregate information for reporting purposes has historically required 
the department to produce financial information through inefficient 
methods (e.g., data calls or data translations), which have proven 
neither accurate nor timely. Program officials agreed and stated that 
they are currently working to complete SFIS and that they would 
continue to incorporate and define terms as appropriate as the 
architecture is evolved. 

* Integrate budget, accounting, and program information and systems. 

Partial compliance is accomplished through information and systems that 
are to be integrated using (1) an enterprise-level automated reporting 
system known as Business Enterprise Information Services (BEIS), which 
is intended to provide timely, accurate, and reliable business 
information across the department to support auditable financial 
statements and provide detailed financial information visibility for 
management in support of the warfighter, and to integrate budget, 
accounting, and program information that is widely dispersed among 
systems and organizations across the department; (2) a generic system 
entity called "Financial Management System Entity," which is to roll up 
component-level systems, or potential systems, that support current or 
future interface requirements; (3) the "Manage Business Enterprise 
Reporting" system function, which is to aggregate and distribute 
information according to requirements; and (4) other architectural 
elements, such as definitions and standards of data exchanges[Footnote 
37] to ensure that the data can be mutually understood, received, 
processed, and potentially aggregated and analyzed, as well as some 
terms used in the architecture. 

However, the architecture does not include certain elements: 

* It does not include a fully defined and yet to be implemented SFIS-- 
that is, an SFIS that includes all data exchanges as well as the 
business rules that are to be automated by SFIS, BEIS, and user 
activities, and are to be supported by procedure manuals. 

* It does not include all systems needed to achieve integration, as 
evidenced by instances in which the architecture provides 
"placeholders" or generic references for yet to be defined future 
systems (e.g., Financial Management System Entity). Program officials 
agreed and stated that these systems would be added as solutions are 
defined to address identified capability gaps. 

* Systematic measurement of performance, including the ability to 
produce timely, relevant, and reliable cost information. 

Partial compliance is achieved via identification of operational 
activities that are to be established to monitor the performance of the 
DOD business mission area and to develop performance plans that include 
performance levels, outcomes, and expected risks. 

However, the architecture does not do the following: 

* It does not provide for the systematic measurement of performance, 
because it has not established operationally acceptable performance 
thresholds for such measures as timeliness, accuracy, and reliability 
of financial information. These operative thresholds have significant 
influence on how business process activities are to be organized and 
controlled. Program officials agreed and stated that this issue is 
being addressed. 

* It does not describe the "As Is" business and technology environments 
needed to conduct the gap analysis that is to show the performance 
shortfalls to be addressed, and thus it does not provide the underlying 
basis for the transition plan. Program officials agreed that the 
architecture does not contain an "As Is" architecture description. They 
stated that they have nevertheless examined the "As Is" conditions in 
identifying the "To Be" solutions in the architecture. They also stated 
that they recognize that these "As Is" conditions are not in the 
architecture and they have yet to be provided to us, and that they need 
to link this information to the "To Be" architecture. 

With respect to the act's second requirement, that the architecture 
includes policies, procedures, data standards, and system interface 
requirements to be applied departmentwide, Version 3.0 partially 
complies. In particular, the architecture identifies federal guidance 
relevant to core business missions, such as the financial management 
and the human resources missions.[Footnote 38] In addition, the 
architecture identifies a specific policy entitled "Supply Chain 
Materiel Management Policy"-- dated April 22, 2004--that is relevant to 
guiding and controlling the department's core business mission and 
business processes for materiel and logistics. Moreover, the 
architecture identifies conceptual, operational, and automated business 
rules that can be used to govern the implementation of systems 
investments in accordance with policies. However, not all relevant 
policies are included in the architecture. For example, policies 
governing the development, maintenance, and implementation of the 
architecture are not included. Program officials agreed, and stated 
that the decision memorandums that were used to guide the development 
of Version 3.0 will be formalized as a departmental policy. 

In addition, Version 3.0 of the architecture includes a logical data 
model (OV-7) that contains data entities, attributes, and their 
relationships and an enterprise Technical Standards Profile (TV-1) that 
comprises a list of data standards (e.g. Extensible Markup Language 1.0 
data exchange standard); however, the architecture does not include a 
systems standards profile that would ensure data sharing and 
interoperability among departmentwide business systems. Version 3.0 
also identifies some, but not all, system interface 
requirements.[Footnote 39] For example, the architecture has yet to 
identify interface requirements with DOD systems that provide 
infrastructure services, such as network routing. Program officials 
acknowledged that the architecture does not include a systems standards 
profile and all system interface requirements and stated that they will 
address this in future versions. 

With respect to the act's third requirement, that the architecture be 
consistent with OMB policies and procedures, Version 3.0 partially 
complies. According to OMB guidance, an enterprise architecture should 
describe the "As Is" and "To Be" environments and a transition 
plan.[Footnote 40] Further, this guidance requires the architecture to 
include, among other things, the following: 

* Business processes. The work performed to support the agency's 
mission, vision, and performance goals. Agencies must also document 
change agents, such as legislation or new technologies that will drive 
architecture changes. 

* Information flow and relationships. The information used by the 
agency in its business processes, including where it is used and its 
movement among locations. These information flows are intended to show 
what information is needed where and how the information is shared to 
support mission functions. 

* Technology infrastructure. The functional characteristics, 
capabilities, and interconnections of the hardware, software, and 
telecommunications. 

* Security architecture. The support provided to secure information, 
systems, and operations. 

Version 3.0 of the architecture includes a "To Be" architecture and a 
transition plan; however, it does not include an "As Is" architecture, 
which is essential to performing a gap analysis to identify capability 
and system performance shortfalls that the transition plan is to 
address. As previously discussed, program officials agreed and stated 
that they plan to address this. In addition: 

* Version 3.0 defines some of the business processes at a high level. 
However, it does not include all business processes. For example, the 
architecture does not describe key aspects of the planning, 
programming, budgeting, and execution processes. In particular, the 
architecture does not yet define a clear planning process that balances 
requirements with resources and provides direction for execution. 

* It includes information flows and relationships. 

* It does not include a description of the technology infrastructure. 

* It does not include a security architecture. 

Beyond the above described areas in which Version 3.0 of the business 
enterprise architecture does not fully satisfy the requirements in the 
fiscal year 2005 defense authorization act, Version 3.0 has other 
limitations. Specifically: 

* The scope of Version 3.0 is not fully consistent with the scope of 
the enterprise transition plan. For example, we identified 21 systems 
in the architecture that are not included in the transition plan's 
"Master List of Systems and Initiatives" that support the business 
enterprise priorities and should therefore be funded. Instead of being 
on this master list, 19 of these 21 systems are included in the 
transition plan as part of a master list of "Non-priority DOD 
programs." Therefore, the systems identified as targeted solutions in 
the architecture are not being recognized in the transition plan as 
systems to be funded to provide the needed business capabilities. The 
remaining 2 of the 21 systems, "Industry System" and "Unstructured Data 
Sources," are not identified at all in the transition plan. As a 
result, the transition plan does not yet explicitly recognize the need 
to transition to the capabilities implied by these two systems, or else 
these systems exceed the scope of the transition plan, the Overview and 
Summary Information product (AV-1), or both. 

* In addition, the AV-1 states that the scope of Version 3.0 is limited 
to the six DOD business enterprise priorities. In contrast, the list of 
"Non-priority DOD programs" in the transition plan is described as a 
listing of systems "that are not DOD Enterprise or Component Priority 
Programs" and thus would not be targeted solutions for the business 
enterprise priorities. As a result, the stated scope of the AV-1 is 
narrower than the implied scope of the transition plan. 

* The transition plan treats certain entities, such as the Financial 
Management System Entity, as system solutions in the Master List of 
Systems, whereas Version 3.0 treats these entities as contextual 
placeholders. This difference is not explained. 

* Finally, another system (the Expeditionary Combat Support System) is 
explicitly related to four business enterprise priorities (Financial 
Visibility, Acquisition Visibility, Materiel Visibility, and Common 
Supplier Engagement) in the Master List of Systems in the transition 
plan, but it is not included in the architecture. 

* Version 3.0 refers to "Recruit Candidate" as a needed business 
capability, but this capability is not reflected in the transition 
plan. This is important because needed capabilities in the architecture 
should be reflected in the transition plan to ensure that they are 
addressed. As another example, "Access Candidate" is referred to as a 
needed business capability in the transition plan, but it is defined as 
an existing operational activity in the architecture. If it is in fact 
an operational activity, this means that the department plans to invest 
resources to achieve a business capability to address a performance 
shortfall that does not exist. Program officials stated that these are 
errors and that they will be corrected. 

Version 3.0 does not explicitly state the time frame covered for the 
"To Be" environment. Rather, it describes the time frame as being "near-
term To Be," but it does not clearly define what is meant by "near-
term," nor does it link this time frame to the milestones associated 
with the business enterprise priorities or the capabilities and systems 
in the transition plan. According to relevant guidance,[Footnote 41] 
the "To Be" architecture should be fiscally and technologically 
achievable, and therefore it should generally project 3 to 5 years into 
the future to accommodate rapid changes in technologies, changes in 
mission focus and priorities, and uncertainty in future resource 
availability. Program officials agreed and stated that they would use 
"near-term" consistently in future versions of the architecture and 
transition plan. 

Version 3.0 does not represent a fully integrated set of architecture 
products, although we did find greater product integration than in 
prior versions of the architecture. Examples of instances in which 
product integration was not apparent follow. 

* First, the Operational Event-Trace Description product (OV-6c)--which 
depicts when activities are to occur within operational processes-- 
includes a process entitled "Send Statements of Accountability or 
Transactions or Trial Balance to Treasury." However, the Operational 
Activity Model (OV-5)--which shows the operational activities (or 
tasks) that are to occur and the input and output process flows among 
these activities--identifies no corresponding activity. Instead, the OV-
5 has an activity entitled "Perform Treasury Operations," which has 
four subactivities, none of which is linked to the above 
process.[Footnote 42] Program officials agreed that these were not 
linked; however, they stated that the "Perform Treasury Operations" 
activity and its subactivities are not intended to link with the above 
mentioned process. However, intended linkages are not clear because the 
architecture does not include a traceability matrix that shows the 
connection between the two architecture products (OV-6c and OV-5). 
Program officials have acknowledged the need for greater product 
integration. 

* Second, one identified event in the architecture--"triggers the 
supplier process that provides supplier inventory information to the 
DOD"--is depicted as two separate events at different levels in the 
process decomposition. In particular, there are different names for 
this event on the parent diagrams and the child diagrams, and different 
templates were used to prepare the diagrams. Program officials agreed 
that these names differed and stated that this would be addressed. 

* Third, certain business rules are not explicitly linked to the events 
included in the architecture description, such as "ENT Post Concurrent 
Months" and "ENT_Estimate_Receivable." Program officials stated that 
the guidelines being used by the department require the business rules 
to be linked to process steps or decision gateway objects, not events. 
However, because an event is something that "happens" during the course 
of a business process, it affects the flow of the process and usually 
has a cause (trigger) or an effect (result). Therefore, best 
practices[Footnote 43] recognize the need to integrate or link the 
"triggers" that are reflected in the Operational Information Exchange 
Matrix (OV-3) to both the business rules shown in the Operational Rules 
Model (OV-6a) and the business events shown in the Operational Event- 
Trace Description (OV-6c). Program officials stated that they will 
consider revising their guidelines to link business rules to events. 

* Fourth, the interface diagram for the Financial Management System 
Entity (FMSE) does not include 4 of the 21 relevant interfaces 
identified in the AV-2 product, which is the integrated dictionary. 
Instead, these four interfaces are shown in other system interface 
diagrams, which are not linked to the FMSE diagram. Program officials 
stated that they will address this. 

* Fifth, the timelines reflected in the transition plan are difficult 
to map to the "To Be" description, according to DOD's contractor 
responsible for verification and validation of the architecture and 
transition plan.[Footnote 44] 

* Sixth, the architecture is not adequately linked to the component 
architectures and transition plans, although such linkage is 
particularly important given the department's newly adopted federated 
approach to developing and implementing the architecture. According to 
DOD, a federated architecture is composed of a set of coherent but 
distinct entity architectures. The members of the federation 
collaborate to develop an integrated enterprise architecture that 
conforms to the enterprise view and to the overarching rules of the 
federation. Program officials agreed and stated that greater levels of 
integration will be a key goal of future versions of the architecture. 

Moreover, while Version 3.0 of the architecture is easier to navigate 
through than prior versions because of improved product integration, it 
is still difficult to navigate and use this version, making 
verification and validation of completeness and correctness 
unnecessarily time consuming. For example, to trace business rules to 
their associated events (e.g., the business rule entitled "ENT Post 
Concurrent Months" to the event "trial balance closing is complete"), 
we had to first locate and review the description of the business rule, 
then locate the descriptions of the events by manually searching 
through numerous process diagrams. This was necessary because the 
architecture does not include a systematic function that enables the 
user to list all business rules that are associated with events and all 
events that are associated with business rules. Such a function is an 
accepted verification and validation method recommended by industry 
experts.[Footnote 45] 

DOD and its verification and validation contractor have also identified 
limitations in Version 3.0 of the architecture, which program officials 
told us would be addressed in future versions. For example, the 
architecture does not do the following: 

* It does not explicitly link to the department's primary non-business 
enterprise architecture (the Global Information Grid Architecture, 
which covers the warfighting mission area). 

* It does not adequately address "net-centricity," a DOD term that 
refers to having a robust, globally interconnected network environment 
(including infrastructure, systems, processes, and people) in which 
data and services (e.g., security services) are shared "timely and 
seamlessly" among users, applications, and platforms. According to DOD, 
the architecture must be improved to better designate enterprise data 
sources, business services, and IT infrastructure services. 

* It does not accurately and completely address stakeholder comments 
and their change requests. 

Program officials, including the Director of the Transformation Support 
Office, the Chief Architect, and the Enterprise Transition Plan Team 
Lead, stated that the department has taken an incremental approach to 
developing the business enterprise architecture and meeting the act's 
requirements. Accordingly, the Special Assistant to the Deputy Under 
Secretary of Defense for Business Transformation and contractor 
officials said that Version 3.0 was appropriately scoped to provide for 
that content that could be produced in the time available to both lay 
the foundation for fully meeting the act's requirements and provide a 
blueprint for delivering near-term capabilities and systems to meet 
near-term business enterprise priorities. Because of this, they stated 
that Version 3.0 fully satisfies the intent of the act. 

We support DOD taking an incremental approach to developing the 
business enterprise architecture, recognizing that adopting such an 
approach is a best practice that we have advocated. In addition, we 
believe that Version 3.0 provides a foundation upon which to build a 
more complete architecture. However, we do not agree that Version 3.0 
fully satisfies the requirements in the fiscal year 2005 defense 
authorization act. Further, the missing scope and content and related 
shortcomings described above mean that while this version is a 
reasonable baseline upon which to build, it is not yet a sufficient 
frame of reference for defining a common vision and the kind of 
comprehensive transition plan needed to effectively and efficiently 
guide and constrain system investment decision making. 

Transition Plan Partially Satisfies the Act, but Improvements Are 
Needed: 

The defense authorization act for fiscal year 2005 requires that DOD 
develop, by September 30, 2005, a transition plan for implementing its 
business enterprise architecture, and that this plan meet three 
requirements. The requirements are that it include: 

* an acquisition strategy for new systems that are expected to be 
needed to complete the defense business enterprise architecture; 

* listings of the legacy systems that will and will not be part of the 
target business systems environment, and a strategy for making 
modifications to those systems that will be included; and: 

* specific time-phased milestones, performance metrics, and a statement 
of financial and nonfinancial resource needs. 

On September 28, 2005, the Acting Deputy Secretary of Defense approved 
the transition plan. This plan, as described below, partially satisfies 
the three requirements. 

With respect to the first requirement, concerning an acquisition 
strategy, the plan does describe a high-level approach for transforming 
the department's business operations and systems, and the approach is 
driven by a set of priorities and a targeted set of business 
capabilities that are to be provided through the implementation of key 
programs. In general, the plan includes information (e.g., the lead 
core business mission, budget information, and milestones) for the 39 
transformational initiatives[Footnote 46] and the 60 business 
systems[Footnote 47] that are to be part of the "To Be" architectural 
environment, including an acquisition strategy for each system. 

However, the plan is largely based on a bottom-up planning process in 
which ongoing programs were examined and categorized in the plan around 
business enterprise priorities and capabilities, including a 
determination as to which programs would be designated and managed as 
DOD-wide programs versus component programs.This bottom-up approach to 
developing the plan does not explicitly reflect transition planning key 
practices cited in federal guidance, such as consideration of 
technology opportunities, marketplace trends, fiscal and budgetary 
constraints, institutional system development and acquisition 
capabilities, and new and legacy system dependencies and life 
expectancies, and the projected value of competing 
investments.[Footnote 48] Moreover, it means that the plan is not based 
on a top-down capability gap analysis between the "As Is" and "To Be" 
architectures in which capability and performance shortfalls are 
described, and investments (such as transformation initiatives and 
systems) that are to address these shortfalls are clearly identified. 
For example, those programs and systems that need to be acquired, 
developed, or modified and by when to meet the department's time frame 
to have a general ledger capability in fiscal year 2006 or 2007 are not 
clearly identified. According to DOD, this general ledger capability is 
to be addressed by systems and initiatives that are spread across 
various appendixes in the transition plan. However, the transition plan 
should clearly describe the collective investments, including the 
components and their respective systems, the specific strategies to be 
used, and the estimated timelines for completion, to address this 
capability shortfall. This is not yet the case because for example, the 
transition plan states that "each component is still identifying the 
optimal path to achieve the capability to post to a United States 
Standard General Ledger compliant DOD corporate ledger." 

With respect to the second requirement, about identifying legacy 
systems that will and will not be part of the "To Be" architectural 
environment, including modifications to these systems, the plan does 
show some of the legacy systems that are to be replaced by ongoing 
programs. For example, it identifies the Defense Cash Accountability 
System (DCAS) as a target system and listed several legacy systems that 
would be replaced by DCAS (e.g., the Cash Reconciliation System, the 
Financial Operations Support system, and the International Balance of 
Payments system). It also provides a list of legacy systems that will 
be modified to provide capabilities associated with the target 
architecture environment, such as the Standard Procurement System and 
the Navy Marine Corps Intranet. 

However, the transition plan does not include a number of elements: 

* It does not include a complete listing of the legacy systems that 
will not be part of the target architecture. For example, the plan 
identified 145 legacy systems that would be migrating to the target 
system Expeditionary Combat Support System (ECSS). However, DOD 
documentation shows that this system includes over 659 legacy logistics 
systems and other legacy management information systems.[Footnote 49] 
This means that the plan does not account for 514 systems related to 
the integration and migration of ECSS. Program officials agreed and 
stated that the 145 systems included account for 90 percent of the Air 
Force's Installation and Logistics portfolio. They also said that the 
Air Force is currently assessing the remaining 514 systems to identify 
interfaces and to determine duplication, and will update the transition 
plan to reflect this assessment. 

* The plan does not include system and budget information for 13 of its 
15 defense agencies[Footnote 50] and for 8 of its 9 combatant 
commands.[Footnote 51] Exclusion of the Defense Information Systems 
Agency is particularly limiting, given that this agency provides IT 
infrastructure services that business systems will need to use. This 
omission makes it unclear whether the new business systems will be able 
to reuse existing components, thereby leveraging established 
capabilities, or will be allowed to introduce duplicative capabilities. 
According to program officials, the transition plan excluded 
information for 13 of the defense agencies and for 8 of its combatant 
commands because it was focused on the largest business-focused 
organizations in DOD--those meeting Tier 1 and Tier 2 investment review 
board certification criteria.[Footnote 52] They noted that the majority 
of these organizations do not meet these threshold criteria and 
therefore were not included in the transition plan.[Footnote 53] 

* The plan does not include a complete listing of the legacy systems 
that will be part of the target architecture, nor explicit strategies 
for modifying those legacy systems identified in the plan's system 
migration diagrams. For example, other DOD documentation shows that 
ECSS, the Defense Enterprise Accounting Management System, and the 
Defense Integrated Military Human Resources System (DIMHRS) must 
interface to provide needed business capabilities. However, the 
transition plan does not reflect this needed integration or the 
specific capabilities that will be provided by ECSS. According to the 
transition plan, these strategies are incorporated in the components' 
architectures. However, as we stated in the previous section of this 
report, the components' architectures have yet to be linked to the 
business enterprise architecture. Program officials stated that this 
issue will be addressed through the department's tiered accountability 
approach. 

With respect to the third requirement, concerning milestones, 
performance metrics, and resource needs, the plan includes key 
milestone dates for the 60 systems identified. For example, September 
2006 was given as the milestone date for the Defense Travel System to 
achieve full operational capability, and performance metrics were cited 
for some systems; for example, for DIMHRS, the plan cites a metric of 
reducing manual workarounds for military pay by 90 percent. However, 
the plan does not show specific dates for terminating or migrating many 
legacy systems, such as the Cash Reconciliation System and the 
Financial Operations Support system, and it does not include milestone 
dates for some ongoing programs, such as the Navy Tactical Command 
Support System. Further, the plan does not include benefits or measures 
and metrics focused on mission outcomes for each system that can be 
linked to the plan's strategic goals. In addition, although the plan 
does identify resource needs in terms of funding, these needs are a 
reflection of the funding needs contained in the fiscal year 2006 
budget submission; this submission was approved before the programs 
included in the transition plan were reevaluated by the DBMSC as to 
their fit within the "To Be" architectural environment and the 
reasonableness of their respective plans. According to program 
officials, this means that the resource needs in the transition plan 
for some programs are not current. 

Beyond the transition plan's partial compliance with the three 
requirements in the act, as described above, the plan is also missing 
relevant context and is not consistent with the architecture in various 
ways. For example: 

* The plan identifies 60 systems as target systems (e.g., DCAS), but 
the "To Be" architecture includes only 23 of these systems. Program 
officials agreed and stated that the other 37 systems are contained 
within component architectures and transition plans. However, as we 
previously stated, the component architectures have not been linked to 
Version 3.0. 

* The plan identifies 21 enterprise initiatives[Footnote 54] (e.g., 
SFIS, Defense Acquisition Management Information Retrieval, and 
Customer Relationship Management), but only 1 of these--Defense 
Acquisition Management Information Retrieval--is included in the 
architecture, and it is shown in the architecture as a system, not an 
initiative. It is important for the architecture to include these 
initiatives and their relationships to systems. Program officials 
agreed and stated that Defense Acquisition Management Information 
Retrieval will be appropriately reflected as a system in the next 
version of the plan. 

* The plan includes a list of 66 systems that are characterized as 
nonpriority DOD enterprise or component programs that will be part of 
the target architecture, but the target architecture does not identify 
all these systems. Further, some systems on the list, such as the 
Mechanization of Contract Administration Services (MOCAS), are systems 
that in the past were considered eligible for elimination. Program 
officials agreed and stated that some of these systems are component- 
level systems and therefore are reflected within the yet to be linked 
component architectures and transition plans. With regard to systems 
that, like MOCAS, are slated for termination, these officials stated 
that replacement systems for such legacy systems have not yet been 
identified. Until they are, the legacy systems will continue to be 
shown as target solutions. 

* The specific business capabilities to be provided by the system 
solutions for the six business enterprise priorities have not been 
completely defined in the plan. For example, the Materiel Visibility 
business enterprise priority requires additional capabilities related 
to the supply chain planning process, according to DOD, but these 
capabilities have yet to be defined in the plan. Program officials 
stated that these will be addressed in future versions of the 
architecture and transition plan. 

According to program officials, including the Director of the 
Transformation Support Office, the Chief Architect, and the Enterprise 
Transition Plan Team Lead, the transition plan is evolving, and any 
limitations will be addressed in future iterations of the plan. The 
Special Assistant to the Deputy Under Secretary of Defense for Business 
Transformation and contractor officials stated that the department has 
taken an incremental approach to developing a transition plan and that 
the plan, as constrained by the scope of Version 3.0 of the 
architecture, satisfies the intent of the act's requirements. 

We support an incremental approach to developing the transition plan, 
which is a best practice that we have advocated. However, the plan does 
not fully comply with the act's requirements. Moreover, it was not 
derived on the basis of a gap analysis between "As Is" and "To Be" 
architectures, and it is not of sufficient scope, content, and 
alignment to effectively and efficiently manage the disposition of the 
department's existing inventory of systems or for sequencing the 
introduction of modernized business operations and supporting systems. 

Fiscal Year 2006 IT Budget Submission Includes Some but Not All 
Information That the Act Specifies: 

The fiscal year 2005 defense authorization act specifies information 
that the department is to incorporate in its budget request for fiscal 
year 2006 and each fiscal year thereafter. Specifically, the act states 
that each budget request must include information on: 

* each defense business system for which funding is being requested; 

* all funds, by appropriation, for each such business system, including 
funds by appropriation specifically for current services (Operation and 
Maintenance) and systems modernization; and: 

* the designated approval authority for each business system. 

DOD's fiscal year 2006 IT budget submission partially satisfies these 
three requirements. With regard to the first requirement, to identify 
each business system for which funding is requested, the fiscal year 
2006 budget does not reflect all business systems. Specifically, when 
DOD submitted its fiscal year 2006 budget submission in February 2005, 
it did not yet have a comprehensive single inventory of its business 
systems. As we reported in May 2004,[Footnote 55] DOD was relying at 
that time on several separate, inconsistent, and unreconciled databases 
to establish an inventory of its business and national security 
systems. Accordingly, we recommended that the department establish a 
single database for its inventory of business systems. On July 13, 
2004, the Assistant Secretary of Defense (Networks and Information 
Integration)/Chief Information Officer (ASD(NII)/CIO) directed 
establishment of the DOD Information Technology Portfolio Data 
Repository (DITPR), and on September 28, 2005, the Deputy Assistant 
Secretary of Defense (Deputy CIO), issued guidance to begin merging the 
DOD IT registry[Footnote 56] into DITPR. According to DOD, all business 
systems will be entered into DITPR by December 31, 2005. According to 
DOD, all systems will be entered into DITPR by September 30, 2006. 
However, the establishment and merger of these repositories had not 
been completed before the development and submission of the fiscal year 
2006 IT budget. 

With respect to the fiscal year 2007 and future IT budget submissions, 
DOD plans to use a separate database, entitled the Select and Native 
Programming Data Collection System-Information Technology to develop 
the department's IT budget submissions. For these future submissions, 
it will be important for DOD to ensure that this system contains all 
business systems investments. 

The extent to which any of these repositories include all business 
systems, and thus the extent to which the fiscal year 2006 and future 
budget submissions will as well, is also a function of whether DOD 
classifies a given system as a business system or a national security 
system.[Footnote 57] We previously reported that DOD reclassified 56 
systems in its fiscal year 2005 budget request from business systems to 
national security systems.[Footnote 58] The net effect of the 
reclassification was a decrease of approximately $6 billion in the 
fiscal year 2005 budget request for business systems and related 
infrastructure. While some of the reclassifications appeared 
reasonable, we reported that others were questionable.[Footnote 59] 
According to DOD, it is currently reviewing the 56 systems, and it 
plans to complete these reviews by February 2006 to ensure they are 
properly classified in the fiscal year 2007 IT budget submission. 

Further reclassifications are in the fiscal year 2006 budget 
submission. Specifically, 13 systems have been reclassified from 
business systems to national security systems in the fiscal year 2006 
submission. In addition, 10 national security systems have been 
reclassified as business systems in the fiscal year 2006 submission. 
For example: 

* The Air Force's Aviation Resource Management System, with a fiscal 
year 2006 budget of $3.3 million, was reclassified from a business to a 
national security system. DOD included this system in the department's 
original inventory of business systems in April 2003 and also reported 
it as a business system under the Logistics domain in the fiscal year 
2005 IT budget request. 

* The TRICARE Management Agency's Medical Readiness Decision Support 
System, with a fiscal year 2006 budget of $1.3 million, was 
reclassified from a national security system to a business system. 

Identification of each business system is also complicated by the fact 
that DOD's definition of a business system, as given in its budget 
submission, differs from the definition of a business system in the 
fiscal year 2005 defense authorization act. According to the act, a 
defense business system is "an information system, other than a 
national security system, operated by, for, or on behalf of the 
Department of Defense, including financial systems, mixed systems, 
financial data feeder systems, and information technology and 
information assurance infrastructure, used to support business 
activities."[Footnote 60] In contrast, the definition that DOD used as 
the basis for its fiscal year 2006 IT budget request notes that IT 
infrastructure and information assurance funding supports both business 
systems and national security systems. As a result, DOD's position is 
that shared IT infrastructure and information assurance funding cannot 
be classified as related to business systems or to national security 
systems. 

With regard to the second requirement, to identify the type of funding 
(i.e., appropriation) being requested and whether the funding was for 
current services or modernization, the fiscal year 2006 budget 
submission identifies the type of funding (i.e., appropriation) being 
requested and whether the funding was for current services or 
modernization. However, a number of systems are assigned to a category 
designated "All Other." It is not clear what is included in the budget 
submission under this category. In the fiscal year 2006 IT budget 
submission, this category totaled about $1.2 billion, and includes, for 
example, about $22.6 million for financial management. As we previously 
reported, the ASD(NII)/CIO and military services' budget officials told 
us that the "All Other" category in the IT budget includes system 
projects that do not have to be identified by name because they fall 
below the $2 million reporting threshold for budgetary 
purposes.[Footnote 61] This budgetary threshold is not consistent with 
the $1 million threshold that the act requires for modernization review 
and approval, as discussed later in this report, and thus could affect 
DOD's ability to identify all system investments that are subject to 
the requirements of the act. According to ASD(NII)/CIO officials, the 
fiscal year 2007 budget submission will identify all business systems 
for which planned spending is equal to or greater than $1 million. 

With respect to the third requirement, to identify the designated 
approval authority for each system, the fiscal year 2006 IT budget 
submission does so for most systems. However, the approval authority 
was not identified for 57 business systems. For example, the Navy's C2 
On-the-Move Network Digital Over-the-Horizon Relay system and the 
Defense Commissary Agency's Enterprise Business System had a designated 
approval authority of "Other." 

DOD officials told us that the department recognizes the need to 
improve the accuracy of its budget submission to provide better 
information to both DOD management and the Congress on the department's 
business systems. 

Full compliance with the act's requirements relative to budgetary 
disclosure is an important enabler of informed DOD budgetary decision 
making and congressional oversight. Lacking such disclosure, whether 
due to incomplete system repositories or incorrect system 
classification, hinders the department's efforts to improve its control 
and accountability over its business systems investments and constrains 
the Congress's ability to effectively monitor and oversee the billions 
of dollars spent annually to maintain, operate, and modernize the 
department's business systems environment. 

Act's Requirement for Delegating IT System Responsibilities and 
Accountabilities to Designated Approval Authorities Has Been Satisfied: 

The defense authorization act for fiscal year 2005 directs DOD to put 
in place a specifically defined structure that is responsible and 
accountable for controlling business system investments to ensure 
compliance and consistency with the business enterprise architecture. 
More specifically, the act directs the Secretary of Defense to delegate 
responsibility for review, approval, and oversight of the planning, 
design, acquisition, deployment, operation, maintenance, and 
modernization of defense business systems to designated approval 
authorities or "owners" of certain business missions. These are as 
follows: 

* The Under Secretary of Defense for Acquisition, Technology, and 
Logistics is to be responsible and accountable for any defense business 
system the primary purpose of which is to support acquisition, 
logistics, or installations and environment activities. 

* The Under Secretary of Defense (Comptroller) is to be responsible and 
accountable for any defense business system the primary purpose of 
which is to support financial management activities or strategic 
planning and budgeting. 

* The Under Secretary of Defense for Personnel and Readiness is to be 
responsible and accountable for any defense business system the primary 
purpose of which is to support human resource management activities. 

* The Assistant Secretary of Defense for Networks and Information 
Integration/Chief Information Officer of the Department of Defense is 
to be responsible and accountable for any defense business system the 
primary purpose of which is to support information technology 
infrastructure or information assurance activities. 

* The Deputy Secretary of Defense or an Under Secretary of Defense, as 
designated by the Secretary of Defense is to be responsible for any 
defense business system to support any DOD activity not covered above. 

DOD has satisfied this requirement under the act. On March 19, 2005, 
the Deputy Secretary of Defense issued a memorandum that delegated the 
authority in accordance with the criteria specified in the act, as 
described above. 

Our research and evaluations, as reflected in the guidance that we have 
issued, show that clear assignment of senior executive investment 
management responsibilities and accountabilities is crucial to having 
an effective institutional approach to IT investment management. 

Act's Requirements for Certain IT Investment Review Structures and 
Processes Have Been Partially Satisfied: 

The defense authorization act for fiscal year 2005 also required DOD to 
establish investment review structures and processes, including a 
hierarchy of investment review boards, each with representation from 
across the department, and a standard set of investment review and 
decision-making criteria for these boards to use to ensure compliance 
and consistency with the business enterprise architecture. In this 
regard, the act cites three specific requirements. First, it requires 
the establishment of the DBSMC for overseeing DOD's business systems 
modernization efforts, and it specifically identifies the DOD positions 
to chair and be members of this committee. Second, it requires each 
designated approval authority to establish by March 15, 2005, an 
investment review board for investments falling under that authority's 
responsibility. Third, the act requires establishment of an investment 
review process that includes, among other things, the use of common 
decision criteria, threshold criteria to ensure appropriate levels of 
review and accountability, and at least annual reviews of every 
business system investment. 

DOD has partially satisfied this requirement in the act. Among other 
things, it has done the following. 

* In February 2005, DOD chartered the DBSMC, identifying it as the 
highest ranking governance body responsible for overseeing business 
systems modernization efforts.[Footnote 62] The DBSMC is responsible 
for ensuring that DOD improves its management and oversight of the 
department's business systems. Consistent with the act, the DBSMC is 
chaired by the Deputy Secretary of Defense, and its members include 
those positions specified in the act: namely, the designated approval 
authorities previously discussed, the secretaries of the military 
services, and the heads of the defense agencies. The vice-chair of the 
committee is the Under Secretary of Defense for Acquisition, 
Technology, and Logistics. 

* DOD established four investment review boards to improve the control 
and accountability over business system investments. The four are (1) 
Financial Management, (2) Human Resources Management, (3) Real Property 
and Installations Lifecycle Management, and (4) Weapon Systems 
Lifecycle Management and Materiel Supply and Services 
Management.[Footnote 63] Each is chaired by the appropriate approval 
and certification authority (see previous section) and has DOD-wide 
representation, including membership from the combatant commands, 
military services, defense agencies, and the Joint Chiefs of Staff. 

* On June 2, 2005, the Under Secretary of Defense for Acquisition, 
Technology, and Logistics issued guidance entitled the Investment 
Review Process Overview and Concept of Operations for Investment Review 
Boards. This guidance integrates the policies, specifies 
responsibilities, and identifies the processes to govern the 
establishment and operation of investment review boards. Among other 
things, the guidance provides for these boards to review all business 
system investments, at least annually, and certify defense business 
system modernizations costing over $1 million, as required by the act. 
The guidance also specifies the certification process, including 
criteria to be used. 

* On July 15, 2005, the Under Secretary of Defense for Acquisition, 
Technology, and Logistics issued supplemental guidance and criteria for 
the components (military services, defense agencies, and DOD field 
activities) to use in preparing their respective defense business 
system modernization submissions to the investment review boards. 

* Overall, DOD's investment structures and processes employ a concept 
that it refers to as "tiered accountability."[Footnote 64] According to 
the department, tiered accountability is intended to place more 
responsibility for the management and oversight of business systems 
investments with the military services and defense agencies' 
leaderships. Accordingly, DOD's guidance describe a process in which 
business systems investments must be certified by multiple levels of 
approval and certification authorities, including the component program 
manager, the component-level precertification authority, the investment 
review board certification authority, and the DBSMC. As part of this 
process, a certification package for each system investment must be 
submitted to the approval authority, and this package is to include 
basic system information (e.g., system description and funding), 
justification as to how the system addresses enterprise-level or 
component-specific requirements; and analysis demonstrating compliance 
with the business enterprise architecture. A standard system 
certification template has been developed for use by all components and 
decision authorities. 

The act designates the ASD(NII)/CIO as one of five designated approval 
authorities for which an investment review board is to be established. 
According to the act and the Deputy Secretary's March 19, 2005, 
memorandum, the ASD(NII)/CIO is responsible and accountable for any 
business system the primary purpose of which is to support IT 
infrastructure or information assurance activities. However, the 
ASD(NII)/CIO has not established an investment review board. According 
to DOD officials, a separate investment review board has not been 
established because the ASD(NII)/CIO does not consider the IT 
infrastructure, information assurance, and related activities that are 
under its purview to be business systems. They added that the 
ASD(NII)/CIO is represented on the other investment review boards and 
can thus oversee issues related to infrastructure and information 
assurance at those meetings. 

DOD's not having established this investment review board is one of the 
reasons that the department's satisfaction of this requirement in the 
act is as yet only partial. In addition, a key aspect of the act and 
DOD's tiered accountability approach is the effective implementation of 
the defined structures and processes. It is important that such 
implementation occurs in a continuous and consistent fashion across the 
department, as we have previously stated. If it does not, the result 
could be investment decisions that perpetuate the existence of overly 
complex, error-prone, nonintegrated system environments and limit 
introduction of corporate solutions to long-standing business problems. 

DOD Is Taking Actions Intended to Satisfy the Act's Requirement for 
Reviewing Projects over $1 Million: 

The defense authorization act for fiscal year 2005 specifies two basic 
requirements, effective October 1, 2005, for obligation of funds for 
business system investments costing more than $1 million. First, it 
requires that these investments be certified by a designated "approval 
authority" as meeting specific criteria.[Footnote 65] Second, it 
requires that the DBSMC approve each certification. The act also states 
that failure to do so before the obligation of funds constitutes a 
violation of the Anti-Deficiency Act.[Footnote 66] 

The department has taken a number of actions to comply with these two 
requirements. As mentioned in the previous section, the department has 
established an investment review process, and this process requires, 
among other things, that any defense business system modernization 
costing more than $1 million obtain component precertification, 
investment review board approval, approval authority certification, and 
DBSMC approval. This process, as described in investment review board 
guidance (including DOD Business Systems Investment Review Proposal 
Submission Guideline), defines the information that programs are to 
submit to obtain certification for systems meeting certain thresholds, 
referred to as tiers. Further, the process states that the component's 
precertification authority must certify that the system is not a 
duplicative effort and that it is compliant with the DOD business 
enterprise architecture before sending the system's certification 
package forward to an investment review board. 

The department has identified 210 business system modernizations that 
meet this $1 million threshold and thus need to be approved by the 
DBSMC. Of the 210, 166 were approved by the DBSMC before September 30, 
2005. The remaining 44 have yet to be approved. This means that under 
the law, DOD cannot obligate fiscal year 2006 funds for these 44 
systems until they receive DBSMC approval. It is important to note, 
however, that the department can continue to invest in these systems by 
using funds that are still available from previous fiscal years. 

Just as with the identification of business systems in DOD's IT budget 
submissions (discussed earlier), the extent to which DOD ultimately 
complies with the act with regard to obligations costing more than $1 
million depends, in part, on the proper classification of systems as 
business versus national security. The following example illustrates 
this point. 

* In its fiscal year 2006 budget, the department is requesting about 
$167 million for the modernization of the Army's Global Combat Support 
System. The system, as we previously reported, was reclassified as a 
national security system in the fiscal year 2005 budget, even though it 
was included in the department's reported inventory of about 4,200 
business systems and approved by the DOD Comptroller in January 
2004.[Footnote 67] Also, the DBSMC approved this Army system in 
September 2005, even though the system remains listed in the fiscal 
year 2006 IT budget request as a national security system. In contrast, 
the department is requesting about $31 million for the modernization of 
the Air Force's version of this system (Global Combat Support System- 
Air Force) in its fiscal year 2006 budget. However, this system is not 
listed as one of the 210 systems requiring DBSMC approval, even though 
the system was reclassified as a business system in the fiscal year 
2006 budget. 

Another issue that will affect the degree to which the department 
complies with the act is whether it relies on system certifications and 
approvals that preceded the act's requirements. According to financial 
management investment review board officials, not all of the financial 
management systems were reviewed in accordance with the fiscal year 
2005 act's requirements. More specifically, four business systems that 
had already been reviewed in accordance with the criteria specified in 
the defense authorization act for fiscal year 2003 were granted DBSMC 
approval in August 2005 on the basis of this prior approval. Table 6 
shows the specific systems, fiscal year 2006 modernization funding, and 
the date of the previous approval. 

Table 6: Systems Receiving DBSMC Approval under Prior Criteria: 

Dollars in millions. 

General Fund Enterprise Business System;
Fiscal year 2006 modernization funding: $60.1;
Date of previous approval: May 2005. 

Defense Enterprise Accounting Management System;
Fiscal year 2006 modernization funding: 55.2;
Date of previous approval: February 2005. 

Nonappropriated Funds Financial Transformation System;
Fiscal year 2006 modernization funding: 9.8;
Date of previous approval: June 2005. 

Standard Accounting and Reporting System;
Fiscal year 2006 modernization funding: 1.8;
Date of previous approval: May 2005. 

Total;
Fiscal year 2006 modernization funding: $126.9;

Sources: GAO analysis based on DOD data.

[End of table] 

However, the act does not provide for DBSMC approval based upon the 
previous review of a system. The act is specific in terms of what 
constitutes DBSMC review and approval, and these criteria were not 
followed for the above four systems. According to financial management 
investment review board officials, the systems listed in table 6 will 
go through the current investment review process no later than February 
2006. 

The department's actions to review and approve business systems 
investments can be viewed as work in process. According to DOD, it 
intends to perform the requisite reviews and approvals of all 
applicable systems before it obligates fiscal year 2006 funds. If it 
does, it will have complied with the act. 

Conclusions: 

The defense authorization act for fiscal year 2005 contains provisions 
aimed at strengthening DOD's institutional approach to investing in IT 
business systems. To varying degrees, the department has satisfied six 
specific requirements in the act, and thus has made important progress 
in establishing the kind of fundamental management structures and 
processes that are needed to correct the long-standing and pervasive IT 
management weaknesses that have led to our designation of DOD business 
systems modernization as a high-risk program. This progress provides a 
foundation upon which to build. However, much more remains to be 
accomplished to fully satisfy the act and address the department's IT 
management weaknesses, particularly with regard to sufficiently 
developing the enterprise architecture and transition plan and ensuring 
that investment review and approval processes are institutionally 
implemented. The road map for fully addressing these areas is embedded 
in our prior recommendations to the department. Therefore, we are not 
making additional recommendations at this time. 

Agency Comments and Our Evaluation: 

In its written comments on a draft of this report, signed by the Deputy 
Under Secretary of Defense (Business Transformation) and reprinted in 
appendix II, the department recognized that our analysis, 
recommendations, guidance, and educational activities have made us a 
constructive player in DOD's business transformation efforts. While not 
commenting on most of the findings in the report, the department also 
stated that it disagreed with us on two points--the level of 
development of an "As Is" architecture and consistency within and 
between the business enterprise architecture and the transition plan. 

With respect to the first point, DOD stated that the sheer size and 
scope of its business operations makes development of a comprehensive 
"As Is" architecture an ineffective use of time and resources. Instead, 
according to DOD, while it understood that there needs to be an "easily 
traceable direct link" between the results of examining its "As Is" 
conditions and the "To Be" solutions, it maintained that the results of 
this "As Is" examination are not required to be in the enterprise 
architecture itself. According to DOD, such "As Is" related work "is 
more properly aligned with business process review than architecture 
management." Notwithstanding these comments, DOD also stated that it 
was committed to documenting the "As Is" and "To Be" relationship in an 
appropriate manner. 

We agree that both the "As Is" and the "To Be" architectures need to be 
documented in an appropriate manner. To date, DOD has yet to document 
its "As Is" architecture in a manner consistent with best practices and 
federal guidance, and thus we stand by our previous recommendations 
concerning development of an "As Is" architecture, and we look forward 
to DOD fulfilling the commitment it made in its comments to address 
this void in its business enterprise architecture. In this regard, we 
also agree that developing what the department termed in its comments 
as a "comprehensive 'As Is' architecture" may not be an effective use 
of time and resources. Accordingly, our prior recommendations for an 
"As Is" architecture have neither presumed nor prescribed a specific 
level of comprehensiveness for this "As Is" description, beyond 
recognizing that it should be defined in accordance with widely 
accepted best practices and federal guidance. According to these 
practices and guidance, it should capture the current inventory of 
enterprise capabilities (in terms of business processes and performance 
measures) in sufficient scope and detail to permit meaningful analysis 
of capability gaps in the "To Be" architecture in those areas of the 
enterprise that are likely to change during the defined transition 
period. In addition, it should capture descriptions of the 
information/data, services/applications, and technology environments 
currently in use, so that transition planning activities can 
appropriately take into account and address such things as data 
redundancies, application duplication, shared services, and 
infrastructure capacity. Our prior recommendations were, however, clear 
that these "As Is" descriptions should be part of the enterprise 
architecture (as opposed to what DOD referred to as a business process 
review), because including such descriptions is a widely accepted best 
practice and a condition in federal guidance. 

With respect to the second point, DOD stated that great effort was made 
to integrate the business enterprise architecture and the transition 
plan and that "virtually all" of our examples demonstrating a lack of 
integration within and between the business enterprise architecture and 
the transition plan "would be more accurately described as 
misunderstandings regarding the scope, purpose or intent of the 
information presented." It also stated that it was committed to 
correcting any integration issues. 

We agree that considerable effort was made to integrate architecture 
products and the architecture with the transition plan, and we 
acknowledge this in the report by stating that the integration of 
products in this version of the architecture was an improvement over 
prior versions. However, because our "misunderstandings" arise directly 
from ambiguity and inconsistencies in the architecture products and the 
transition plan that blur their intended meaning, this is clear 
evidence that a well-defined architecture is needed and that current 
levels of ambiguity and inconsistency limit the utility and 
effectiveness of the products as reference tools for guiding and 
constraining system investment decisions. We agree with DOD that 
addressing these limitations will create better transformation tools 
that will benefit all stakeholders, most importantly those within the 
department. 

We are sending copies of this report to interested congressional 
committees; the Director, Office of Management and Budget; the 
Secretary of Defense; the Deputy Secretary of Defense; the Under 
Secretary of Defense for Acquisition, Technology, and Logistics; the 
Under Secretary of Defense (Comptroller); the Assistant Secretary of 
Defense (Networks and Information Integration)/Chief Information 
Officer; 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]. 

If you or your staff have any questions on matters discussed in this 
report, please contact me at (202) 512-3439 or [Hyperlink, 
hiter@gao.gov], or McCoy Williams at (202) 512-6906 or [Hyperlink, 
williamsM1@gao.gov]. Contact points for our Offices of Congressional 
Relations and Public Affairs may be found on the last page of this 
report. GAO staff who made major contributions to this report are 
listed in appendix V. 

Signed by:

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

Signed by:

McCoy Williams:
Director Financial Management Assurance: 

List of Committees: 

The Honorable John 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 L. Hunter: 
Chairman: 
The Honorable Ike Skelton: 
Ranking Minority Member: 
Committee on Armed Services: 
House of Representatives: 

The Honorable C.W. Bill Young: 
Chairman: 
The Honorable John P. Murtha: 
Ranking Minority Member: 
Subcommittee on Defense Committee on Appropriations: 
House of Representatives: 

The Honorable Jim Saxton: 
Chairman: 
The Honorable Martin T. Meehan: 
Ranking Minority Member: 
Subcommittee on Terrorism, Unconventional Threats and Capabilities 
Committee on Armed Services: 
House of Representatives: 

[End of section] 

Appendixes: 

Appendix I: Objective, Scope, and Methodology: 

Our objective was to assess the Department of Defense's (DOD) efforts 
to comply with the requirements of the defense authorization act for 
fiscal year 2005.[Footnote 68] Consistent with the act and as agreed 
with congressional defense committees' staffs, we evaluated DOD's 
efforts relative to six provisions in the act: (1) development of an 
enterprise architecture that includes an information infrastructure 
enabling DOD to support specific capabilities, such as data standards 
and system interface requirements; (2) development of a transition plan 
for implementing the enterprise architecture that includes specific 
elements, such as the acquisition strategy for new systems; (3) 
inclusion of business system information in DOD's fiscal year 2006 
budget submission; (4) establishment of a business system investment 
approval and accountability structure; (5) establishment of a business 
system investment review process; and (6) approval of defense business 
system investments in excess of $1 million. 

To determine whether the architecture addressed the requirements 
specified in the act, we reviewed Version 3.0 of the business 
enterprise architecture, which was approved on September 28, 2005. This 
review included analyzing relevant criteria to identify the important 
architecture scope and content and comparing Version 3.0 architecture 
products to determine whether they provided this scope and 
content.[Footnote 69] In reviewing the products, we specifically 
focused on principles, business processes, business rules, and 
standards (e.g., process and data) because relevant criteria recognize 
that these are fundamental elements of a well-defined and enforceable 
architecture. In addition, we focused on consistency and completeness 
among the architecture products and their content (e.g., operational 
activities and functions to systems), as well as between the 
architecture and the transition plan. To do this, we traced linkages 
between the different architecture products to determine if these 
linkages had been specifically identified to ensure ease of stakeholder 
navigation and understanding. We also reviewed the traceability matrix 
prepared by DOD that documented the mapping of the architecture 
products to the act and interviewed program officials to obtain an 
understanding of the methodology used to prepare and validate the 
information in this matrix. In addition, we interviewed key program 
officials, including the Special Assistant to Business Transformation, 
Deputy Under Secretary of Defense (Financial Management), the Director 
of the Transformation Support Office, the Chief Architect, and the 
Enterprise Transition Plan Team Lead, to discuss the development and 
maintenance of the architecture products. 

To determine whether the transition plan addresses the requirements 
specified in the act, we reviewed the transition plan approved on 
September 28, 2005. This review included determining whether the 
transition plan included elements specified in the act, such as an 
acquisition strategy for new systems and a statement of financial and 
nonfinancial resource needs. We also reviewed the transition plan to 
ascertain the relationship between the plan and the architecture. We 
reviewed the traceability matrix prepared by DOD that documented the 
mapping of the transition plan elements to the act and interviewed 
program officials to obtain an understanding of the methodology used to 
prepare and validate the information in this matrix. In addition, we 
interviewed key program officials, including the Special Assistant to 
Business Transformation, the Deputy Under Secretary of Defense 
(Financial Management), the Director of the Transformation Support 
Office, the Enterprise Transition Plan Team Lead, and the Chief 
Architect, to discuss the development and maintenance of the plan. 

To determine whether DOD's fiscal year 2006 information technology (IT) 
budget submission was prepared in accordance with the criteria set 
forth in the act, we reviewed and analyzed DOD's approximately $30 
billion fiscal year 2006 IT budget request. As part of our analysis, we 
determined what portion of the IT budget request related to DOD 
business systems. In addition, we compared the fiscal year 2005 and 
2006 IT budget requests to determine the systems that were reclassified 
from business to national security systems, as well as from national 
security to business systems. We analyzed the 23 system 
reclassifications by using information in the IT budget requests and 
the department's business system inventory. We also followed up with 
DOD officials to ascertain the department's efforts to address our 
concerns regarding the reclassification of the 56 systems discussed in 
our April 2005 report.[Footnote 70] We also reviewed and analyzed the 
fiscal year 2006 IT budget request to ascertain whether the specific 
types of funds being requested were explicitly identified and whether 
an approval authority was designated for each business system. 

To determine whether DOD has put in place a specifically defined 
structure that is responsible and accountable for controlling business 
systems investments to ensure compliance and consistency with the 
business enterprise architecture, we reviewed applicable memorandums 
that had been issued by the department and interviewed cognizant 
departmental officials. 

To determine whether DOD has established investment review structures 
and processes and issued a standard set of investment review and 
decision-making criteria, we reviewed applicable policies and 
procedures issued by the department. In this regard, we reviewed the 
charter for each of the investment review boards. We also met with 
representatives from the Financial Management and the Weapon Systems 
Lifecycle Management and Materiel Supply and Services Management 
investment review boards to obtain an understanding of the specific 
roles and responsibilities of the investment review boards. We also 
obtained an understanding of the tiered accountability approach being 
followed by the department to help improve its control over business 
system investments. We also reviewed the department's May 17, 2005, 
document entitled "Investment Review Process Overview and Concept of 
Operations for Investment Review Boards." 

To determine whether the department had established a process for the 
review of business system modernizations in excess of $1 million, we 
determined whether the department had identified the business systems 
that were subject to the $1 million threshold. For the 210 systems that 
the department identified as subject to the criteria set forth in the 
act, we reviewed the department's July 2005 guidance entitled "DOD 
Business Systems Investment Review Proposal Submission Guideline." In 
addition, we met representatives from the Financial Management and 
Weapon Systems Lifecycle Management and Materiel Supply and Services 
Management investment review boards to obtain an understanding of how 
they used the guidance in the review of the systems that they are 
accountable for. 

We did not independently validate the reliability of the cost and 
budget figures provided by DOD, because the specific amounts were not 
relevant to our findings. 

We conducted our work at DOD headquarters offices in Arlington, 
Virginia, from August through November 2005 in accordance with U.S. 
generally accepted government auditing standards. 

[End of section] 

Appendix II: Comments from the Department of Defense: 

Office Of The Under Secretary Of Defense: 
3000 Defense Pentagon: 
Washington, DC 20301-3000: 

November 21 2005: 

Acquisition Technology And Logistics: 

Mr. Randolph C. Hite: 
Director, Information Technology Architecture and Systems Issues: 
U.S. Government Accountability Office: 
441 G Street, N.W.: 
Washington, DC 20548: 

Dear Mr. Hite: 

This is the Department of Defense (DoD) response to the GAO. Draft 
Report GAO-06-219, "DOD BUSINESS SYSTEMS MODERNIZATION: Progress Made 
in Establishing Foundational Architecture Products and Investment 
Management Practices, but Much Work Remains" dated November 15, 2005 
(GAO Code 310607). 

GAO has been a vital partner in our efforts to transform the 
Department's business operations. Their analysis and recommendations on 
our plans and activities have provided important learning on best 
practices and guidance in refining our transformation approach. We 
appreciate their support, particularly their recognition of the 
Department's recent progress in laying the groundwork for success. In 
the two areas outlined below, we disagree with GAO's recommendations 
and findings: 

1: Creation of an "As Is" Architecture: 

Given the sheer size and scope of the Department's activities, we 
believe that developing a comprehensive "As Is" architecture would be 
an ineffective use of time and resources. We fully understand the GAO's 
concern that there needs to be an easily traceable direct link between 
the discovery phase's examination of "As Is" conditions and the 
resulting "To Be" solutions; however, we maintain that this analysis is 
not required in the architecture itself. Such work is more properly 
aligned with business process review than architecture management. 
Regardless, we are committed to working with GAO to arrive at a 
methodology for documenting the "As Is"-"To Be" relationship that is 
appropriate to the business conditions found within the Department. 

2. Consistency within and between the Business Enterprise Architecture 
and Enterprise Transition Plan: 

Great efforts were made to fully integrate the various products of the 
BEA and ETP through unit and integration testing. We are committed to 
correcting any inconsistencies as they are identified. However, 
virtually all examples provided by the GAO to demonstrate instances 
where "product integration was not apparent" would be more accurately 
described as misunderstandings regarding the scope, purpose or intent 
of the information presented (many related to understanding the 
implications of tiered accountability), rather than actual errors. We 
take these comments as a challenge to better communicate and educate 
all our stakeholders, including the GAO, on the scope, purpose and use 
of our transformation tools. 

Both of these issues represent opportunities to leverage GAO to assist 
us in better refining our approach to creating dynamic and easily 
usable transformation tools. Going forward, as the Department shifts 
the primary focus of its business transformation efforts from 
administrative processes and architecture to the achievement of 
tangible business transformation results, there will be new areas of 
opportunity for engagement. We welcome GAO's insights and look forward 
to their participation in our future efforts. 

Signed by:

Paul A. Brinkley: 
Deputy Under Secretary of Defense, (Business Transformation): 

[End of section] 

Appendix III: Summary of Several Architecture Frameworks: 

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

For example, John A. Zachman developed a structure or framework for 
defining and capturing an architecture.[Footnote 71] 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 models that are associated 
with each of these perspectives; these models describe (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 conceptual schema that can be used to identify and describe 
an entity's existing and planned components and their relationships to 
one another before beginning the costly and time-consuming efforts 
associated with developing or transforming the entity. 

Since Zachman introduced his framework, a number of other frameworks 
has been proposed. In August 2003, the department released Version 1.0 
of the DOD Architecture Framework (DODAF).[Footnote 72] The DODAF 
defines the type and content of the architectural products, as well as 
the relationships among the products that are needed to produce a 
useful architecture. (See app. IV for a list of the products prescribed 
by the DODAF.) Briefly, the framework decomposes an architecture into 
three primary views: operational, systems, and technical 
standards[Footnote 73] (see fig. 1). According to DOD, the three 
interdependent views are needed to ensure that IT systems support 
operational needs, and that they are developed and implemented in an 
interoperable and cost-effective manner. 

Figure 1: Interdependent DODAF Views of an Architecture: 

[See PDF for image] 

[End of figure] 

In September 1999, the federal Chief Information Officer (CIO) Council 
published the Federal Enterprise Architecture Framework (FEAF), which 
is intended to provide federal agencies with a common construct on 
which to base their respective architectures and to facilitate the 
coordination of common business processes, technology insertion, 
information flows, and system investments among federal agencies. FEAF 
describes an approach, including models and definitions, for developing 
and documenting architecture descriptions for multiorganizational 
functional segments of the federal government. Similar to most 
frameworks, FEAF's proposed models describe an entity's business, the 
data necessary to conduct the business, applications to manage the 
data, and technology to support the applications. 

In addition, the Office of Management and Budget (OMB) established the 
Federal Enterprise Architecture (FEA) Program Management Office to 
develop a federated enterprise architecture in the context of five 
"reference models, and a security and privacy profile that overlays the 
five models." 

* The Business Reference Model is intended to describe the federal 
government's businesses, independent of the agencies that perform them. 
This model consists of four business areas: (1) services for citizens, 
(2) mode of delivery, (3) support delivery of services, and (4) 
management of government resources. It serves as the foundation for the 
FEA. OMB expects agencies to use this model, as part of their capital 
planning and investment control processes, to help identify 
opportunities to consolidate IT investments across the federal 
government. Version 2.0 of this model was released in June 2003. 

* The Performance Reference Model is intended to describe a set of 
performance measures for major IT initiatives and their contribution to 
program performance. According to OMB, this model will help agencies 
produce enhanced performance information; improve the alignment and 
better articulate the contribution of inputs, such as technology, to 
outputs and outcomes; and identify improvement opportunities that span 
traditional organizational boundaries. Version 1.0 of this model was 
released in September 2003. 

* The Service Component Reference Model is intended to identify and 
classify IT service (i.e., application) components that support federal 
agencies and promote the reuse of components across agencies. This 
model is intended to provide the foundation for the reuse of 
applications, application capabilities, components (defined as "a self- 
contained business process or service with predetermined functionality 
that may be exposed through a business or technology interface"), and 
business services. According to OMB, this model is a business-driven, 
functional framework that classifies service components with respect to 
how they support business or performance objectives. Version 1.0 of 
this model was released in June 2003. 

* The Data Reference Model is intended to describe, at an aggregate 
level, the types of data and information that support program and 
business line operations and the relationships among these types. This 
model is intended to help describe the types of interactions and 
information exchanges that occur across the federal government. Version 
1.0 of this model was released in September 2004. 

* The Technical Reference Model is intended to describe the standards, 
specifications, and technologies that collectively support the secure 
delivery, exchange, and construction of service components. Version 1.1 
of this model was released in August 2003. 

* The Security and Privacy Profile is intended to provide guidance on 
designing and deploying measures that ensure the protection of 
information resources. OMB has released Version 1.0 of the profile. 

[End of section] 

Appendix IV: List of the DOD Architecture Framework Products: 

Product: All view (AV):
Product: AV-1;
Product title: All view (AV): Overview and Summary Information;
Product description: All view (AV): Executive-level summary information 
on the scope, purpose, and context of the architecture. 

Product: All view (AV):
Product: AV-2;
Product title: All view (AV): Integrated Dictionary;
Product description: All view (AV): Architecture data repository with 
definitions of all terms used in all products. 

Product: Operational view (OV);
Product: OV-1;
Product title: All view (AV): High-Level Operational Concept Graphic;
Product description: All view (AV): High-level graphical/textual 
description of what the architecture is supposed to do, and how it is 
supposed to do it. 

Product: Operational view (OV);
Product: OV-2;
Product title: All view (AV): Operational Node Connectivity Description;
Product description: All view (AV): Graphic depiction of the 
operational nodes (or organizations) with needlines that indicate a 
need to exchange information. 

Product: Operational view (OV);
Product: OV-3;
Product title: All view (AV): Operational Information Exchange Matrix;
Product description: All view (AV): Information exchanged between nodes 
and the relevant attributes of that exchange. 

Product: Operational view (OV);
Product: OV-4;
Product title: All view (AV): Organizational Relationships Chart;
Product description: All view (AV): Command structure or relationships 
among human roles, organizations, or organization types that are the 
key players in an architecture. 

Product: Operational view (OV);
Product: OV-5;
Product title: All view (AV): Operational Activity Model;
Product description: All view (AV): Operations that are normally 
conducted in the course of achieving a mission or a business goal, such 
as capabilities, operational activities (or tasks), input and output 
flows between activities, and input and output flows to/from activities 
that are outside the scope of the architecture. 

Product: Operational view (OV);
Product: OV-6a;
Product title: All view (AV): Operational Rules Model;
Product description: All view (AV): One of three products used to 
describe operational activity--identifies business rules that constrain 
operations. 

Product: Operational view (OV);
Product: OV-6b;
Product title: All view (AV): Operational State Transition Description;
Product description: All view (AV): One of three products used to 
describe operational activity--identifies business process responses to 
events. 

Product: Operational view (OV);
Product: OV-6c;
Product title: All view (AV): Operational Event-Trace Description;
Product description: All view (AV): One of three products used to 
describe operational activity--traces actions in a scenario or sequence 
of events. 

Product: Operational view (OV);
Product: OV-7;
Product title: All view (AV): Logical Data Model;
Product description: All view (AV): Documentation of the system data 
requirements and structural business process rules of the operational 
view. 

Product: Systems view (SV);
Product: SV-1;
Product title: All view (AV): Systems Interface Description;
Product description: All view (AV): Identification of systems nodes, 
systems, and systems items and their interconnections, within and 
between nodes. 

Product: Systems view (SV);
Product: SV-2;
Product title: All view (AV): Systems Communications Description;
Product description: All view (AV): Specific communications links or 
communications networks and the details of their configurations through 
which systems interface. 

Product: Systems view (SV);
Product: SV-3;
Product title: All view (AV): Systems-Systems Matrix;
Product description: All view (AV): Relationships among systems in a 
given architecture;
can be designed to show relationships of interest (e.g., system-type 
interfaces, planned versus existing interfaces). 

Product: Systems view (SV);
Product: SV-4;
Product title: All view (AV): Systems Functionality Description;
Product description: All view (AV): System functional hierarchies and 
system functions, and the system data flow between them. 

Product: Systems view (SV);
Product: SV-5;
Product title: All view (AV): Operational Activity to Systems Function 
Traceability Matrix;
Product description: All view (AV): Mapping of relationships between 
the set of operational activities and the set of system functions 
applicable to that architecture. 

Product: Systems view (SV);
Product: SV-6;
Product title: All view (AV): Systems Data Exchange Matrix;
Product description: All view (AV): Characteristics of the system data 
exchanged between systems. 

Product: Systems view (SV);
Product: SV-7;
Product title: All view (AV): Systems Performance Parameters Matrix;
Product description: All view (AV): Quantitative characteristics of 
systems and systems hardware/software items, their interfaces, and 
their functions. 

Product: Systems view (SV);
Product: SV-8;
Product title: All view (AV): Systems Evolution Description;
Product description: All view (AV): Planned incremental steps toward 
migrating a suite of systems to a more efficient suite, or toward 
evolving a current system to a future implementation. 

Product: Systems view (SV);
Product: SV-9;
Product title: All view (AV): Systems Technology Forecast;
Product description: All view (AV): Emerging technologies and 
software/hardware products that are expected to be available in a given 
set of time frames and that will affect future development of the 
architecture. 

Product: Systems view (SV);
Product: SV-10a;
Product title: All view (AV): Systems Rules Model;
Product description: All view (AV): One of three products used to 
describe system functionality--identifies constraints that are imposed 
on systems functionality due to some aspect of systems design or 
implementation. 

Product: Systems view (SV);
Product: SV-10b;
Product title: All view (AV): Systems State Transition Description;
Product description: All view (AV): One of three products used to 
describe system functionality--identifies responses of a system to 
events. 

Product: Systems view (SV);
Product: SV-10c;
Product title: All view (AV): Systems Event-Trace Description;
Product description: All view (AV): One of three products used to 
describe system functionality--lays out the sequence of system data 
exchanges that occur between systems (external and internal), system 
functions, or human role for a given scenario. 

Product: Systems view (SV);
Product: SV-11;
Product title: All view (AV): Physical Schema;
Product description: All view (AV): Physical implementation of the 
Logical Data Model entities (e.g., message formats, file structures, 
and physical schema). 

Product: Technical standards view (TV);
Product: TV-1;
Product title: All view (AV): Technical Standards Profile;
Product description: All view (AV): Listing of standards that apply to 
SV elements in a given architecture. 

Product: Technical standards view (TV);
Product: TV-2;
Product title: All view (AV): Technical Standards Forecast;
Product description: All view (AV): Description of emerging standards 
and the potential impact on current systems view elements, within a set 
of time frames. 

Source: DOD. 

[End of table] 

[End of section] 

Appendix V: GAO Contact and Staff Acknowledgments: 

GAO Contact: 

Randolph C. Hite, (202) 512-3439 or [Hyperlink, hiter@gao.gov]. 

McCoy Williams, (202) 512-6906 or [Hyperlink, williamsM1@gao.gov].

Acknowledgments: 

In addition to the contacts named above, key contributors to this 
report were Cynthia Jackson and Darby Smith, Assistant Directors, and 
Beatrice Alff, Barbara Collier, Francine DelVecchio, Neelaxi Lakhmani, 
Anh Le, Mai Nguyen, Tarunkant Mithani, Freda Paintsil, Randolph 
Tekeley, and William Wadsworth. 

(310607): 

FOOTNOTES 

[1] 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. See 10 U.S.C. § 2222 (j) (2). 

[2] GAO, High-Risk Series: An Update, GAO-05-207 (Washington, D.C.: 
January 2005). 

[3] An enterprise architecture, or modernization blueprint, 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 "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. 

[4] DOD components include the military services, defense agencies, and 
DOD field activities. 

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

[6] Ronald W. Reagan National Defense Authorization Act for Fiscal Year 
2005, Pub. L. No. 108-375, § 332, 118 Stat. 1811, 1851-1856 (Oct. 28, 
2004) (codified in part at 10 U.S.C. § 2222). 

[7] GAO, DOD Business Systems Modernization: Long-standing Weaknesses 
in Enterprise Architecture Development Need to Be Addressed, GAO-05-702 
(Washington, D.C.: July 22, 2005). 

[8] See, for example, GAO, Defense Inventory: Opportunities Exist to 
Improve Spare Parts Support Aboard Deployed Navy Ships, GAO-03-887 
(Washington, D.C.: Aug. 29, 2003);
Military Pay: Army National Guard Personnel Mobilized to Active Duty 
Experienced Significant Pay Problems, GAO-04-89 (Washington, D.C.: Nov. 
13, 2003); and DOD Travel Cards: Control Weaknesses Resulted in 
Millions of Dollars of Improper Payments, GAO-04-576 (Washington, D.C.: 
June 9, 2004). 

[9] GAO-05-207. The 8 specific DOD high-risk areas are (1) approach to 
business transformation, (2) business systems modernization, (3) 
contract management, (4) financial management, (5) personnel security 
clearance program, (6) supply chain management, (7) support 
infrastructure management, and (8) weapon systems acquisition. The 6 
governmentwide high-risk areas are (1) disability programs, (2) 
interagency contracting, (3) information systems and critical 
infrastructure, (4) information sharing for homeland security, (5) 
human capital, and (6) real property. 

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

[11] The Clinger-Cohen Act of 1996, 40 U.S.C. § 11312 and 11315(b)(2). 

[12] The E-Government Act of 2002, Public Law 107-347 (Dec. 17, 2002). 

[13] This guidance is provided in the Office of Management and Budget 
(OMB) Capital Programming Guide, Version 1.0 (July 1997) and GAO, 
Information Technology Investment Management: A Framework for Assessing 
and Improving Process Maturity, GAO-04-394G (Washington, D.C.: March 
2004). 

[14] The Clinger-Cohen Act of 1996, 40 U.S.C. sections 11101-11704. 
This act expanded the responsibilities of OMB and the agencies that had 
been set under the Paperwork Reduction Act with regard to information 
technology management. See 44 U.S.C. 3504(a)(1)(B)(vi) (OMB);
44 U.S.C. 3506(h)(5) (agencies). 

[15] We have made recommendations to improve OMB's process for 
monitoring high-risk IT investments; see GAO, Information Technology: 
OMB Can Make More Effective Use of Its Investment Reviews, GAO-05-276 
(Washington, D.C.: Apr. 15, 2005). 

[16] This policy is set forth and guidance is provided in OMB Circular 
No. A-11 (Nov. 2, 2005) (section 300) and in OMB's Capital Programming 
Guide, which directs agencies to develop, implement, and use a capital 
programming process to build their capital asset portfolios. 

[17] GAO, Information Technology Investment Management: A Framework for 
Assessing and Improving Process Maturity, GAO-04-394G (Washington, 
D.C.: March 2004). 

[18] GAO, Information Technology: A Framework for Assessing and 
Improving Enterprise Architecture Management (Version 1.1), GAO-03- 
584G (Washington, D.C.: April 2003); and CIO Council, A Practical Guide 
to Federal Enterprise Architecture, Version 1.0 (February 2001). 

[19] See, for example, GAO, Homeland Security: Efforts Under Way to 
Develop Enterprise Architecture, but Much Work Remains, GAO-04-777 
(Washington, D.C.: Aug. 6, 2004); DOD Business Systems Modernization: 
Limited Progress in Development of Business Enterprise Architecture and 
Oversight of Information Technology Investments, GAO-04-731R 
(Washington, D.C.: May 17, 2004); Information Technology: Architecture 
Needed to Guide NASA's Financial Management Modernization, GAO-04-43 
(Washington, D.C.: Nov. 21, 2003); DOD Business Systems Modernization: 
Important Progress Made to Develop Business Enterprise Architecture, 
but Much Work Remains, GAO-03-1018 (Washington, D.C.: Sept. 19, 2003); 
Business Systems Modernization: Summary of GAO's Assessment of the 
Department of Defense's Initial Business Enterprise Architecture, GAO- 
03-877R (Washington, D.C.: July 7, 2003); Information Technology: DLA 
Should Strengthen Business Systems Modernization Architecture and 
Investment Activities, GAO-01-631 (Washington, D.C.: June 29, 2001); 
and Information Technology: INS Needs to Better Manage the Development 
of Its Enterprise Architecture, GAO/AIMD-00-212 (Washington, D.C.: Aug. 
1, 2000). 

[20] GAO, Executive Guide: Improving Mission Performance Through 
Strategic Information Management and Technology, GAO/AIMD-94-115 
(Washington, D.C.: May 1994); Office of Management and Budget, 
Evaluating Information Technology Investments, A Practical Guide 
(Washington, D.C.: November 1995); GAO, Assessing Risks and Returns: A 
Guide for Evaluating Federal Agencies' IT Investment Decision-making, 
GAO/AIMD-10.1.13 (Washington, D.C.: February 1997); and GAO-04-394G. 

[21] GAO-03-584G. 

[22] GAO-04-394G. 

[23] There were five business area domains: (1) acquisition, (2) 
financial management, (3) human resources management, (4) installations 
and environment, and (5) logistics. There was also one mission area 
domain--enterprise information environment. 

[24] The vice chair of the DBSMC is the Under Secretary of Defense for 
Acquisition, Technology, and Logistics. 

[25] Examples of some of these DOD-wide programs, systems, and 
initiatives include the Defense Travel System, the Standard Procurement 
System, the Defense Integrated Military Human Resources System, and the 
Standard Financial Information Structure. 

[26] GAO-01-525;DOD Business Systems Modernization: Improvements to 
Enterprise Architecture Development and Implementation Efforts Needed, 
GAO-03-458 (Washington, D.C.: Feb. 28, 2003); Information Technology: 
Observations on Department of Defense's Draft Enterprise Architecture, 
GAO-03-571R (Washington, D.C.: Mar. 28, 2003); GAO-03-877R; DOD 
Business Systems Modernization: Important Progress Made to Develop 
Business Enterprise Architecture, but Much Work Remains, GAO-03-1018 
(Washington, D.C.: Sept. 19, 2003); DOD Business Systems Modernization: 
Limited Progress in Development of Business Enterprise Architecture and 
Oversight of Information Technology Investments, GAO-04-731R 
(Washington, D.C.: May 17, 2004). 

[27] According to relevant guidance, an effective configuration 
management process consists of four primary elements: (1) configuration 
identification, which includes procedures for identifying, documenting, 
and assigning unique identifiers (e.g., serial number and name) to 
product types generated for the architecture program, generally 
referred to as configuration items; (2) configuration control, which 
includes procedures for evaluating and deciding whether to approve 
changes to a product's baseline configuration, generally accomplished 
through configuration control boards, which evaluate proposed changes 
on the basis of costs, benefits, and risks and decide whether to permit 
a change; (3) configuration status accounting, which includes 
procedures for documenting and reporting on the status of configuration 
items as a product evolves; and (4) configuration auditing, which 
includes procedures for determining alignment between the actual 
product and the documentation describing it, thereby ensuring that the 
documentation used to support the configuration control board's 
decision making is complete and correct. Each of these elements should 
be described in a configuration management plan and implemented 
according to the plan. 

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

[29] Ronald W. Reagan National Defense Authorization Act for Fiscal 
Year 2005, Pub. L. No. 108-375, § 332, 118 Stat. 1811, 1851-1856 (Oct. 
28, 2004) (codified in part at 10 U.S.C. § 2222). 

[30] This process must be consistent with section 11312 of Title 40, 
United States Code, which is the Capital Planning and Investment 
Control section of the Clinger-Cohen Act. 

[31] Ronald W. Reagan National Defense Authorization Act for Fiscal 
Year 2005, Pub. L. No. 108-375, § 332, 118 Stat. 1811, 1851-1856 (Oct. 
28, 2004) (codified in part at 10 U.S.C. § 2222). 

[32] DOD, Department of Defense Architecture Framework, Version 1.0, 
Volume 1 (August 2003) and Volume 2 (February 2004). 

[33] The Joint Financial Management Improvement Program (JFMIP) was a 
joint and cooperative undertaking of the Department of the Treasury, 
GAO, OMB, and the Office of Personnel Management (OPM), working in 
cooperation with each other and other federal agencies to improve 
financial management practices in the federal government. Leadership 
and program guidance were provided by the four Principals of JFMIP--the 
Secretary of the Treasury, the Comptroller General of the United 
States, and the Directors of OMB and OPM. Although JFMIP ceased to 
exist as a stand-alone organization as of December 1, 2004, the JFMIP 
Principals will continue to meet at their discretion. 

[34] The United States Standard General Ledger provides a uniform Chart 
of Accounts and technical guidance to be used in standardizing federal 
agency accounting. 

[35] DOD defines the Global Information Grid 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. 

[36] See, for example, J. A. Zachman, "A Framework for Information 
Systems Architecture," IBM Systems Journal 26, no. 3 (1987); Paula 
Hagan, "Relating Elements of the Zachman Framework, Spewak's Enterprise 
Architecture Planning, and DOD Products" (June 18, 2002); and B. Craig 
Meyers and Patricia Oberndorf, Managing Software Acquisition Open 
Systems and COTS Products (Addison-Wesley, 2001). 

[37] Examples of data exchanges cited in the architecture include those 
associated with disbursing, collecting, and obligating data. Data 
exchange standards cited in the technical reference model include the 
Electronic Data Interchange, the American National Standards Institute 
Accredited Standards Committee X12, and the Extensible Markup Language 
1.0. 

[38] As examples, for the financial management core business mission 
area, DOD's business enterprise architecture identified guidance, such 
as the Joint Financial Management Improvement Program and OMB Circular 
No. A-19 entitled Title 5 (Organization and Employees), Part I, Chapter 
5, Subchapter II, Section 552a (The Privacy Act of 1974). For the human 
resources core business mission area, the architecture identified 
chapter 14 of Title 29 relating to age discrimination in employment. 

[39] An example of a system interface requirement is the Human 
Resources interface "DCPDS-DIMHRS," which represents the requirements 
needed to exchange data between the Defense Civilian Personnel Data 
System and the Defense Integrated Military Human Resources System. 

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

[41] GAO, Information Technology: A Framework for Assessing and 
Improving Enterprise Architecture Management (Version 1.1), GAO-03- 
584G (Washington, D.C.: April 2003); and CIO Council, A Practical Guide 
to Federal Enterprise Architecture, Version 1.0 (February 2001). 

[42] The four subactivities are Manage Disbursements, Manage 
Collections, Manage Cash, and Manage Investments. 

[43] See, for example, Business Process Management Initiative, Business 
Process Modeling Notation, Version 1.0 (May 2004); and Ronald Ross, 
Business Rule Concepts: Getting to the Point of Knowledge (Business 
Rule Solutions, LLC, 2005). 

[44] Transformation Support Office IV&V Participation in, and Review 
of, BEA 3.0 (Sept. 28, 2005). 

[45] See, for example, Ronald Ross, Business Rule Concepts: Getting to 
the Point of Knowledge (Business Rule Solutions, LLC, 2005). 

[46] These initiatives include, for example, the Air Force Information 
Reliability and Integration Action Plan and the Defense Logistics 
Agency Integrated Data Environment. 

[47] The 60 systems include 23 enterprise systems and 37 component 
systems. 

[48] GAO-03-584G and CIO Council, A Practical Guide to Federal 
Enterprise Architecture, Version 1.0 (February 2001). 

[49] DOD, Expeditionary Combat Support System Sources Sought Synopsis 
(May 10, 2004). 

[50] DOD included system and budget information for the following 
defense agencies in the transition plan: (1) Defense Financial and 
Accounting Service and (2) Defense Logistics Agency. DOD did not 
include this information for the following defense agencies: (1) 
Ballistic Missile Defense Organization, (2) Defense Advanced Research 
Projects Agency, (3) Defense Commissary Agency, (4) Defense Contract 
Audit Agency, (5) Defense Contract Management Agency, (6) Defense 
Information Systems Agency, (7) Defense Intelligence Agency, (8) 
Defense Legal Services Agency, (9) Defense Security Cooperation Agency, 
(10) Defense Security Service, (11) Defense Threat Reduction Agency, 
(12) National Imagery and Mapping Agency, and (13) National Security 
Agency. 

[51] DOD included system and budget information for the Transportation 
Command in the transition plan. DOD did not include this information 
for the (1) Central Command, (2) Joint Forces Command, (3) Pacific 
Command, (4) Southern Command, (5) Space Command, (6) Special 
Operations Command, (7) European Command, and (8) Strategic Command. 

[52] As defined in the department's Investment Review Process Overview 
and Concept of Operations for Investment Review Boards, Tier 1 systems 
include all systems that are classified as a Major Automated 
Information System or a Major Defense Acquisition Program. A Major 
Automated Information System is a program or initiative that is so 
designated by the Assistant Secretary of Defense (Networks and 
Information Integration)/Chief Information Officer or that is estimated 
to require program costs in any single year in excess of $32 million 
(fiscal year 2000 constant dollars), total program costs in excess of 
$126 million (fiscal year 2000 constant dollars), or total life-cycle 
costs in excess of $378 million (fiscal year 2000 constant dollars). A 
Major Defense Acquisition Program is so designated by the Secretary of 
Defense, or it is a program estimated by the Secretary of Defense to 
require an eventual total expenditure for research, development, test, 
and evaluation of more than $300 million (fiscal year 1990 constant 
dollars) or an eventual total expenditure for procurement of more than 
$1.8 billion (fiscal year 1990 constant dollars). Tier 2 systems 
include those with modernization efforts of $10 million or greater but 
that are not designated as a Major Automated Information System or a 
Major Defense Acquisition Program, or programs that have been 
designated as investment review board interest programs because of 
their impact on DOD transformation objectives. The tier system includes 
another tier in addition to these two: Tier 3 systems are modernization 
efforts that have anticipated costs greater than $1 million but less 
than $10 million. 

[53] Per DOD, components that have Tier 1 and Tier 2 systems that were 
excluded from the transition plan are (1) Defense Commissary Agency, 
(2) Defense Information Systems Agency, (3) Defense Threat Reduction 
Agency, and (4) TRICARE. 

[54] According to DOD, "systems" can be an information system-- 
including financial systems, mixed systems, financial data feeder 
systems--and IT and information assurance infrastructure used to 
support business activities, such as acquisition, financial management, 
logistics, strategic planning and budgeting, installations and 
environment, and human resource management. The term "initiative" 
typically refers to nonsystem programs or activities that are focused 
on policy changes, data standards, or other business practice changes. 

[55] GAO, DOD Business Systems Modernization: Billions Continue to Be 
Invested with Inadequate Management Oversight and Accountability, GAO- 
04-615 (Washington, D.C.: May 27, 2004). 

[56] The IT Registry is a database of mission-critical and mission- 
essential IT systems maintained by the Assistant Secretary of Defense 
(Networks and Information Integration)/Chief Information Officer. 

[57] National security systems are intelligence systems, cryptologic 
activities related to national security, military command and control 
systems, and equipment that is an integral part of a weapon or weapons 
system or is critical to the direct fulfillment of military or 
intelligence missions. 

[58] GAO-05-381. 

[59] GAO-05-381. 

[60] 10 U.S.C. § 2222 (j) (2). 

[61] GAO-04-615. 

[62] See 10 U.S.C. § 186. 

[63] The Human Resources Management investment review board was 
established on June 14, 2005; the Weapon Systems Lifecycle Management 
and Materiel Supply and Services Management investment review board was 
established on July 21, 2005; the Real Property and Installations 
Lifecycle Management investment review board was established on July 
27, 2005; and the Financial Management investment review board was 
established on August 9, 2005. 

[64] See footnote 53. Both Tier 1 and Tier 2 certification submissions 
require a component precertification letter, a certification template, 
and the defense business systems dashboard. In addition, a component 
economic viability analysis and an independent cost review authority 
validation letter are applicable to all tiers and are available upon 
request from the component. 

[65] A key condition identified in the act includes certification by 
designated approval authorities that the defense business system 
modernization is (1) in compliance with the enterprise architecture; 
(2) necessary to achieve critical national security capability or 
address a critical requirement in an area such as safety or security; 
or (3) necessary to prevent a significant adverse effect on a project 
that is needed to achieve an essential capability, taking into 
consideration the alternative solutions for preventing such an adverse 
effect. 

[66] U.S.C. § 1341(a) (1) (A); see 10 U.S.C § 2222(b). 

[67] GAO-05-381. 

[68] Ronald W. Reagan National Defense Authorization Act for Fiscal 
Year 2005, Public Law 108-375, § 332, 118 Stat. 1811, 1851-1856 (Oct. 
28, 2004) (codified in part at 10 U.S.C. § 2222). 

[69] See, for example, DOD, Department of Defense Architecture 
Framework, Version 1.0, Volume 1 (August 2003) and Volume 2 (February 
2004); Dennis E. Wisnosky with Joseph Vogel and the other Wizards from 
Wizdom Systems, Inc, DoDAF Wizdom: A Practical Guide to Planning, 
Managing and Executing Projects to Build Enterprise Architectures using 
the Department of Defense Architecture Framework (Wizdom Press, 2004- 
2005); J. A. Zachman, "A Framework for Information Systems 
Architecture," IBM Systems Journal 26, no. 3 (1987); Institute of 
Electrical and Electronics Engineers, Standard for Recommended Practice 
for Architectural Description of Software-Intensive Systems 1471-2000 
(Sept. 21, 2000); Business Process Management Initiative, Business 
Process Modeling Notation, Version 1.0 (May 2004); Ronald G. Ross and 
Gladys S.W. Lam, Developing the Business Model: Proteus Business 
Analysis Workshop, Fourth Edition (August 2005); and Ronald Ross, 
Business Rule Concepts: Getting to the Point of Knowledge (Business 
Rule Solutions, LLC, 2005). 

[70] GAO, DOD Business Systems Modernization: Billions Being Invested 
without Adequate Oversight, GAO-05-381(Washington, D.C.: Apr. 29, 
2005). 

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

[72] DOD, Department of Defense Architecture Framework, Version 1.0, 
Volume 1 (August 2003) and Volume 2 (February 2004). 

[73] There are some overarching aspects of architecture that relate to 
all three of the views. These overarching aspects, such as goals and 
mission statements and concepts of operations, are captured in the All- 
view products. 

GAO's Mission: 

The Government Accountability 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. Government Accountability 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. Government Accountability Office, 

441 G Street NW, Room 7149 

Washington, D.C. 20548: