For example, the department has implemented the provisions in the Ronald  W. Reagan National Defense Authorization Act for Fiscal Year 2005, which  are aimed at increasing senior DOD leadership involvement in the program. Moreover, much remains to be  accomplished until DOD’s new governance structure becomes an  operational reality. Until it does, it is unlikely that the department will be  able to develop an effective BEA. 2. 3. 4. 5. In  particular, the department has yet to specify measurable goals and  outcomes to be achieved, nor has it defined the tasks to be performed to  achieve these goals and outcomes, the resources needed to perform the  tasks, or the time frames within which the tasks will be performed. DOD  has not assessed, as part of its program planning, the workforce  capabilities that it has in place and that it needs to manage its architecture  development, maintenance, and implementation efforts, nor does it have a  strategy for meeting its human capital needs. Recognizing this long- standing void in planning, DOD stated that it intends to complete, by  September 30, 2005, a transition plan that will include a program baseline  that will be used to oversee and manage program activities. Further, the baseline was to establish program roles,  responsibilities, and accountabilities and was to be used as a managerial  and oversight tool to allocate resources, manage risk, and measure and  report progress. 2). However, after almost 4  years of architecture products development, a configuration manager has  not been assigned. Program officials, including the Configuration Control Board Chair, stated  that they recognize the importance of effective configuration management. DOD Has Yet to Develop a Well-Defined BEA to Guide Its Modernization Efforts

Despite six BEA releases and two updates, DOD still does not have a  version of an enterprise architecture that can be considered well defined,  meaning that the architecture, for example, has a clearly defined purpose  that can be linked to the department’s goals and objectives and describes  both the “As Is” and the “To Be” environments; consists of integrated and  consistent architecture products; and has been approved by department  leadership. The March 2005 Update also did not have fully integrated products. Conclusions

Having and using a well-defined enterprise architecture are essential for  DOD to effectively and efficiently modernize its nonintegrated and  duplicative business operations and systems environment. However, the  department does not have such an architecture, and the architecture  products that it has produced to date do not provide sufficient content and  utility to effectively guide and constrain the department’s ongoing and  planned business systems investments. This means that despite spending  almost 4 years and about $318 million to develop its BEA, the department is  not positioned to meet its legislative mandates. Objectives, Scope, and Methodology

Our objectives were to determine whether the Department of Defense  (DOD) has (1) established an effective governance structure; (2) developed  program plans, including supporting workforce plans; (3) performed  effective configuration management; (4) developed well-defined business  enterprise architecture (BEA) products; and (5) addressed our other  recommendations. According to program officials,  the department intends to revise the governance  structure, including the communications strategy, in  September 2005. For example,  DOD has  begun to revise its governance structure to provide  for improved management and oversight, such as  establishing the DBSMC and assigning it  accountability and responsibility for directing,  overseeing, and approving the BEA; and  developed a configuration management plan and  the related procedures, and established a  configuration control board. Description of DOD Architecture Framework Products, Version 1.0

Executive-level summary information on the scope, purpose, and context of the  architecture Architecture data repository with definitions of all terms used in all products High-Level Operational Concept Graphic High-level graphical/textual description of what the architecture is supposed to  do, and how it is supposed to do it Graphic depiction of the operational nodes (or organizations) with needlines that  indicate a need to exchange information Information exchanged between nodes and the relevant attributes of that  exchange Command structure or relationships among human roles, organizations, or  organization types that are the key players in an architecture  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 One of three products used to describe operational activity—identifies business  rules that constrain operations One of three products used to describe operational activity—identifies business  process responses to events One of three products used to describe operational activity—traces actions in a  scenario or sequence of events Documentation of the system data requirements and structural business process  rules of the operational view Identification of systems nodes, systems, and systems items and their  interconnections, within and between nodes Specific communications links or communications networks and the details of  their configurations through which systems interface Relationships among systems in a given architecture; can be designed to show  relationships of interest (e.g., system-type interfaces, planned versus existing  interfaces)
Mapping of relationships between the set of operational activities and the set of  system functions applicable to that architecture Characteristics of the system data exchanged between systems Systems Performance Parameters Matrix Quantitative characteristics of systems and systems hardware/software items,  their interfaces, and their functions Planned incremental steps toward migrating a suite of systems to a more efficient  suite, or toward evolving a current system to a future implementation 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 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 One of three products used to describe system functionality—identifies  responses of a system to events 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 Physical implementation of the Logical Data Model entities (e.g., message  formats, file structures, and physical schema)

Comments from the Department of Defense

GAO Contact and Staff Acknowledgments

	GAO Contact

	Acknowledgments

In addition to the contact named above, Cynthia Jackson, Assistant  Director; Barbara Collier; Joanne Fiorino; Neelaxi Lakhmani; Anh Le;  Freda Paintsil; Randolph Tekeley; and William Wadsworth made key  contributions to this report.
Why GAO Did This Study

The Ronald W. Reagan National Defense Authorization Act for Fiscal Year 2005 directed the Department of Defense (DOD) to develop, by September 2005, a well-defined business enterprise architecture (BEA) and a transition plan. GAO has made numerous recommendations to assist the department in successfully doing so. As part of ongoing monitoring of the architecture, GAO assessed whether the department had (1) established an effective governance structure; (2) developed program plans, including supporting workforce plans; (3) performed effective configuration management; (4) developed well-defined BEA products; and (5) addressed GAO's other recommendations.

What GAO Found

To effectively and efficiently modernize its nonintegrated and duplicative business operations and systems, it is essential for DOD to develop and use a well-defined BEA. However, it does not have such an architecture, and the products that it has produced do not provide sufficient content and utility to effectively guide and constrain ongoing and planned systems investments. As a result, despite spending almost 4 years and about $318 million, DOD does not have an effective architecture program. The current state of the program is due largely to long-standing architecture management weaknesses that GAO has made recommendations over the last 4 years to correct. In particular, DOD has not done the following: (1) established an effective governance structure, including an effective communications strategy, to achieve stakeholder buy-in. In particular, the structure that has been in place since 2001 lacks the requisite authority and accountability to be effective, and the key entities that made up this structure have not performed according to their respective charters; (2) developed program plans that explicitly identify measurable goals and outcomes to be achieved, nor has it defined the tasks to be performed to achieve the goals and outcomes, the resources needed to perform these tasks, or the time frames within which the tasks will be performed. DOD also has not assessed, as part of its program planning, the workforce capabilities that it needs in order to effectively manage its architecture efforts, nor does it have a strategy for doing so; (3) performed effective configuration management, which is a formal approach to controlling product parts to ensure their integrity. The configuration management plan and the charter for the configuration control board are draft; the board has limited authority; and, after 4 years of development, the department has not assigned a configuration manager; (4) developed a well-defined architecture. The latest versions of the architecture do not include products describing the "As Is" business and technology environments and a transition plan for investing in business systems. In addition, the versions that have been produced for the "To Be" environment have not had a clearly defined purpose and scope, are still missing important content, and contain products that are neither consistent nor integrated; and (5) fully addressed other GAO recommendations. DOD recognizes that these weaknesses need to be addressed and has recently assigned a new BEA leadership team. DOD also has either begun steps to or stated its intentions to (1) revise its governance structure; (2) develop a program baseline, by September 30, 2005, that will be used as a managerial and oversight tool to allocate resources, manage risks, and measure and report progress; and (3) revise the scope of the architecture and establish a new approach for developing it. However, much remains to be accomplished to establish an effective architecture program. Until it does, its business systems modernization effort will remain a high-risk program.