Summary: The fiscal year 2003 Defense Authorization Act requires the Department of Defense (DOD) to develop by May 1, 2003, a financial management enterprise architecture, including a transition plan, that meets certain requirements. The act also requires that GAO submit to congressional defense committees an assessment of the architecture and transition plan within 60 days of their approval. As part of our ongoing work to satisfy this legislative requirement and at the request of Senate Subcommittee on Readiness and Management Support, Committee on Armed Services, staff, we briefed the Subcommittee on Readiness and Management Support, Senate Committee on Armed forces on March 4, 2003, on our preliminary assessment of the DOD draft architecture products dated February 7, 2003. As further requested by the staff, this letter transmits the observations we made during the briefing.
Based on our preliminary assessment of DOD's draft architecture products, we made the following observations during our March 4, 2003, briefing to Congress. To DOD's credit, it is (1) following its Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance Architecture framework and planning to develop most of the products called for by this framework; (2) using an automated tool to create and maintain the architecture products; and (3) following a defined process for identifying the federal regulatory and legal requirements associated with federal accounting standards and financial management and reporting requirements (e.g., Joint Financial Management Improvement Program and Title 10 U.S. Code--Armed Forces) for the seven business process areas2 within the "to be" architecture. However, we also stated that the department had yet to provide a clear definition of the intended purpose of the April 30, 2003, architecture, which, according to federal guidance, is needed to establish the architecture's scope and depth (i.e., the boundaries and level of detail to be provided in the architecture). Further, according to DOD officials' statements and DOD's architecture plans and schedules, the April 30, 2003, version of the architecture will not fully satisfy the requirements contained within Section 1004 of Public Law 107-314. In addition, we stated that the draft architecture did not include a number of items recommended by relevant architectural guidance, such as the "as is" architecture environment, including descriptions of existing business operations and supporting technology; a "to be" security architecture view, which defines the security requirements (e.g., policies, procedures, and controls), including relevant standards to be applied in implementing these controls; "to be" architecture descriptions for all key stakeholders (e.g., DOD top executives and the Congress), which are intended to provide each with sufficient understanding of the architecture to allow for meaningful input; "to be" architecture organization and location views, which define the entities/people who will perform the functions, processes, and activities, and specify the locations where the functions, processes, and activities will be performed; an explicit definition of architecture drivers and governing principles, which are the constraints and requirements that lead to major decisions about the "to be" architecture (e.g., the use of centralized versus distributed processing, and the standardization of business rules to minimize effect on implementation); and defined structure and linkages among "to be" architecture views, such as the linkages among (1) applications and services, (2) organizations using the applications and services, and (3) applicable technical standards. Given that the draft architecture products are not intended to be complete, we also noted that our assessment and observations were limited to the state of the draft products as of February 7, 2003, and that because these products are still being developed, later versions may include missing views and items.
