DOD Business Systems Modernization

Important Progress Made in Establishing Foundational Architecture Products and Investment Management Practices, but Much Work Remains Gao ID: GAO-06-219 November 23, 2005

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.

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.



GAO-06-219, DOD Business Systems Modernization: Important Progress Made in Establishing Foundational Architecture Products and Investment Management Practices, but Much Work Remains 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:

The Justia Government Accountability Office site republishes public reports retrieved from the U.S. GAO These reports should not be considered official, and do not necessarily reflect the views of Justia.