DOD Business Systems Modernization: Long-Standing Weaknesses in  
Enterprise Architecture Development Need to Be Addressed	 
(22-JUL-05, GAO-05-702).					 
                                                                 
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.				 
-------------------------Indexing Terms------------------------- 
REPORTNUM:   GAO-05-702 					        
    ACCNO:   A30878						        
  TITLE:     DOD Business Systems Modernization: Long-Standing	      
Weaknesses in Enterprise Architecture Development Need to Be	 
Addressed							 
     DATE:   07/22/2005 
  SUBJECT:   Agency missions					 
	     Enterprise architecture				 
	     Human capital management				 
	     Performance management				 
	     Program management 				 
	     Strategic planning 				 
	     Systems analysis					 
	     Systems management 				 
	     Federal agency reorganization			 
	     Accountability					 
	     Risk management					 
	     Business planning					 
	     Government and business				 
	     DOD Business Management Modernization		 
	     Program						 
                                                                 

******************************************************************
** This file contains an ASCII representation of the text of a  **
** GAO Product.                                                 **
**                                                              **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced.  Tables are included, but    **
** may not resemble those in the printed version.               **
**                                                              **
** Please see the PDF (Portable Document Format) file, when     **
** available, for a complete electronic file of the printed     **
** document's contents.                                         **
**                                                              **
******************************************************************
GAO-05-702

     

     * Report to Congressional Committees
          * July 2005
     * DOD BUSINESS SYSTEMS MODERNIZATION
          * Long-standing Weaknesses in Enterprise Architecture Development
            Need to Be Addressed
     * Contents
          * Results in Brief
          * Background
               * Enterprise Architecture Is Critical to Achieving Successful
                 Modernization
               * What Is an Enterprise Architecture?
               * DOD's Business Management Modernization Program: A Brief
                 Description and Chronology
               * Prior Reviews of DOD's Architecture Efforts Have Identified
                 Many Weaknesses and Challenges
          * DOD Has Yet to Implement Effective Governance and Communications,
            but Improvements Are Under Way
               * Long-standing Program Governance Weaknesses Remain, Although
                 Recent Proposals Are Intended to Address Weaknesses
               * An Effective Communications Strategy Has Yet to Be
                 Implemented, but Some Activities Are Under Way
          * DOD Has Yet to Develop Program Plans and Supporting Workforce
            Plans, but Intends to Make Improvements
               * DOD Has Yet to Develop Effective Program Plans
               * DOD Has Not Performed Effective Workforce Planning
          * DOD Is Not Performing Effective Configuration Management
          * DOD Has Yet to Develop a Well-Defined BEA to Guide Its
            Modernization Efforts
               * "As Is" Description, Transition Plan, and Purpose of BEA
                 Releases Are Missing
               * BEA Products Are Incomplete, Inconsistent, and Not
                 Integrated
               * BEA Releases Have Not Been Approved
          * DOD Has Yet to Fully Address Most of Our Other Recommendations
          * Conclusions
          * Recommendations for Executive Action
          * Agency Comments
     * Objectives, Scope, and Methodology
     * Status of Prior Recommendations on DOD's Development and Maintenance
       of Its Business Enterprise Architecture
     * Summary of Several Architecture Frameworks
     * Description of DOD Architecture Framework Products, Version 1.0
     * Comments from the Department of Defense
     * GAO Contact and Staff Acknowledgments
     * PDF6-Ordering Information.pdf
          * Order by Mail or Phone

                 United States Government Accountability Office

Report to Congressional Committees

GAO

July 2005

DOD BUSINESS SYSTEMS MODERNIZATION

Long-standing Weaknesses in Enterprise Architecture Development Need to Be
                                   Addressed

                                       a

DOD BUSINESS SYSTEMS MODERNIZATION

Long-standing Weaknesses in Enterprise Architecture Development Need to Be
Addressed

  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:

     o 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.
     o 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.
     o 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.
     o 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.
     o 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.

                 United States Government Accountability Office

Contents

  Letter 1

Results in Brief 2 Background 4 DOD Has Yet to Implement Effective
Governance and

Communications, but Improvements Are Under Way 16 DOD Has Yet to Develop
Program Plans and Supporting Workforce

Plans, but Intends to Make Improvements 23 DOD Is Not Performing Effective
Configuration Management 29 DOD Has Yet to Develop a Well-Defined BEA to
Guide Its

Modernization Efforts 32 DOD Has Yet to Fully Address Most of Our Other

Recommendations 43 Conclusions 44 Recommendations for Executive Action 45
Agency Comments 45

  Appendixes

Appendix I: Appendix II:

Appendix III: Appendix IV:

    Appendix V: Appendix VI:

Objectives, Scope, and Methodology 47 Status of Prior Recommendations on
DOD's Development and Maintenance of Its Business Enterprise Architecture
50 Summary of Several Architecture Frameworks 56 Description of DOD
Architecture Framework Products, Version 1.0 60 Comments from the
Department of Defense 62 GAO Contact and Staff Acknowledgments 64

Table 1: Roles and Responsibilities of Governance Entities 8

  Tables

Table 2: Roles and Responsibilities of the Program Office

Divisions 10 Table 3: Increments for Developing the BEA 11 Table 4: List
of DOD's Architecture Framework Products Included

in Each Release 40

Figure 1: Simplified Diagram of the Program Office 9

  Figures

Figure 2: Organization Chart of the Program Office 28 Figure 3:
Interdependent DODAF Views of an Architecture 57

    Page i GAO-05-702 DOD Business Enterprise Architecture

Contents

    Abbreviations

ASD(NII)/CIO

AV BEA BMMP C4ISR

CIO DBSMC DOD DODAF DO/IT FEA FEAF IBM IT OMB OV PPBE SFIS SV TV USD(AT&L)
Assistant Secretary of Defense (Networks and Information
Integration)/Chief Information Officer all view business enterprise
architecture Business Management Modernization Program Command, Control,
Communications, Computers, Intelligence, Surveillance, and Reconnaissance
(architecture framework) Chief Information Officer Defense Business
Systems Management Committee Department of Defense Department of Defense
Architecture Framework Domain Owners Integration Team Federal Enterprise
Architecture Federal Enterprise Architecture Framework International
Business Machines information technology Office of Management and Budget
operational view Planning, Programming, Budgeting, and Execution Standard
Financial Information Structure systems view technical standards view
Under Secretary of Defense for Acquisition, Technology, and Logistics

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. However, 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.

A

United States Government Accountability Office Washington, D.C. 20548

July 22, 2005

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

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

We first designated business systems modernization efforts within the
Department of Defense (DOD) as a high-risk program in 1995, and we
continue to designate it as such today.1 As our research on successful
public and private sector organizations has shown, attempting such
large-scale systems modernization programs without a well-defined
enterprise architecture often results in systems that are duplicative; are
not well integrated; are unnecessarily costly to manage, maintain, and
operate; and do not effectively optimize mission performance. To help DOD
transform its operations, we recommended2 in 2001 that the department
develop an enterprise architecture to guide and constrain its multibillion
dollar annual investment in business systems. In July 2001, the department
initiated a business management modernization program to, among other
things, develop a business enterprise architecture (BEA).

Recognizing the importance of DOD's efforts to transform its business
operations and systems through the use of an enterprise architecture,
Congress included provisions in the National Defense Authorization Act for
Fiscal Year 20033 aimed at having the department develop and effectively

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

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

3Bob Stump National Defense Authorization Act for Fiscal Year 2003, Public
Law 107-314, S: 1004, 116 Stat. 2458, 2629-2631 (Dec. 2, 2002).

                                Results in Brief

implement a well-defined BEA. In addition, the Ronald W. Reagan National
Defense Authorization Act for Fiscal Year 20054 again directs DOD to
develop a well-defined BEA and a transition plan by September 2005.

As part of our ongoing monitoring of the BEA, we assessed whether DOD 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 our other recommendations.

We performed our work from July 2004 through May 2005, in accordance with
generally accepted government auditing standards. We conducted this review
under the Comptroller General's authority and have addressed this report
to the committees of jurisdiction. Details on our objectives, scope, and
methodology are contained in appendix I.

DOD has yet to establish an effective governance structure for its
architecture development, maintenance, and implementation efforts,
including an effective communications strategy to achieve stakeholder
buy-in to the architecture. In particular, the structure that has been in
place since 2001 has lacked the requisite authority and accountability to
be effective, and the key entities making up this structure have not
performed according to their respective charters. For example, one
governance entity met only four times in 4 years, another last met about a
year ago, and a third did not include key members-the military services-in
its deliberations. Moreover, efforts under this governance structure to
outreach to and communicate with key stakeholders, whose input and support
of the BEA are critical to its success, fell short of plans. DOD
recognizes the need for change to address these long-standing BEA
governance weaknesses. Specifically, the department established the
Defense Business Systems Management Committee (as required by the Fiscal
Year 2005 Defense Authorization Act) to direct, oversee, and approve,
among other things, the BEA. In addition, program officials stated that
the department intends to revise its communications strategy. However,
much remains to be accomplished before these steps result in establishment
of an operational governance structure. Until such a

4Ronald W. Reagan National Defense Authorization Act for Fiscal Year 2005,
Public Law 108-375, S: 332, 118 Stat. 1811, 1851-1856, (Oct. 28, 2004)
(codified in part at 10

U.S.C. S:2222).

    Page 2 GAO-05-702 DOD Business Enterprise Architecture

structure exists, the department's architecture, and thus its
modernization efforts, will be at risk of failure.

DOD does not have the program plans it needs to effectively manage its BEA
efforts. It has not developed 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 the 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 has in place and that it needs to acquire
to manage its architecture efforts, and it does not have a strategy for
meeting its human capital needs. Unless this situation changes, it is
unlikely that DOD will be successful in its attempt to develop, maintain,
and implement its BEA. Recognizing this long-standing planning weakness,
the department stated that it will have an approved program plan by
September 30, 2005.

DOD is not performing effective configuration management, which is a
formal process for maintaining integrity and traceability and for
controlling modifications or changes to the architecture products
throughout their life cycles. Although the department has a draft plan
that defines key steps and practices, it has not followed this plan. In
addition, the department does not have a configuration manager after
almost 4 years of architecture development. Further, while there is a
configuration control board, the board's charter has yet to be approved,
and its authority is limited to approving changes to a subset of BEA
products. Until this situation is remedied, DOD will not have adequate
assurance that it is controlling product changes and maintaining the
integrity of product content.

DOD's BEA is not well defined and, thus, provides limited utility. The
latest releases and updates of the BEA do not include products describing
DOD's current or "As Is" business and technology environments, nor do they
include a plan for investing in business systems in a sequence that will
allow it to move from this "As Is" environment to its target or "To Be"
environment. In addition, there are no clearly defined associations
between the purpose of the BEA releases and updates produced to date for
this "To Be" environment and the department's goals and objectives. These
releases are also still missing important content that we have made
recommendations to correct. Moreover, the artifacts produced in these
releases and updates have been neither consistent with one another nor
adequately integrated. Finally, only the first release (Release 1.0) of
the BEA has been approved. Recognizing the need to develop architecture
products that have utility and provide a foundation upon which to build,
program officials have stated the department's intent to reduce the scope
of the BEA and to change the development approach from one that focuses on
producing as many products as it can within a specific time period to one
that focuses on developing high-quality products. Without such products,
DOD will not be able to effectively modernize its business systems.

To date, DOD has not addressed most of our other prior recommendations
regarding the development and maintenance of the BEA. While the department
has taken recent actions that fully address one of these recommendations
and partially address others, much remains to be accomplished. For
example, the department has yet to develop and implement a quality
assurance plan. Until our recommendations are addressed, the department
will remain challenged in its ability to effectively develop and implement
a BEA, and, thus, its business systems modernization will remain at high
risk of failure.

Given that roughly $318 million and 4 years have been invested without
commensurate progress and results, and given the department's recent
actions intended to address some of them, we are making several
recommendations to the Secretary of Defense to ensure that (1) DOD's
architecture progress, plans for moving forward, and capability to
implement these plans are fully disclosed to congressional committees; (2)
our open recommendations are integral to DOD's next steps; and (3) these
next steps provide for effective BEA workforce planning. In its written
comments on a draft of this report, DOD concurred with our recommendations
and stated the department's intent to implement them.

DOD is a massive and complex organization. In fiscal year 2004, the

  Background

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.
Moreover, execution of its operations spans a wide range of defense
organizations, including the military services and their respective major
commands and functional activities, numerous large defense agencies and
field activities, and various combatant and joint operational commands,
which are responsible for military operations for specific geographic
regions or theaters of operations.

In executing these military operations, the department performs an
assortment of interrelated and interdependent business functions,
including logistics management, procurement, health care management, and
financial management. DOD reports that, in order to support these business
functions, it currently relies on about 4,200 systems-including
accounting, acquisition, finance, logistics, and personnel. As we have
previously reported,5 this 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) manual data entry into multiple
systems. These problems continue despite the department's spending
billions of dollars annually to operate, maintain, and modernize its
business systems. DOD received approximately $13.3 billion for fiscal year
2005 to operate, maintain, and modernize this environment. In addition,
our reports6 continue to show that the department's stovepiped 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 high-risk areas that are
governmentwide in scope.7

Because of the department's size and complexity, modernizing its business
systems is a huge management challenge that we first designated as one of
the department's high-risk areas in 1995, and we continue to do so today.8
To help meet this challenge, DOD established its business systems

5GAO, DOD Business Systems Modernization: Improvements to Enterprise
Architecture Development and Implementation Efforts Needed, GAO-03-458
(Washington, D.C.: Feb. 28, 2003).

6See, 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).

7 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.

8 GAO-05-207.

    Enterprise Architecture Is Critical to Achieving Successful Modernization

modernization program in 2001. As we testified in 2003,9 one of the seven
key elements that are necessary to successfully execute this modernization
program is to establish and implement an enterprise architecture.
Subsequently, in its Fiscal Year 2004 Performance and Accountability
Report,10 DOD acknowledged that deficiencies in its systems and business
processes hindered the department's ability to collect and report
financial and performance information that was accurate, reliable, and
timely. The DOD report noted that to address its systemic problems and
assist in the modernization of its business operations, the department had
undertaken the development and implementation of a BEA.

Effective use of an enterprise architecture, or a modernization blueprint,
is a trademark 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 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. The Clinger-Cohen Act of
199611 mandates that an agency's CIO develop, maintain, and facilitate the
implementation of an information technology (IT) architecture. Further,
the E-Government Act of 200212 requires OMB to oversee the development of
enterprise architectures within and across agencies. In addition, OMB has
issued guidance that, among other things, requires system investments to
be consistent with these architectures.

What Is an Enterprise An enterprise architecture provides a clear and
comprehensive picture of an entity, whether it is an organization (e.g., a
federal department) or a

    Architecture?

functional or mission area that cuts across more than one organization

9GAO, Department of Defense: Status of Financial Management Weaknesses and
Progress

Toward Reform, GAO-03-931T (Washington, D.C.: June 25, 2003). 10DOD,
Department of Defense Performance and Accountability Report, Fiscal Year
2004 (Nov. 15, 2004).

11The Clinger-Cohen Act of 1996, 40 U.S.C. S:S: 11312 and 11315(b)(2).
12The E-Government Act of 2002, Public Law 107-347 (Dec. 17, 2002).

(e.g., financial maagement). This picture consists of snapshots of both
the enterprise's current or "As Is" environment and its target or "To Be"
environment, as well as a capital investment road map for transitioning
from the current to the target environment. These snapshots consist of
"views," which are one or more architecture products that provide logical
or technical representations of the enterprise.

The suite of products and their content that form a given entity's
enterprise architecture are largely governed by the framework used to
develop the architecture. Since the 1980s, various architecture frameworks
have emerged and been applied. See appendix III for 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. 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.13

13See, 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).

    DOD's Business Management Modernization Program: A Brief Description and
    Chronology

In July 2001, the Secretary of Defense established the Business Management
Modernization Program (BMMP) to improve the efficiency and effectiveness
of DOD's business operations and provide the department's leaders with
accurate and timely information through the development and implementation
of a BEA. At that time, the Secretary tasked the Under Secretary of
Defense (Comptroller), in coordination with the Under Secretary of Defense
for Acquisition, Technology, and Logistics (USD(AT&L)) and the Assistant
Secretary of Defense (Networks and Information Integration)/Chief
Information Officer (ASD(NII)/CIO), with responsibility for overseeing the
program. To accomplish this, in October 2001, the Comptroller established
governance bodies and assigned them responsibilities associated with
developing, maintaining, and implementing the BEA. These entities and
their respective roles and responsibilities are shown in table 1. DOD is
currently revising its BEA governance structure, including recently
eliminating its long-standing governance entities. These revisions are
discussed later in this report.

           Table 1: Roles and Responsibilities of Governance Entities

Entity                      Roles and        Membership
                               responsibilities 
Executive Committee         o  Provides      o  Cochaired by the
Steering Committee          strategic        Comptroller and the Assistant
                               direction to the Secretary of Defense
                               Steering         (Networks and Information
                               Committee  o     Integration)/Chief
                               Champions        Information Officer
                               program          (ASD(NII)/CIO)  o  Includes
                               execution  o     representatives from both the
                               Holds components Office of the Secretary of
                               a responsible    Defense and the military
                               for program      departments, such as the
                               results  o       Under Secretary of Defense
                               Advises the      for Acquisition, Technology,
                               Under Secretary  and Logistics (USD(AT&L)) and
                               of Defense       the Under Secretary of the
                               (Comptroller) on Army  o  Cochaired by the
                               business         Principal Deputy Comptroller
                               modernization  o 
                                Advises the     
                               Executive        
                               Committee on     
                               program          
                     performance                  and the Deputy DOD CIO      
                     o  Serves as the forum       o  Includes representatives 
                          for discussion of       from both the Office of     
                                  component       
                     issues  o  Provides          the Secretary of Defense    
                     guidance to the              and the military            
                     program officeb              departments, such as the    
                                                  Principal Deputy            
                                                  USD(AT&L) and the Assistant 
                                                  Secretary of the            
                                                  Army                        
Domain Owners     o  Provides recommendations  o  Chaired by the program   
                     to the Steering Committee    office director             
Integration Team  o  Provides guidance         o  Includes representatives 
                     regarding architecture       from the program office,    
                     updates and                  
                     their effects                senior executives from each 
                                                  business domain             
                             o  Identifies,       (domain representatives)    
                             addresses, and       and the enterprise          
                     resolves cross-domainc       
                     issues, and program              information environment 
                     governance and domain         mission area, and military 
                     operational issues           services representatives    

(Continued From Previous Page)

                  Entity Roles and responsibilities Membership

Domains and Mission  o  Implements the architecture  o  Headed by the
USD(AT&L), the Comptroller, the Area  o  Develops and executes the
transition plan Under Secretary of Defense (Personnel and

     o Oversees portfolio management activities Readiness), and the
       ASD(NII)/CIO
     o Establishes a structure to ensure the representation of  o  Includes
       representatives from the DOD the DOD components and the appropriate
       federal components, including the military services agencies

Source: DOD.

aDOD components include the military departments, defense agencies, and
DOD field activities.

bIn March 2005, DOD changed the name of the program office from the
Business Modernization and Systems Integration Office to the
Transformation Support Office.

cThere are five departmental domains or business process areas: (1)
acquisition, (2) financial management, (3) human resources management, (4)
installations and environment, and (5) logistics. There is also one
mission area-enterprise information environment.

Also in 2001, the BMMP program office was established to execute the
program's day-to-day activities, including implementing internal
management controls and other mechanisms to provide reasonable assurance
that the office would develop and implement an effective BEA. The office
is led by a program director and comprised of seven program divisions,
each of which is headed by an assistant deputy director. Figure 1 is a
simplified diagram of the organizational structure of the program office,
and table 2 shows the roles and responsibilities of the program divisions.

               Figure 1: Simplified Diagram of the Program Office

                                  Source: DOD.

Table 2: Roles and Responsibilities of the Program Office Divisions

Program division          Roles and responsibilities                       
                             Communicate status, progress, goals, and         
Communications            objectives of program to ensure that decision    
                             makers                                           
                             (e.g., internal work groups and external         
                             customers, such as Congress and GAO) receive     
                             quality                                          
                             information to make informed decisions about the 
                             department's business modernization efforts      
Financial Management and  Develop and maintain the program budget; report  
                             on program performance against the budget; and   
Comptroller               develop, oversee, and manage all program office  
                             contracts                                        
                             Provide information technology support for       
Chief Technology Officer  program activities and operations, such as       
                             maintenance                                      
                             of the architecture data repository, as well as  
                             ensure that the program office is in compliance  
                             with                                             
                             government security policies and standards       
                             Develop, extend, and improve the business        
Enterprise Architecture   enterprise architecture (BEA); and provide       
                             quality                                          
                             assurance and configuration control to ensure    
                             BEA quality and utility                          
Strategic Planning        Develop and maintain the strategic plan and      
                             program baseline, develop and maintain the risk  
                             management program, conduct quality assessments  
                             of the BEA and other program deliverables,       
                             identify process improvement areas and ensure    
                             corrective actions are taken, and assess program 
                             performance against program goals                
Transition Planning       Develop, maintain, and implement the transition  
                             plan; provide portfolio management assistance to 
                             the domains; and oversee the modernization of    
                             the department's business systems and the        
                             establishment of a consolidated systems          
                             repository                                       
Administrative Support    Provide administrative support to the program    
Programs                  office for human, material, financial, and       
                             technology                                       
                             resources to achieve the mission, vision, and    
                             strategy                                         

Source: DOD.

Initially, DOD planned to develop the architecture in 1 year.
Subsequently, the department stated that it would develop its architecture
in three increments, each increment addressing a subset of objectives and
consisting of specific architecture releases. Table 3 shows these
increments, the corresponding architecture releases, and the planned
completion dates for the increments.

To develop the architecture, DOD entered into a 5-year, $95 million
contract with International Business Machines (IBM) in April 2002, under
which the department has issued a series of task orders aimed at
developing the architecture. In 2004, DOD increased the contract amount to
$250 million; however, the contract did not provide a reason for this
increase, and program officials have yet to provide an explanation. As of
September 2004, DOD reported that it had obligated approximately $318
million for the program, which is primarily for contractor support.14

14Program officials, including the Chief Architect, stated that they do
not track and report the cost of each architecture release. These
officials stated that it would not be cost-effective to attempt to capture
this information for this review.

Page 10 GAO-05-702 DOD Business Enterprise Architecture

      Table 3: Increments for Developing the BEA

Original Revised Architecture releasea increment increment Increment
Objectives and date completion date completion date

     o Achieve unqualified audit opinion for consolidated 2.1-April 2004
       January 2005 March 2005 Department of Defense (DOD) financial
       statements, 2.2-July 2004 including related processes to achieve asset
       accountability 2.3-November 2004 and address other material weaknesses
       January 2005 Update
     o Achieve total personnel visibility to include military service March
       2005 Update members, civilian employees, military retirees, and other

U.S. personnel in a theater of operations (including contractors and other
federal employees)

     o Align acquisition practices with government and industry 3.0-September
       2005 September 2005 No change best practice benchmarks
     o Achieve total asset visibility and accurate valuation of assets
       (includes operating, materials, and supplies; inventory and property;
       and plant and equipment)
     o Enhance force management through position accountability and
       visibility (military and civilian)
     o Improve military health care delivery through a more efficient health
       care claims system, more accurate patient diagnostic coding, and joint
       medical material asset visibility
     o Improve environmental safety and occupational health
     o Implement planning, programming, budgeting, and 3.0-September 2005
       September 2006 September 2005 execution (PPBE) process improvements in
       accordance with Joint Defense Capabilities Study recommendations for a
       capabilities-based PPBE process
     o Achieve integrated total force management
     o Improve installation management

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

Source: DOD.

aThe architecture releases for increment 1 are limited to "To Be"
architecture products. According to DOD, the architecture releases for
increments 2 and 3 will include "As Is" and "To Be" architecture products.
DOD issued the initial transition plan in May 2003, and, according to
program officials, the department currently plans to issue the second
release in September 2005.

Over the last 4 years, we have identified the need for, and reviewed DOD's
efforts to develop an enterprise architecture for modernizing its business
operations and systems, and we have made a series of recommendations to
assist the department in successfully developing the architecture and
using it to guide and constrain its ongoing and planned business systems
investments.

In particular, we reported in May 200115 that the department did not have
an architecture for its financial and financial-related business
operations, nor did it have the management structures, processes, and
controls in place to effectively develop and implement one. We concluded
that continuing to spend billions of dollars on new and modified systems
would result in more processes and systems that were duplicative, not
interoperable, unnecessarily costly to maintain and interface, and not
optimizing mission performance and accountability. We made eight
recommendations to the Secretary of Defense that were aimed at providing
the means for effectively developing and implementing an architecture and
limiting DOD components' systems investments until it had a well-defined
architecture and the means to enforce it. In July 2001, DOD initiated the
BMMP.

In February 2003,16 we reported that the department was following some
architecture best practices, such as establishing a program office to be
responsible for managing the enterprise architecture development effort.
We also reported challenges and weaknesses in DOD's architecture efforts.
For example, we reported that DOD had not yet (1) established a governance
structure and the process controls needed to ensure ownership of and
accountability for the architecture across the department; (2) clearly
communicated to intended stakeholders its purpose, scope, and approach for
developing the architecture; and (3) defined and implemented an
independent quality assurance process. We reiterated our earlier
recommendations and made six new recommendations aimed at enhancing DOD's
ability to develop its architecture and to guide and constrain its
business systems modernization investments.

In March 2003,17 we reported that DOD's draft release of its architecture
did not include a number of items that were recommended by relevant
architectural guidance, and that DOD's plans would not fully satisfy the
requirements of the National Defense Authorization Act for Fiscal Year
2003.18 For example, the draft architecture did not include a "To Be"
security view, which would define the security requirements-including

15GAO-01-525. 16GAO-03-458.

17GAO, Information Technology: Observations on Department of Defense's
Draft Enterprise Architecture, GAO-03-571R (Washington, D.C.: Mar. 28,
2003).

18Bob Stump National Defense Authorization Act for Fiscal Year 2003,
Public Law 107-314, S: 1004, 116 Stat. 2458, 2629-2631 (Dec. 2, 2002).

relevant standards to be applied in implementing security policies,
procedures, and controls. DOD officials generally agreed, and they stated
that subsequent releases of the architecture would provide these missing
details.19

In July and September 2003,20 we reported that the initial release of the
department's architecture, including the transition plan, did not
adequately address statutory requirements and other relevant architectural
requirements. For example, the description of the "As Is" environment did
not include (1) the current business operations in terms of entities and
people who perform the functions, processes, and activities and (2) the
locations where the functions, processes, and activities are performed.
The description of the "To Be" environment did not include actual systems
to be developed or acquired to support future business operations and the
physical infrastructure that would be needed to support the business
systems. The transition plan did not include time frames for phasing out
existing systems within DOD's then reported inventory of about 2,300
business systems.21 We concluded that the department's initial release of
the architecture did not contain sufficient scope and detail either to
satisfy the act's requirements or to effectively guide and constrain
departmentwide business systems modernization. In our September 2003
report,22 we reiterated the open recommendations that we had made in our
May 200123 and February 200324 reports, and we made 10 new recommendations
to, among other things, improve DOD's efforts for developing the next
release of the architecture.

19Because the review was focused on draft architecture products that were
not intended to be complete, we did not make any recommendations in the
March 2003 report. Our assessment was a specific point-in-time review of
the BEA (i.e., the Feb. 7, 2003, draft architecture).

20GAO-03-877R and GAO-03-1018.

21DOD reported that it had approximately 4,200 business systems as of
February 2005.

22GAO-03-1018. 23GAO-01-525. 24GAO-03-458.

In March25 and July 2004,26 we testified that DOD's substantial
long-standing financial and business management problems adversely
affected the economy, effectiveness, and efficiency of its operations and
had resulted in a lack of adequate transparency and appropriate
accountability across all major business areas. Further, we said that
substantial work remained before the BEA would begin to have a tangible
impact on improving the department's overall business operations. We
concluded that until DOD completed a number of actions, including
developing a well-defined BEA, its business systems modernization efforts
would be at a high risk of failure.

In May 2004,27 we reported that after 3 years of effort and over $203
million in obligations, DOD had not made significant change in the content
of the BEA or in its approach to investing billions of dollars annually in
existing and new systems. We reported that few actions had been taken to
address the recommendations we had made in our September 2003 report,28
which were aimed at improving the department's plans for developing the
next release of the architecture and implementing the institutional means
for selecting and controlling both planned and ongoing business systems
investments. We also reported that DOD had still not adopted key
architecture management best practices that we had recommended,29 such as
assigning accountability and responsibility for directing, overseeing, and
approving the architecture and explicitly defining performance metrics to
evaluate the architecture's quality, content, and utility. Further, DOD
had not added the scope and detail to its architecture that we had
previously identified as missing. For example, in the latest release of
the BEA-

25GAO, Department of Defense: Further Actions Needed to Establish and
Implement a Framework for Successful Financial and Business Management
Transformation, GAO-04-551T (Washington, D.C.: Mar. 23, 2004); and
Department of Defense: Further Actions Needed to Establish and Implement a
Framework for Successful Business Transformation, GAO-04-626T (Washington,
D.C.: Mar. 31, 2004).

26GAO, Department of Defense: Long-standing Problems Continue to Impede
Financial and Business Management Transformation, GAO-04-907T (Washington,
D.C.: July 7, 2004); and Department of Defense: Financial and Business
Management Transformation Hindered by Long-standing Problems, GAO-04-941T
(Washington, D.C.: July 8, 2004).

27GAO-04-731R.

28GAO-03-1018.

29GAO, Information Technology: A Framework for Assessing and Improving
Enterprise Architecture Management (Version 1.1), GAO-03-584G (Washington,
D.C.: April 2003).

Release 2.0-DOD did not provide sufficient descriptive content related to
future business operations and supporting technology to permit effective
acquisition and implementation of system solutions and associated
operational change. Moreover, the department had not yet explicitly
defined program plans, including milestones, detailing how it intended to
extend and evolve the architecture to incorporate this missing content. We
concluded that the future of DOD's architecture development and
implementation activities was at risk, which in turn placed the
department's business transformation effort in jeopardy of failing.
Therefore, we added that it was imperative that the department move
swiftly to implement our open recommendations. Because many of our prior
recommendations remained open, we did not make any new recommendations in
our May 2004 report,30 but we reiterated the open recommendations that we
had made in our May 2001, February 2003, and September 2003 reports.31

In November 200432 and April 2005,33 we testified that for DOD to
successfully transform its business operations, it would need a
comprehensive and integrated business transformation plan; people with the
skills, responsibility, and authority to implement the plan; an effective
process and related tools, such as a BEA; and results-oriented performance
measures that would link institutional, unit, and individual personnel
goals and expectations to promote accountability for results. We testified
that over the last 3 years, we had made a series of recommendations to DOD
and suggested legislative changes that, if implemented, could help the
department move forward in establishing the means to successfully address
the challenges it faces in transforming its business operations.34 We also
testified that, after about 3 years of effort and over $203 million in

30GAO-04-731R.

31 GAO-01-525 , GAO-03-458, and GAO-03-1018 .

32GAO, Department of Defense: Further Actions Are Needed to Effectively
Address Business Management Problems and Overcome Key Business
Transformation Challenges,

GAO-05-140T (Washington, D.C.: Nov. 18, 2004).

33GAO, DOD's High-Risk Areas: Successful Business Transformation Requires
Sound Strategic Planning and Sustained Leadership, GAO-05-520T
(Washington, D.C.: Apr. 13, 2005).

34See, for example, 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); GAO-04-551T;
and GAO-03-1018 .

  DOD Has Yet to Implement Effective Governance and Communications, but
  Improvements Are Under Way

reported obligations, the architecture's content and the department's
approach to investing billions of dollars annually in existing and new
systems had not changed significantly, and that the program had yielded
very little, if any, tangible improvements in DOD's business operations.

Long-standing weaknesses in DOD's BEA governance structure and
communications strategy still remain. While DOD has established a new
senior committee to oversee its business transformation efforts, including
BEA development, much remains to be accomplished before proposed
governance and communications concepts are fully defined and implemented.
Until the department has made its intended governance and communications
concept operational, the success of DOD's architecture efforts will remain
in doubt.

    Long-standing Program Governance Weaknesses Remain, Although Recent
    Proposals Are Intended to Address Weaknesses

An enterprise architecture is a corporate asset that, among other things,
is intended to represent the strategic direction of the enterprise.
Accordingly, best practices35 recommend that to demonstrate commitment,
organizations should vest accountability and assign responsibility for
directing, overseeing, and approving the architecture to a committee or
group with representation from across the enterprise. Sustained support
and commitment by this committee to the architecture, as well as the
committee's ownership of it, are critical to a successful enterprise
architecture development effort. We have previously recommended that DOD
establish this kind of architecture responsibility and accountability
structure.36 (See app. II for our prior recommendations and their current
status.)

During the last 4 years, DOD has relied on three primary management
entities to govern BEA development, maintenance, and implementation- the
Executive Committee, the Steering Committee, and the Domain Owners
Integration Team (DO/IT). (See table 1 for their roles and
responsibilities.) This governance approach, however, does not assign
accountability and responsibility for directing, overseeing, and approving

35See, for example, GAO-03-584G; and Chief Information Officer Council, A
Practical Guide to Federal Enterprise Architecture, Version 1.0 (February
2001).

36GAO-03-458.

Page 16 GAO-05-702 DOD Business Enterprise Architecture

the BEA to these entities either singularly or collectively. As we
reported in February 2003,37 the Executive and Steering Committees were
advisory in nature, and their responsibilities were limited to providing
guidance to the program office and advising the Comptroller and the
Executive Committee. Moreover, since they were established, neither the
two committees nor the DO/IT have adequately fulfilled their assigned
responsibilities, as we discuss below.

     o The Executive Committee was chartered to, among other things, provide
       strategic direction to the Steering Committee, champion program
       execution, and hold DOD components-including the military
       services-responsible for program results. To accomplish these things,
       the charter states that the committee should establish a meeting
       schedule. However, no schedule was established, and the committee met
       only four times in over 3 1/2 years. Moreover, no minutes of the four
       meetings were prepared, according to the program's Acting Assistant
       Deputy Director for Communications, and no other documentation exists
       to demonstrate the committee's performance of its chartered functions.
       In fact, during numerous DO/IT meetings that we attended, participants
       stated that the Executive Committee was not providing strategic
       direction, nor was it championing program execution.
     o The Steering Committee was chartered to advise the Executive Committee
       on program performance, serve as the forum for discussion of component
       issues, and provide guidance to the program office. According to the
       program's Acting Assistant Deputy Director for Communications, neither
       Executive Committee meeting minutes nor any other documentation exists
       to demonstrate that the Steering Committee advised the Executive
       Committee. Moreover, during the Steering Committee meetings that we
       attended over the last 4 years, we saw no evidence that this committee
       either planned to or actually did advise the Executive Committee on
       program performance. While we did observe in these meetings that
       issues were raised and discussed, which is a chartered responsibility
       of the committee, we also observed that the committee did not provide
       guidance and direction to the program office during these meetings.
       The Steering Committee last met about 1 year ago (June 2004).

37GAO-03-458.

o  The DO/IT was chartered to provide recommendations to the Steering
Committee; provide guidance regarding architecture updates and their
effects; and identify, address, and resolve domain and program issues. The
charter also states that the DO/IT was to ensure that its representation
included the military services. However, during the Steering Committee
meetings that we attended, DO/IT representatives did not provide any
recommendations to the Steering Committee, nor did they provide guidance
on architecture updates and their effects. Moreover, the DO/IT did not
include military service representatives, and it did not establish any
policies and procedures for how to address and resolve issues. As a
result, issues that were identified during meetings were not resolved. For
example, in July 2004, there were discussions regarding the lack of
involvement from the services, the lack of detail in the architecture
content, and the lack of clear understanding of the roles and
responsibilities among the domains and the services. During this meeting,
however, no decisions were made about how these issues were to be
resolved, and no actions were taken to provide recommendations to the
Steering Committee for resolving the issues. As a result, we observed the
same issues being discussed, without resolution, 5 months later.

DOD has recently taken steps to improve the program's governance structure
and, according to program officials, further steps are planned. For
example, the department has implemented the provisions in the Ronald

W. Reagan National Defense Authorization Act for Fiscal Year 2005,38 which
are aimed at increasing senior DOD leadership involvement in the program.
In particular, it includes DOD's establishment of the Defense Business
Systems Management Committee (DBSMC) to replace both the Executive and
Steering Committees and to serve as the highest ranking governance body
overseeing business transformation. According to the DBSMC charter, the
committee is accountable and responsible for directing, overseeing, and
approving all program activities. Specific responsibilities of the
committee include

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

Page 18 GAO-05-702 DOD Business Enterprise Architecture

     o establishing strategic direction and plans for the business mission
       area39 in coordination with the warfighting and enterprise information
       environment mission areas;
     o approving business mission area transformation plans and initiatives
       and coordinating transition planning in a documented program baseline
       with critical success factors, milestones, metrics, deliverables, and
       periodic program reviews;
     o establishing key metrics and targets by which to track business
       transformation progress;
     o establishing policies and approving the business mission area
       strategic plan, the transition plan for implementation for business
       systems modernization, the transformation program baseline, and the
       BEA; and
     o executing a comprehensive communications strategy.

Consistent with recent legislation, the DBSMC is chaired by the Deputy
Secretary of Defense, and the USD(AT&L) serves as the vice chair. Its
membership consists of senior leadership from across the department,
including the military service secretaries, the defense agency heads, and
the principal staff assistants.40 The department has also moved the
program office from the Comptroller to the USD(AT&L), reporting to the
Special Assistant for Business Transformation. According to DOD, this
transfer of functions and responsibilities will allow USD(AT&L) to
establish the level of activity necessary to support and coordinate the
activities of the newly established DBSMC.

Other entities may be established to support the DBSMC. According to
program officials, including the Program Director, the DO/IT has been
eliminated and may be replaced by a DOD Enterprise Transformation
Integration Group. Further, the DO/IT had identified the need for six

39DOD plans to restructure the five business domains and the one mission
area into five core business mission areas: (1) Personnel Management, (2)
Weapon Systems Life-cycle Management, (3) Real Property and Installation
Life-cycle Management, (4) Material Supply and Service Management, and (5)
Financial Management.

40In DOD, principal staff assistants are 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, or equivalents, who
report directly to the Secretary or Deputy Secretary of Defense.

    An Effective Communications Strategy Has Yet to Be Implemented, but Some
    Activities Are Under Way

additional boards41 to assist the program office. These boards have not
yet been chartered, but potential board members have met to discuss the
boards' roles, responsibilities, and operating procedures, as well as
program issues. However, the program director stated that not all of these
boards may be established under the new structure.

According to the Special Assistant for Business Transformation, a new
governance structure will be in place and operational by September 30,
2005. To this end, DOD officials told us that the DBSMC held its first
meeting in February 2005 to finalize its charter and member composition,
and that to move governance reforms forward, the committee will initially
hold monthly meetings.

The weaknesses in the BEA governance structure over the last 4 years,
according to program officials, are attributable to a lack of authority
and accountability in program leadership by the various management
entities (e.g., Executive and Steering Committees) and to the limited
direction provided by these entities. While DOD's recent actions are
intended to address these root causes, almost 4 years and approximately
$318 million in obligations have been invested, and the department is
still attempting to establish an effective governance structure. 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.

Effective communications among architecture stakeholders are closely
aligned with effective governance. According to relevant guidance,42 once
initial stakeholder participation in an architecture program is achieved,
a communications strategy should be defined and implemented to facilitate
the exchange of information among architecture stakeholders about all
aspects of the program, such as program purpose, scope, methodologies,
progress, results, and key decisions. Such communication is essential to
executing an architecture program effectively, including obtaining
institutional buy-in for developing and using the architecture for
corporate

41The six boards are the (1) Architecture Management Board, (2)
Capabilities Transformation Board, (3) Data Management Board, (4)
Portfolio Management Board, (5) Change Management Board, and (6) Strategic
Management Board.

42See, for example, GAO-03-584G; and CIO Council, Federal Enterprise
Architecture, Version 1.0.

Page 20 GAO-05-702 DOD Business Enterprise Architecture

decision making. Accordingly, in 2003 we recommended43 that DOD provide
for ensuring stakeholder commitment and buy-in through proactive
architecture marketing and communication activities. (See app. II for our
prior recommendation and its current status.)

In response, the program office defined and approved a strategic
communications plan in March 2004. According to the plan, its purpose is
to direct the flow of information to inform, collaborate with, and educate
DOD internal and external stakeholders about the program. To accomplish
this, the plan identifies categories of stakeholders and includes a
five-phase implementation approach. The five phases are as follows:

ommunication
       tools.
t the program.
However, an assessment to evaluate the effectiveness of communication

43GAO-03-458.

tools and procedures, available resources, and agency or industry best
practices in communicating the program's purpose to the various
stakeholders (e.g., the domains and the military services) has not been
performed. In addition, the program's Acting Assistant Deputy Director for
Communications stated that a systematic approach, including metrics, to
measure the effectiveness of the communications strategy has not been
defined. According to this official, communications activities have been
ad hoc.

Further, DO/IT representatives told us that the program's Web site does
not contain consistent and current information about the program; as a
result, stakeholders' understanding of the BEA is limited. Moreover, the
plan focuses first on internal stakeholders, and it defers efforts to
proactively promote understanding and buy-in with external stakeholders,
such as Congress. The plan defines the internal stakeholders to exclude
key departmental components, such as the military services and the defense
agencies. Instead, it defines internal stakeholders to include only the
program office and the domains.

As a result, both the internal and external DOD stakeholders with whom we
spoke said that they did not have a clear understanding of the program,
including its purpose, scope, approach, activities, and status, as well as
stakeholders' roles and responsibilities. For example, the Installation
and Environment domain representative stated that it was unclear how the
program would achieve one of the program's original goals (i.e., achieving
an unqualified audit opinion by fiscal year 2007), and what the role of
this representative's domain would be in achieving this goal. Similarly,
the Acquisition domain representative stated that the roles and
responsibilities of the domains for the program are confusing, because the
domains should be the entities that are developing the BEA, and not the
program office. According to this representative, the current approach
will result in redundancy and increased program costs.

In addition, the program office's Acting Assistant Deputy Director for
Communications acknowledged that stakeholders are confused, stating that
they do not have a good understanding of either the BEA's goals,
objectives, and intended outcomes or stakeholders' roles and
responsibilities. This official also stated that cross-domain integration
issues remain that require strong DOD leadership to move the
communications efforts beyond conducting awareness activities to achieving
departmentwide buy-in.

  DOD Has Yet to Develop Program Plans and Supporting Workforce Plans, but
  Intends to Make Improvements

The Special Assistant for Business Transformation has recently begun to
better communicate with key external stakeholders, such as Congress. For
example, this official stated that department officials have met with and
intend to hold future meetings with congressional staff to brief them on
the department's plans and efforts to date. Without effective
communication with BEA stakeholders, the likelihood that DOD will be able
to effectively develop and implement its BEA is greatly reduced.

DOD does not have the program plans that it needs to effectively manage
the development, maintenance, and implementation of its BEA. 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. The absence
of effective program planning, including program workforce planning, has
contributed to DOD's limited progress in developing a well-defined
architecture and clearly reporting on its progress to date. Unless its
program planning improves, it is unlikely that the department will be
successful in its attempt to develop, maintain, and implement its BEA.
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.

                 DOD Has Yet to Develop Effective Program Plans

Architecture management guidance states that organizations should develop
and execute program plans, and that these plans should provide an explicit
road map for accomplishing architecture development, maintenance, and
implementation goals.44 Among other things, effective plans should specify
tasks to be performed, resources needed to perform these tasks (e.g.,
funding, staffing, tools, and training), program management and contractor
roles and responsibilities, time frames for completing tasks, expected
outcomes, performance measures, program

44See, for example, GAO-03-584G; and CIO Council, Federal Enterprise
Architecture, Version 1.0.

Page 23 GAO-05-702 DOD Business Enterprise Architecture

management controls, and reporting requirements. We have previously
reported on the program's lack of effective planning and have recommended
that DOD develop BEA program plans.45 (See app. II for our prior
recommendation and its current status.)

Since the program was launched in 2001, DOD has operated without a program
plan. Instead, the department has set target dates for producing a series
of architecture releases as part of three generally defined architecture
increments (see table 3). However, DOD has not clearly defined what the
purpose of the respective increments are, either individually or
collectively, and it has not developed near-, mid-, or long-term plans for
producing these increments. At a minimum, such plans would identify
specific tasks (i.e., provide a detailed work breakdown structure) for
producing the architecture releases that possess predefined content and
utility. These plans would also contain specific and reliable estimates of
the time and resources it will take to perform these tasks.

Also in lieu of program plans, the program office provided us with
documents in November 2004 that the deputy program director stated were to
address our open recommendations for (1) adding needed content and
consistency to the BEA's "As Is" and "To Be" architectural products and
(2) developing a well-defined BEA transition plan. However, the documents
that we were provided were plans for developing plans to address our
recommendations and, thus, were not documents explaining how and when our
recommendations would be addressed.

DOD has recognized the need for program planning. According to the Acting
Assistant Deputy Director for Strategic Planning, the program office had
committed to developing a program baseline by December 2004. According to
the program director, this baseline was to include program goals,
objectives, and activities as well as performance, cost, and schedule
commitments. 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. However, the department has yet to develop this program
baseline. Moreover, while this program baseline would be a useful tool for
strengthening program management, it nevertheless was not to have included
all of the elements of an effective program plan, such as a detailed work
breakdown structure and associated resource estimates. According

45GAO-03-1018.

to senior officials, including the Special Assistant for Business
Transformation and the Deputy Under Secretary of Defense (Financial
Management), the department is drafting a transition plan that is to be
approved by the DBSMC and issued by September 30, 2005. According to these
officials, this plan will include a program baseline and a BEA development
approach.

The lack of well-defined program plans has contributed significantly to
the limited BEA progress that we have reported over the last several
years. Moreover, this absence of program plans has created a lack of
transparency and understanding about what is occurring on the program and
what will occur-both inside and outside the department. It has also
inhibited BEA governance entities' ability to ensure that resources (e.g.,
program office, domains, and contractors) are being effectively used to
achieve worthwhile outcomes and results. Although the contractor's work
statements have provided some additional detail, these task descriptions
lack the specificity necessary to use them effectively to monitor the
contractor's progress and performance. For example, the latest work
statement includes the task "develop business rules based on the available
sources of information," which has been included in prior work statements.
However, the latest work statement does not define the scope of this
effort, nor does it define how this latest task will support prior efforts
to develop business rules. As a result, the extent to which business rules
have been developed and the work remaining to complete the development of
these rules is unclear. Further, the relationship of this task to DOD's
ability to satisfy the objectives for increment 1 also has not been
defined. These architecture relationships need to be defined before the
department can develop explicit plans for effective BEA development.

Moreover, because there is no plan linking them together, it is not clear
how the contractor's work statements and other BEA working groups' efforts
relate to or contribute to larger BEA goals and objectives. For example,
the program office has continued to task the contractor to develop
architecture releases, although the intended use, and thus the explicit
content, of the various releases has not been clearly linked to the goals
and objectives of increment 1. Representatives of the DOD business domains
raised similar concerns with the contractor's work statements, telling us
that the work statements have been vague and have not been linked to the
specific architecture products. According to these representatives, the
department does not know if it is investing resources on tasks that are
needed and add value to the program.

    DOD Has Not Performed Effective Workforce Planning

According to the deputy program director, continuous changes in the
direction and scope of the program have hindered DOD's ability to develop
effective program plans. Without such plans, DOD has been, and will
continue to be, limited in its ability to develop a well-defined
architecture on time and within budget.

As we have previously reported,46 workforce planning is an essential
component of program management. Workforce planning enables an entity to
be aware of and prepared for its current and future human capital needs,
such as workforce size, knowledge and skills, and training. Such planning
involves assessing the knowledge and skills needed to execute the program,
inventorying existing staff knowledge and skills, identifying any
shortfalls, and providing for addressing these shortfalls. Through
effective workforce planning, programs and organizations can have the
right people with the right skills doing the right jobs in the right place
at the right time. Relevant architecture management guidance47 recognizes
the importance of planning for and having adequate human resources in
developing, maintaining, and implementing enterprise architectures.

DOD has yet to perform workforce planning for its BEA program.
Nevertheless, it has established a program office consisting of seven
program divisions (see fig. 1) and staffed the office with 60 government
employees and approximately 300 contractor staff. In addition, the
department has assigned other staff to support the various program
government entities, such as the domains and the DO/IT, and it has
established various formal and informal working groups. However, DOD has
not taken steps to ensure that the people assigned to the program have the
right skill sets or qualifications. In particular, DOD has not defined the
requisite workforce skills and abilities that the department needs in
order to develop, maintain, and implement the architecture. To illustrate,
the program's Assistant Deputy Director for Administrative Support told us
that the position descriptions used to staff the program office were
generic and were not tailored to the needs of an enterprise architecture
program. This official added that, as a result, a person might satisfy the
qualifications contained in the position description, but still not meet
the needs of the

46GAO, A Model of Strategic Human Capital Management, GAO-02-373SP
(Washington, D.C.: Mar. 15, 2002).

47 GAO-03-584G; and CIO Council, Federal Enterprise Architecture, Version
1.0.

Page 26 GAO-05-702 DOD Business Enterprise Architecture

BEA program. In addition to not defining its workforce needs, the program
also does not have an inventory of the capabilities of its currently
assigned program workforce. For example, the Assistant Deputy Director for
Administrative Support told us that the department did not know the number
of individuals assigned to support the various governance entities.

In the absence of an inventory of existing workforce knowledge and skills,
we requested any available information on the qualifications and training
of program staff in key leadership positions (e.g., assistant deputy
directors). In response, the Assistant Deputy Director for Administrative
Support said that such information was not readily available for all
staff, and this official provided us with resumes for 15 program
officials, 4 of whose resumes we were told were created in response to our
request for key staff qualifications and training.

Exacerbating the program's lack of workforce planning is the fact that
several key program office positions are vacant. For example, four of the
seven program division leadership positions (i.e., assistant deputy
directors' positions) are temporarily filled by persons "acting" in this
position (see fig. 2). In addition, key supporting positions within the
program divisions, such as the positions for performance management and
independent verification and validation/quality assurance, are vacant. As
a result, 1 program official is currently acting in three
positions-strategic planning/organization development (includes risk
management), performance management (earned value management system), and
independent verification and validation/quality assurance. Further, two of
the positions this person occupies are incompatible and do not allow for
appropriate separation of duties.48 Specifically, this individual is
responsible for both program performance management and independent
oversight of performance management.

48Separation of duties requires that key duties and responsibilities be
separated among individuals to ensure that effective checks and balances
exist to reduce the risk of error, waste, or wrongful acts or to reduce
the risk of these issues going undetected.

Page 27 GAO-05-702 DOD Business Enterprise Architecture

Figure 2: Organization Chart of the Program Office

Filled

Acting (temporarily filled)

Vacant Source: DOD.

In addition, significant staff turnover has occurred in key program
positions. For example, the program office has had three directors in 4
years, three transition planning directors since March 2004, and four
contracting officer technical representatives responsible for the prime
contract since January 2003.

  DOD Is Not Performing Effective Configuration Management

The Assistant Deputy Director for Administrative Support stated that the
program lacks valid and reliable data about its human capital needs and
current capabilities. This official told us that plans are being developed
to begin addressing this situation. For example, to begin monitoring staff
turnover, the program office recently began maintaining a list of program
staff with start dates. However, this official also told us that the plans
for improving the program's management of its human capital were not
complete, and dates for when the plans would be complete have not been
set.

The absence of effective workforce planning has contributed significantly
to DOD's limited progress to date in developing its architecture. Unless
the program's approach to human capital management improves, it is
unlikely that the department's future efforts to develop, maintain, and
implement the BEA will be successful.

Relevant architecture guidance,49 including DOD guidance,50 recognizes the
importance of configuration management when developing and maintaining an
architecture. The purpose of configuration management is to maintain
integrity and traceability, and control modifications or changes to the
architecture products throughout their life cycles. Effective
configuration management, among other things, enables integration and
alignment among related architecture products. As we have previously
reported,51 an effective configuration management process comprises four
primary elements, each of which should be described in a configuration
management plan and implemented according to the plan. In addition,
responsibility, accountability, and authority for configuration management
should be assigned to a configuration manager. The four elements are:

49See, for example, GAO-03-584G; CIO Council, Federal Enterprise
Architecture, Version 1.0; Electronic Industries Alliance, National
Consensus Standard for Configuration Management, ANSI/EIA-649-1998 (August
1998); Institute of Electrical and Electronics Engineers, Standard for
Application and Management of the Systems Engineering Process 1200-1998
(Jan. 22, 1999); and the Software Engineering Institute, Capability
Maturity Model Integration, Version 1.1 (March 2002).

50DOD, Military Handbook 61A(SE): Configuration Management Guidance (Feb.
7, 2001).

51GAO, National Guard: Effective Management Processes Needed for Wide-Area
Network, GAO-02-959 (Washington, D.C.: Sept. 24, 2002).

     o Configuration identification: 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.
     o Configuration control: 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.
     o Configuration status accounting: Procedures for documenting and
       reporting on the status of configuration items as a product evolves.
       Documentation, such as historical change lists and original
       architecture products, are generated and kept in a library, thereby
       allowing organizations to continuously know the state of a product's
       configuration and to be in a position to make informed decisions about
       changing the configuration.
     o Configuration auditing: 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. Configuration
       audits, both functional and physical, are performed when a significant
       product change is introduced, and they help to ensure that only
       authorized changes are being made.

DOD has a draft configuration management plan and related procedures that
address all four of these areas. However, the plan is not being followed.
For example, according to the plan and procedures, certain product types52
should be placed under configuration management and be assigned a unique
identifier. However, in one case, the verification and

52The product types are (1) system architect encyclopedias and
architecture support products, which include data needed to produce the
operational, system, and technical views of the BEA; (2) functional
requirements, which include policies and laws that the BEA must comply
with; (3) other program deliverables, which include the quality management
plan and the data repository maintenance and support plan; and (4) other
program work products that are not required by the performance work
statement to include program processes, procedures, and user guides.

validation contractor53 reported that DOD had updated one of the BEA
products (i.e., All View-1) that was initially published in Release 2.3,
but that this updated product was not given a unique identifier and a new
release date, and no entry was made in the version history to enable
stakeholders to differentiate between the two versions.

Configuration naming conventions also have not been consistently followed,
resulting in the updates to a single document being given different unique
identifiers than the original document. For example, the November 2003
configuration management plan had the unique identifier
"C0008_05_03_BMMP_Configuration_Management_Plan.doc," which was comprised
of the call number, the task number, the subtask number, and the name of
the document. However, the department later assigned this document the
following unique identifier "Configuration_Management_Plan.doc," which did
not include the call and task numbers. Such inconsistencies could permit
changes to be made to the wrong version of a product, thereby compromising
the integrity and reliability of the information.

Consistent with relevant guidance, the procedures require that a
configuration manager be assigned and that this individual be responsible
for ensuring that the four elements are executed. However, after almost 4
years of architecture products development, a configuration manager has
not been assigned. In addition, while the department established a
configuration control board and chartered it to evaluate and decide
whether to approve proposed product changes, this board is not fully
functioning. Specifically, the board's charter has yet to be approved, and
its authority has been limited to a subset of BEA products. For example,
its authority does not extend to the BEA transition plan.

With respect to configuration status accounting activities that have been
conducted to ensure the integrity of product baselines,54 we were provided

53A verification and validation contractor is a neutral third-party
contractor who is responsible for conducting architecture compliance
evaluations and who provides quality assurance checking on program
information, as well as the proper implementation of the architecture
methodology.

54A baseline is a set of specifications or work products (e.g.,
architecture products) that has been formally reviewed or agreed upon,
that thereafter serves as the basis for further development, and that can
be changed only through change control procedures to maintain integrity. A
baseline represents the assignment of an identifier to a configuration
item and its associated entities.

  DOD Has Yet to Develop a Well-Defined BEA to Guide Its Modernization Efforts

with two reports even though program officials, including the
Configuration Control Board Chair, told us that no configuration status
accounting reports exist and that neither do any auditing procedures and
processes (e.g., audit checklists, agendas, or plans). However, one of
these reports was missing key data, such as the date of the report, the
submitter, and the version of the product currently being reviewed and,
thus, was of limited use. It was also unclear as to which version of the
product was referenced in the report, and these officials told us that the
current baseline of approved configuration items, including the
configuration management plan, is unknown. As a result, configuration
items can be duplicated. For example, the Acting Assistant Deputy Director
for Communications had a second communications plan prepared, and this
official told us that he did not know that a prior draft plan existed.
Because of this, the new strategy did not leverage any of the work that
had previously been done, and duplicative plans exist.

Program officials, including the Configuration Control Board Chair, stated
that they recognize the importance of effective configuration management.
They attributed the absence of effective configuration management to a
number of factors, including no policy or directive requiring it and the
lack of a common understanding of effective configuration management
practices.

The absence of effective configuration management raises questions about
whether changes to the BEA and other relevant products have been justified
and accounted for in a manner that maintains the integrity of the
documentation. Unless this situation is remedied, the department will not
have adequate assurance that it has maintained accountability and ensured
the consistency of information among the products it is developing. In
addition to the governance and planning weaknesses we previously
discussed, the department's lack of effective configuration management has
also contributed to the state of the BEA discussed in the next section of
this report.

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. According to program officials, the state of the BEA reflects
the

Page 32 GAO-05-702 DOD Business Enterprise Architecture

    "As Is" Description, Transition Plan, and Purpose of BEA Releases Are
    Missing

program's focus on meeting arbitrary milestones rather than architecture
content needs. Recognizing the need to develop well-defined architecture
products that have utility and provide a foundation upon which to build,
program officials have stated the department's intent to change its BEA
development approach, refocusing its efforts on fewer, higher quality
products. Until a BEA development approach embodying architecture
development and content best practices is clearly defined and implemented,
it is not likely that DOD will produce an enterprise architecture that
will provide needed content and utility.

As we previously discussed, the various frameworks used to develop
architecture products consistently provide for describing a given
enterprise in both logical (e.g., business, performance, application, and
information) and technical (e.g., hardware, software, and data) terms, and
for doing so for the enterprise's current or "As Is" environment and its
target or "To Be" environment; these frameworks also provide for defining
a capital investment sequencing plan to transition from the "As Is" to the
"To Be" environment. However, the frameworks do not prescribe the degree
to which the component parts should be described to be considered correct,
complete, understandable, and usable-essential attributes of any
architecture. This is because the depth and detail of the descriptive
content depends on what the architecture is to be used for (i.e., its
intended purpose and scope). Relevant architecture guidance55 states that
a well-defined architecture should have a specific and commonly understood
purpose and scope, and that it should be developed in incremental
releases. Using this purpose and scope, the necessary content of
architecture releases can then be defined.

In September 2003,56 we reported that Release 1.0 of the BEA was missing
important content, and we made 62 recommendations to add this content. The
latest releases of the BEA (see table 4) do not address the 32 of our 62
recommendations that are related to the "As Is" description and the

55See, for example, GAO-03-584G; CIO Council, Federal Enterprise
Architecture, Version 1.0; DOD, Department of Defense Architecture
Framework, Version 1.0, Volume 1 (August 2003) and Volume 2 (February
2004); and Institute of Electrical and Electronics Engineers,

Standard for Recommended Practice for Architectural Description of
Software-Intensive Systems 1471-2000 (Sept. 21, 2000).

56GAO-03-1018.

Page 33 GAO-05-702 DOD Business Enterprise Architecture

transition plan.57 Specifically, the releases do not include products
describing the "As Is" environment for those areas of the enterprise that
are likely to change, and they do not include a sequencing plan that
serves as a road map for transitioning from the "As Is" state to the "To
Be" state. For example, the BEA releases do not contain a description of
the "As Is" environment that would include current business operations in
terms of the entities or people who perform the functions, processes, and
activities, and the locations where the functions, processes, and
activities are performed. It also does not describe the data or
information being used by the functions, processes, and activities. As a
result, DOD does not have a picture of its current environment to permit
development of a meaningful and useful transition plan.

The BEA releases also do not contain a transition plan that would include
information such as time frames for phasing out existing systems within
DOD's current inventory and resource requirements for implementing the "To
Be" architecture. As a result, DOD does not yet have a meaningful and
reliable basis for managing the disposition of its existing inventory of
systems or for sequencing the introduction of modernized business
operations and supporting systems. As we previously reported,58 not having
defined the "As Is" operations and technology at this juncture is risky
because it defers until too late in the architecture development cycle
creation of sufficient descriptive content and context to develop an
effective transition plan. (See app. II for our prior recommendations and
their current status.) DOD's architecture framework (DODAF),59 which the
department is using to develop the BEA, does not require the development
of an "As Is" architectural description or a transition plan, and thus
neither has been the focus of the program. However, according to program
officials, including the Chief Architect, the September 2005 BEA release
will include both the "As Is" architectural description and a transition
plan.

In addition, DOD has not clearly linked the purpose of any of the "To Be"
architecture releases produced to date to the goals and objectives of
increment 1. Further, these releases also do not have a clearly defined

57The other 30 prior recommendations pertain to the "To Be" environment
and are discussed in the next section of this report.

58GAO-03-1018.

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

Page 34 GAO-05-702 DOD Business Enterprise Architecture

scope with respect to what business processes and supporting systems each
release would focus on. According to program officials, the last five
versions (i.e., Releases 2.1, 2.2, and 2.3 and the January and March 2005
Updates) support the objectives of increment 160 (see table 3). These
objectives are broad-based strategic goals or outcomes that DOD proposed
achieving through a series of architecture releases. However, DOD did not
define how many releases were needed to achieve each objective and how the
purpose of each release is associated with the objectives. Restated, while
each incremental objective would describe the mission outcome that DOD
intended to achieve via implementation of the series of releases that make
up that increment, the purpose of the releases was not specified in terms
of architectural questions that were related to the objectives. To
illustrate, one objective of increment 1 is to achieve an unqualified
audit opinion for consolidated DOD financial statements. Examples of the
purpose questions that would support this objective include the following:

ade to existing business processes and the
       supporting systems to address material internal control weaknesses
       affecting significant line items on the financial statements?
t to which
they do address the increment 1 objectives.

60Increment 1 objectives include (1) achieving unqualified audit opinion
for consolidated DOD financial statements and (2) achieving total
personnel visibility to include military service members, civilian
employees, military retirees, and other U.S. personnel in a theater of
operations.

Page 35 GAO-05-702 DOD Business Enterprise Architecture

    BEA Products Are Incomplete, Inconsistent, and Not Integrated

According to program officials, including the deputy program director and
the Chief Architect, the prior releases were developed with the goal of
producing as many architecture products as possible within a predefined
schedule. The releases were not developed to provide the content needed to
meet the defined purpose and scope of the release. Until the department
defines the intended purpose and scope of its BEA, including its
incremental releases, and ensures that the architecture products include
adequate descriptions of the "As Is" and "To Be" environments, as well as
a plan for transitioning between the two, it will not have a well-defined
architecture to guide and constrain its systems modernization efforts.

Architecture frameworks61 provide for multiple products, each describing a
particular aspect of the enterprise, such as data or systems. Moreover,
each of these products is interdependent, meaning that they have
relationships with one another that must be explicitly defined and
maintained to ensure that the products form a coherent whole. In light of
these relationships, it is important to develop the architecture products
in a logical sequence that reflects this relationship. DODAF62 recognizes
this need for integration of the products that make up its three "To Be"
views-operational view (OV), systems view (SV), and technical standards
view (TV). (See app. IV for a brief description of the products that
comprise each of these views.) According to the framework, an architecture
must be well structured so that the products can be readily assembled or
decomposed into higher or lower levels of detail, as needed. It should
also be consistent-that is, information elements should be the same
throughout the architecture.

As noted in the previous section, we reported in September 2003,63 that
Release 1.0 of the BEA was missing important content, and we made 62
recommendations to add this content. The latest releases of the BEA do not
adequately address our 30 prior recommendations related to the "To Be"

61See, for example, GAO-03-584G; CIO Council, Federal Enterprise
Architecture, Version 1.0; Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002); and
Institute of Electrical and Electronics Engineers, Standard for
Recommended Practice for Architectural Description of Software-Intensive
Systems 1471-2000 (Sept. 21, 2000).

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

63GAO-03-1018.

description.64 For example, these releases do not include descriptions of
the actual systems to be developed or acquired to support future business
operations and the physical infrastructure (e.g., hardware and software)
that will be needed to support the business systems. As a result, the "To
Be" environment lacks the detail needed to provide DOD with a common
vision and frame of reference for defining a transition plan to guide and
constrain capital investments and, thus, to effectively leverage
technology to orchestrate logical, systematic change and to optimize
enterprisewide mission performance. (See app. II for details on the status
of our prior recommendations.)

In addition, the respective products of each of the latest BEA releases65
continue to be inconsistent and not integrated, because key architecture
products were either not developed or not updated to reflect changes made
in other products. Examples of where Releases 2.2 and 2.3 are not
consistent and integrated follow:

     o In Release 2.2, the department updated the system data exchange matrix
       (SV-6), which assigns attributes (e.g., timeliness) to the data to be
       exchanged (e.g., Performance Metrics) between system functions-
       "Manage Business Enterprise Reporting" and "Establish and Maintain
       Performance Information"-to support business operations. However, the
       OV-3 in Release 2.2, which shows the attributes of the information to
       be exchanged to support operations, is not consistent with the
       attributes defined in the SV-6. For example, in the OV-3, the
       attribute referred to as "timeliness" is defined in terms of either
       "hours," "minutes," or "seconds;" however, in the SV-6, the attribute
       referred to as "timeliness" is only defined in terms of either "high,
       medium, or basic."
     o In Releases 2.2 and 2.3, the department updated the respective
       operational event-trace description product (OV-6c), which depicts
       when activities are to occur within operational processes. However,
       the department did not update, in either release, the operational
       activity model (OV-5), which shows the operational activities (or
       tasks) that are to occur and the input and output flows among these
       activities. For example, the OV-6c shows the sequence of the
       activities to occur for the

64The other 32 prior recommendations pertain to the "As Is" environment
and the transition plan and are discussed in the previous section of this
report.

65We reviewed Releases 2.2, 2.2.1, and 2.3 and the March 2005 Update.

Page 37 GAO-05-702 DOD Business Enterprise Architecture

process labeled "produce obligation reports;" however, the activities

shown in the OV-5 were not associated with this process.

The latest releases also do not provide for traceability among the
architecture products by clearly identifying the linkages and dependencies
among the products, such as associating processes (e.g., produce
obligation reports) with activities (e.g., compare expense to obligation)
in the operational views and then associating these same processes to
systems (e.g., financial reporting system) in the systems view. In
addition, the linkage between the two functions (i.e., "Manage Business
Enterprise Reporting" and "Establish and Maintain Performance
Information") previously discussed cannot be traced to the OV-3 in Release
2.2. This is because Release 2.2 did not include an SV-5, which would
provide a traceability of system functions back to operational activities.
The lack of an updated SV-5 also raises questions as to whether all
operational requirements are satisfied by the system functions. In
addition, the architecture products were not developed in a logical
sequence, as called for in relevant guidance and standards66 (e.g., the
OV-6c, which shows the timing or sequencing of activities, was built
before the OV-5, which shows the activities that are to occur).

Further, according to the verification and validation contractor, the
department has yet to address 242 of its 299 outstanding comments since
Release 1.0. The verification and validation contractor also cited similar
concerns, as previously described, for Releases 2.2 and 2.3. Specifically,
the contractor reported that the BEA products were not integrated, and
that key products were missing or had not been updated-such as the
operational nodes connectivity description (OV-2) and the operational
information exchange matrix (OV-3). In its report on the January 2005
Update,67 the contractor stated that the architecture products were
developed in an order different from that recommended in DODAF, and that
the dependency relationships between and among BEA products were not
clearly depicted. For example, the contractor reported that the logical

66See, for example, GAO-03-584G; CIO Council, Federal Enterprise
Architecture, Version 1.0; Office of Management and Budget, Federal
Enterprise Architecture Business Reference Model, Version 1.0 (2002); DOD,
Department of Defense Architecture Framework, Version 1.0, Volume 1
(August 2003) and Volume 2 (February 2004); and Institute of Electrical
and Electronics Engineers, Standard for Recommended Practice for
Architectural Description of Software-Intensive Systems 1471-2000 (Sept.
21, 2000).

67IV&V Evaluation Summary Report BEA January 31, 2005, Update, Version 2
(Feb. 1, 2005).

data model (OV-7) was to have been developed using the OV-3, OV-5, and
OV-6c artifacts as inputs. However, this was not the case. Instead, the
OV-7 was developed using information that may have been reverse engineered
from existing systems and architectures external to the BEA. The
contractor reported that unless these dependencies are clearly documented
and depicted, new systems may be implemented without satisfying all
operational requirements, with missing functions and interfaces or based
on obsolete data models, recreating many of the problems the modernization
is intended to resolve. The contractor also reported that the resulting
technical problems in the OV-7 could interfere with the department's
achievement of the increment 1 objectives.

The March 2005 Update also did not have fully integrated products.
Specifically, while some of the products were integrated, this integration
occurred at the highest level only and could not be found at lower levels
of decomposition (e.g., subprocesses and subactivities) within the
architecture. For example, the level of integration does not enable the
user to determine all information inputs for the activities at all levels,
nor does it clearly reflect the dissemination or use of the information
after it has been processed. In addition, this update did not include key
architecture products that are recommended by DODAF-such as the system
data exchange artifact (SV-6), which assigns attributes (e.g., timeliness)
to the data to be exchanged between system functions and the system
inventory (SV-8). The SV-8 provides a basis for portfolio investment
decisions by depicting the evolution of systems, systems integration, and
systems improvements over time. We also found that the architecture was
not user friendly in that it was difficult to navigate. For example, the
linkages among the architecture products did not always work, thereby,
requiring manual navigation through the architecture to find the linkages.
This would take hours to do, especially since it was complicated by the
fact that certain artifacts (e.g., diagrams) could not be read online and
had to be printed.

Relatedly, as shown in table 4, the latter BEA releases have not included
all of the recommended DODAF products. DODAF recommends that the BEA
include 23 out of 26 possible architecture products to meet the
department's stated intention to use the BEA as the basis for
departmentwide business and systems modernization. However, Release

2.2 of the architecture included only 16 of the 23 recommended
architecture products, and 6 of the 16 products (OV-1, OV-2, OV-3, OV-4,
OV-5, and SV-9) were actually Release 2.0 products that had not been
updated to align with the changes that had been made to the 10 products
that were updated in this release. Similarly, Release 2.3 included only 4
products; the January 2005 Update included 6, and the March 2005 Update
included 15. According to the Chief Architect, all prior architecture
products that were not included in a specific release or update are
obsolete. For example, Release 2.2 included 16 architecture products, of
which 10 had been updated. The remaining 6 products had not been updated,
but they were still considered to be valid because they were included in
this release. This means that for all releases and updates, only those
products included in the release or update are relevant. For example, DOD
updated 15 products and included them in the March 2005 Update; therefore,
as of March 2005, only these 15 products were considered to be valid
artifacts of the BEA.

Table 4: List of DOD's Architecture Framework Products Included in Each Release

                                            Releases and dates      
                                            issued                  
                                1.0, 2.0, c 2.1,d 2.2,d,e,f 2.3, d     Mar    
                                            Jan                     
                                May   Feb   Apr July Nov 2005         2005    
Product titlea Recommended b 2003  2004  2004 2004 2004          Updated,g 
                                            Updated,g               
All view (AV)h                                                   

            Page 40 GAO-05-702 DOD Business Enterprise Architecture

AV-1 Overview and Summary Information          o    o  o   o   o  o  o  o  
AV-2 Integrated Dictionary                     o    o  o       o  o  o  o  
Operational view (OV)i                                                  
OV-1 High-Level Operational Concept Graphic    o    o  o       o        o  
OV-2 Operational Node Connectivity Description o    o  o       o        o  
OV-3 Operational Information Exchange Matrix   o    o  o       o        o  
OV-4 Organizational Relationships Chart        o    o  o       o        
OV-5 Operational Activity Model                o    o  o       o     o  o  
OV-6a Operational Rules Model                  o    o  o       o     o  o  
OV-6b Operational State Transition Description o    o  o       o        
OV-6c Operational Event-Trace Description      o       o   o   o  o  o  o  
OV-7 Logical Data Model                             o  o       o  o  o  o  
Systems view (SV)j                                                      
SV-1 Systems Interface Description             o    o  o       o        o  
SV-2 Systems Communications Description             o                   
SV-3 Systems-Systems Matrix                    o    o  o                
SV-4 Systems Functionality Description         o    o  o       o        o  
SV-5 Operational Activity to Systems           o    o  o                o  
Traceability Matrix                                                     
SV-6 Systems Data Exchange Matrix              o    o  o       o        

(Continued From Previous Page)
                                                    Releases and dates issued
                           1.0, 2.0, 2.1,d 2.2,d,e,f 2.3,    Jan       Mar    
                                 c                    d             
Product     Recommended May  Feb  Apr   July 2004 Nov  2005      2005      
titlea      b           2003 2004 2004            2004 Updated,g Updated,g 
SV-7                                                             
Systems                                                          
Performance     o        o    o                                  
Parameters                                                       
Matrix                                                           
SV-8                                                             
Systems                                                          
Evolution                                                        
Description     o        o                                       

SV-9 Systems Technology Forecast              o       o  o     o        o  
SV-10a Systems Rules Model                    o                      
SV-10b Systems State Transition Description   o                      

SV-10c Systems Event-Trace Description    o        o  o      
SV-11 Physical Schema                                 
Technical standards view (TV)k                        
TV-1 Technical Standards Profile          o        o  o      o          o  
TV-2 Technical Standards Forecast         o        o  o                 o  

Source: GAO analysis based on DOD data.

aSee appendix IV for a brief description of each product.

bProducts that are recommended by DODAF based on DOD's intended use of the
BEA.

cAccording to the verification and validation contractor, the AV-1
included in this release had not been updated to align with changes the
department had made to the other products that were included in this
release.

dThese releases do not include the "As Is" architectural description and a
transition plan.

eIn August 2004, DOD updated this release to incorporate the Standard
Financial Information Structure (SFIS) in the OV-7 (Logical Data Model).
According to DOD, the SFIS will standardize the coding of financial data.
This updated release (Release 2.2.1) did not include any additional
architecture products.

fAccording to the AV-1 and the narrative summary, the following
architecture products had not been updated to align with changes the
department had made to the other products that were included in this
release: OV-1, OV-2, OV-3, OV-4, OV-5, and SV-9.

gAccording to program officials, the next BEA release (Release 3.0) is due
in September 2005. Until then, all releases will be referred to as
updates.

hAll-view products are to provide for overarching aspects of the
architecture that relate to additional views (e.g., operational and
systems views) and provide the scope and context for the architecture
(e.g., to guide and constrain systems investment decisions).

iOperational view products are to depict the organizationwide business
environment and activities that need to occur to achieve the "To Be"
state.

jSystems view products are to describe the set of systems capabilities
that are to provide DOD with accurate, reliable, and timely access to
business management and associated financial information.

kTechnical standards view products contain the set of technology
constraints that will drive the manner of system implementation.

Program and contractor officials, including the Acting Assistant Deputy
Director for Transition Planning, stated that although the department's
first release of its architecture included a fairly consistent and
integrated set of architecture products, DOD's current releases do not
because the

    BEA Releases Have Not Been Approved

department did not update all the recommended architecture products. These
officials, including the Chief Architect, also stated that, as a result,
the utility of the architecture is limited. However, according to key
program officials, including the Special Assistant for Business
Transformation and the Chief Architect, the integration of the
architecture products was not the focus; rather, DOD's primary goal was to
produce as many products as it could within a specified time period (see
tables 3 and 4).

Recognizing these weaknesses, the Special Assistant for Business
Transformation stated that the department intends to reduce the scope of
the architecture and revise the development approach, which will be
reflected in the September 30, 2005, architecture release. However,
according to program officials, including the Special Assistant for
Business Transformation, the September 2005 BEA release will not be
comprehensive (i.e., it will not meet all the act's requirements).
Further, the department has yet to develop plans and a methodology to
execute this new focus and vet it through the department. Program
officials also stated that as a result of the new focus, they are trying
to decide which products from prior releases could be salvaged and used.

Nevertheless, the department has spent almost 4 years and approximately
$318 million in obligations to develop an architecture that is incomplete,
inconsistent, and not integrated and, thus, has limited utility. Until the
department develops an approved, well-defined architecture that includes a
clear purpose and scope and integrated products, it remains at risk of not
achieving its intended business modernization goals and of not having an
architecture that the stakeholders can use to guide and constrain ongoing
and planned business systems investments to prevent duplicative and
noninteroperable systems.

Relevant architecture guidance68 state that architecture versions should
be approved by the committee overseeing the development and maintenance of
the architecture; the CIO; the chief architect; and senior management,
including the department head. Such approval recognizes and endorses the
architecture for what it is intended to be-a corporate tool for managing
both business and technological change and transformation. Consistent with
guidance, DOD has stated its intention to approve all BEA releases.

68See, for example, GAO-03-584G; and CIO Council, Federal Enterprise
Architecture, Version 1.0.

Page 42 GAO-05-702 DOD Business Enterprise Architecture

  DOD Has Yet to Fully Address Most of Our Other Recommendations

However, Release 1.0 of the BEA is the only release that DOD reports as
having been approved. As we previously reported,69 DOD officials told us
that Release 1.0 was approved by the former Executive Committee, the
department's CIO as a member of the Executive Committee, and the DOD
Comptroller on behalf of the Secretary of Defense in May 2003, but they
also said that documentation to verify these approvals did not exist.

Since Release 1.0, DOD has issued five additional releases and two
updates. None of these have been approved by any individual or committee
in the BEA governance structure. According to program officials, including
the Special Assistant for Business Transformation and the Chief Architect,
Release 3.0 of the BEA, which will be issued in September 2005, will be
the next release of the architecture to be approved by the department.
These officials stated that the architecture releases have not been
approved because the department did not have a governance structure and
process in place for doing so. Without the appropriate approvals, buy-in
to and recognition of the BEA as an institutionally endorsed change
management and transformation tool is not achievable.

In addition to the governance, planning, and content issues previously
discussed, we have made other recommendations relative to DOD's ability to
effectively develop, maintain, and implement an enterprise architecture
for its business operations. To date, the department has fully addressed
one of our other recommendations, which is to report every 6 months to the
congressional committees on the status of the BEA effort, but it has yet
to fully address the remaining recommendations. (See app. II for details
on the status of these recommendations.) For example, the department has
yet to address our recommendations to

     o develop a position description for the Chief Architect that defines
       requisite duties and responsibilities,
     o update policies to assign responsibility and accountability for
       approving BEA releases,

69GAO-03-1018.

     o update policies to address the issuance of waivers for business
       systems that are not compliant with the architecture but are
       nevertheless justified on the basis of documented analysis, and
     o develop and implement a quality assurance plan.

According to the program director and deputy director, the current state
of the BEA, including progress in addressing our recommendations, reflects
the program's prior focus on producing as many products as it could within
a specific time period. The focus had not been on the content and quality
of the releases, but rather on the timing of their delivery. In contrast,
our recommendations have all focused on establishing the means by which to
deliver a well-defined BEA and ensuring that delivered releases of the
architecture contain this requisite content. Until DOD adopts the kind of
approach embodied in our recommendations, it is unlikely that it will
produce a well-defined BEA within reasonable time frames and at an
affordable cost.

Having and using a well-defined enterprise architecture are essential for

  Conclusions

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. In our view, the state
of the architecture is due largely to long-standing architecture
management weaknesses that the recommendations we have made over the last
4 years are aimed at correcting, as well as the department's prior focus
on producing as many products as it could within a specific time period.
To date, the department has not taken adequate steps to implement most of
our recommendations.

While recent steps to begin revamping its BEA governance structure and to
begin program planning are positive first steps and are consistent with
some of the recommendations that we made to lay a foundation for
architecture development, maintenance, and implementation, much more
remains to be accomplished. Thus, it is imperative for the department to
move swiftly to strengthen its BEA program in a manner that incorporates
our prior recommendations and recognizes its current architecture
management capabilities. Until it does, the department will continue to
put billions of dollars at risk of being invested in systems that are
duplicative, are not interoperable, cost more to maintain than necessary,
and do not optimize mission performance and accountability.

We recommend that the Secretary of Defense direct the Deputy Secretary

  Recommendations for

of Defense, as the chair of the DBSMC and in collaboration with DBSMC

  Executive Action members, to

     o immediately fully disclose the state of its BEA program to DOD's
       congressional authorization and appropriations committees, including
       its limited progress and results to date, as well as specific plans
       and commitments for strengthening program management and producing
       measurable results that reflect the department's capability to do so;
     o ensure that each of our recommendations related to the BEA management
       and content are reflected in the above plans and commitments; and
     o ensure that plans and commitments provide for effective BEA workforce
       planning, including assessing workforce knowledge and skills needs,
       determining existing workforce capabilities, identifying gaps, and
       filling these gaps.

In written comments on a draft of this report signed by the Special

  Agency Comments

Assistant for Business Transformation in the Office of the Under Secretary
of Defense (Acquisition, Technology, and Logistics) and the Deputy Under
Secretary of Defense (Financial Management) (reprinted in app. V), the
department concurred with our recommendations and stated its intent to
implement them. Specifically, DOD stated that it would (1) disclose plans,
progress, and results of its BEA efforts to DOD's congressional
committees;

(2) address our recommendations related to BEA management and content; and
(3) assess its workforce needs and adjust its workforce to meet
requirements.

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 (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 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 [email protected]. 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 VI.

Randolph C. Hite

Director

Information Technology Architecture and Systems Issues

Appendix I

                       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.

To determine whether DOD has established an effective governance structure
for its efforts, we reviewed program documentation-such as approved
charters for the Executive and Steering Committees, the Domain Owners
Integration Team (DO/IT), the Transformation Support Office,1 and the
Defense Business Systems Management Committee-and the communications
strategy and supporting documents. We compared these documents with the
elements in our Enterprise Architecture Management Maturity Framework and
federal Chief Information Officer (CIO) Council guidance.2

To determine whether DOD has developed program plans, including supporting
workforce plans, we interviewed the Director and deputy program director,
and the assistant deputy directors for communications, strategic planning,
and transition planning. We also reviewed draft plans that showed the
department's intent to address our prior recommendations for the content
previously missing from the "As Is" architecture and the transition plan.
We also reviewed the department's March 15, 2005, annual report to
Congress,3 briefing slides on the department's BEA development approach,
and the various statements of work for the contractor responsible for
extending and evolving the architecture. For human capital, we reviewed
program organization charts and position descriptions for key program
officials. In addition, we interviewed key program officials, such as the
assistant deputy directors for communications, strategic planning, and
enterprise architecture, to discuss their roles and responsibilities.

1In March 2005, DOD changed the name of the program office from the
Business Modernization and Systems Integration Office to the
Transformation Support Office.

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

3Department of Defense, Annual Report to Congressional Defense Committees:
Status of the Department of Defense's Business Management Modernization
Program (Mar. 15, 2005).

Appendix I Objectives, Scope, and Methodology

To determine whether effective configuration management was being
performed, we reviewed the configuration management plan and associated
procedures,4 and the draft configuration control board charter. We
compared these documents with best practices, including the federal CIO
Council's Practical Guide, to determine the extent to which DOD had
adopted key management practices. In addition, we reviewed meeting minutes
to determine whether the board was operating effectively and performing
activities according to best practices. We also interviewed program
officials, including the Chief Architect and the Configuration Control
Board Chair, to discuss the process and its effect on the department's
ability to develop and maintain the BEA products.

To determine whether DOD had developed well-defined BEA products, we
reviewed the latest BEA releases (i.e., Releases 2.2, 2.2.1, and 2.3 and
the March 2005 Update)5 and the program's verification and validation
contractor's reports documenting its assessment of Releases 2.2 and 2.3
and the January 2005 Update of the architecture. To determine whether
these BEA releases addressed our prior recommendations on missing
architecture content and inconsistencies, we requested contractual change
requests related to our recommendations. Program officials, including the
program director and Chief Architect, stated that change requests to
address our recommendations do not exist. We also reviewed the
verification and validation contractor's assessment of DOD's efforts to
address its outstanding comments on prior versions of the BEA and DOD
stakeholders'6 comments on Release 2.2 of the BEA. Further, we reviewed
DOD's approach to developing the architecture products since Release 1.0
and compared it with relevant guidance, such as DOD's architecture
framework. We also observed architecture walk-through sessions held by
program officials to discuss concerns and provide progress updates. In
addition, we interviewed program officials, including the Special
Assistant for Business Transformation, Deputy Under Secretary of Defense

4We reviewed multiple versions of these documents during this review. For
example, we reviewed the August and November 2003 and the April 2004
versions of the configuration management plan, as well as the May and
November 2004 versions of the configuration control procedure document.

5We did not review the January 2005 Update because the department provided
this release at the same time it provided the March 2005 Update. As a
result, we reviewed the content of the March release.

6DOD stakeholders include the program office staff, business domains,
mission area, military services, and defense agencies.

Appendix I Objectives, Scope, and Methodology

(Financial Management), Chief Architect, the Configuration Control Board
Chair, and the verification and validation contractor to discuss the
development and maintenance of the BEA products.

To determine the status of DOD's efforts to address our other
recommendations related to BEA development and maintenance, we reviewed
program documentation, such as the draft quality assurance plan, and
compared them with the elements in our Enterprise Architecture Management
Maturity Framework. We requested updates to the Information Technology
Portfolio Management Policy and the position description for the Chief
Architect. We also interviewed program and contractor officials, such as
the Director and deputy program director, and the assistant deputy
directors for quality assurance and communications.

To augment our documentation reviews and analyses, we attended regularly
scheduled meetings, such as the DO/IT meetings, the program execution
status meetings, and configuration control board meetings. We also held
monthly teleconferences with the program and deputy program directors to
discuss any issues and to obtain explanations or clarification on the
results of our audit work.

We did not independently validate cost and budget information provided by
the department.

We conducted our work primarily at DOD headquarters in Arlington,
Virginia, and we performed our work from July 2004 through May 2005, in
accordance with generally accepted government auditing standards. We
requested comments on a draft of this report from the Secretary of Defense
or his designee. Written comments from the Special Assistant for Business
Transformation in the Office of the Under Secretary of Defense
(Acquisition, Technology, and Logistics) and the Deputy Under Secretary of
Defense (Financial Management) are addressed in the "Agency Comments"
section of this report and are reprinted in appendix V.

Appendix II

Status of Prior Recommendations on DOD's Development and Maintenance of Its
Business Enterprise Architecture

GAO report information and    Implemented?                                 
recommendation Yes            Partial No   DOD comments and our assessment
GAO-01-525: Information                    
Technology: Architecture                   
Needed to Guide Modernization              
of DOD's Financial                         
Operations. May 17, 2001.                  
(1) The Secretary immediately              DOD has developed the           
issue a Department of              X       Information Technology          
Defense (DOD) policy that                  Portfolio Management policy.    
directs the development,                   While this policy, in           
implementation, and                        conjunction with the            
maintenance of a business                  overarching Global Information  
enterprise architecture                    Gridb policy, assigns           
(BEA).a                                    responsibilities for the        
                                                 development, implementation, 
                                                           and maintenance of 
                                                 the BEA, it does not provide 
                                                    for having accountability 
                                              for and approval of updates to  
                                              the architecture                
                                                   processes for architecture 
                                                    oversight and control and 
                                              architecture review and         
                                              validation, and it does not     
                                              address the issuance of waivers 
                                                         for business systems 
                                              that are not compliant with the 
                                                        BEA but are           
                                              nevertheless justified on the   
                                              basis of documented             
                                                  analysis. Program officials 
                                                   stated that the department 
                                                 plans to revise this policy, 
                                                   but they did not provide a 
                                              time frame for doing so.        

(2) The Secretary immediately       X  We previously reported that DOD had 
modify the Senior                                          established the 
Financial Management Oversight          Executive and Steering Committees, 
Council's charter to                                            which were 
o  designate the Deputy Secretary      advisory in nature. The department  
of Defense as the                                   also had               
Council Chair and the Under                  established the Domain Owners 
Secretary of Defense                                      Integration Team 
(Comptroller) as the Council          (DO/IT) and stated that these three  
vice-Chair; and                       bodies were                          
o  empower the council to serve as           responsible for governing the 
DOD's BEA steering                                       program. However, 
committee, giving it the                these groups had not been assigned 
responsibility and authority to                           responsibilities 
ensure that a DOD BEA is developed          for directing, overseeing, and 
and maintained in                                       approving the BEA. 
accordance with the DOD Command,               According to key department 
Control,                                            officials, these three 
Communications, Computers,                      entities will be replaced. 
Intelligence, Surveillance,                      Specifically, in February 
and Reconnaissance (C4ISR)             2005, DOD established the Defense   
Architecture Framework.                             Business               
                                                 Systems Management Committee 
                                                               (DBSMC), which 
                                          replaced the Executive and Steering 
                                                                  Committees. 
                                          According to its charter, the DBSMC 
                                                               is accountable 
                                         and responsible for the program. The 
                                                                   department 
                                           plans to establish an underlying   
                                                      management              
                                            structure to support the DBSMC in 
                                                             carrying out its 
                                            roles and responsibilities. In    
                                                  addition, program           
                                                    officials have stated the 
                                                    department's intention to 
                                            replace the DO/IT with the DOD    
                                                      Enterprise              
                                             Transformation Integration Group 
                                                              whose roles and 
                                              responsibilities and concept of 
                                                       operations have yet to 
                                         be defined.                          

Appendix II Status of Prior Recommendations on DOD's Development and
Maintenance of Its Business Enterprise Architecture

                         (Continued From Previous Page)

            Page 51 GAO-05-702 DOD Business Enterprise Architecture

IGAO report information and   mplemented?                                  
recommendation Yes            Partial No  DOD comments and our assessment
(3) The Secretary immediately                   The Assistant Secretary of 
make the Assistant                 X                 Defense (Networks and 
Secretary of Defense                      Information Integration)/Chief   
(Command, Control,                        Information Officer              
Communications &                           (ASD(NII)/CIO) is a member of   
Intelligence), in                                   the recently           
collaboration with the                    
Under Secretary of Defense                  established DBSMC; however, it 
(Comptroller), accountable to                        is not known how this 
the Senior Financial                      committee will operate.          
Management Oversight Council              
for                                       
developing and maintaining a              
DOD BEA.                                  
                                             DOD established a program office 
                                                            in July 2001. DOD 
In fulfilling this                                  also appointed a Chief 
responsibility, the Assistant                 Architect, and, according to 
Secretary                                 
appoint a Chief Architect for              the department, it has adequate 
DOD business management                                program funding and 
modernization and establish                       staff for developing and 
and adequately staff and                     maintaining its architecture. 
fund an enterprise                        However, DOD has yet to define   
architecture program office               the roles and                    
that is                                   
responsible for developing                responsibilities for the Chief   
and maintaining a DOD-wide                Architect or provide a           
BEA in a manner that is                   time frame for doing so.         
consistent with the framework             
defined in the Chief                      
Information Officer (CIO)                 
Council's                                 
published guide for managing              
enterprise architectures. In              
particular, the Assistant                 
Secretary should take                     
appropriate steps to ensure               
that the Chief Architect                  
o  obtains executive buy-in               
and support;                              
o  establishes architecture               
management structure and                  
controls;                                 
o  defines the architecture               
process and approach;                     
o  develops the baseline                  
architecture, the target                  
architecture, and the                     
sequencing plan;                          
o  facilitates the use of the             
architecture to guide                     
business                                  
management modernization                  
projects and investments;                 
and                                       
o  maintains the                          
architecture.                             
(4) The ASD(NII)/CIO report               The ASD(NII)/CIO is a member of  
at least quarterly to the          X      the recently                     
Senior Financial Management                 established DBSMC; however, it 
Oversight Council on the                             is not known how this 
Chief Architect's progress in             committee will operate.          
developing a BEA, including               
the Chief Architect's                     
adherence to enterprise                   
architecture                              
policy and guidance from the                    The Steering Committee was 
Office of Management and                            briefed monthly by the 
Budget (OMB), the CIO                            program office on various 
Council, and DOD.                            program activities until June 
                                                  2004, when it held its last 
                                                    meeting. As a result, the 
                                                   Steering Committee was not 
                                                       updated on the content 
                                               and status of Releases 2.2 and 
                                                          2.3 and the January 
                                               2005 and March 2005 Updates of 
                                                           the BEA. According 
                                              to program officials, the DBSMC 
                                                            held an executive 
                                             session in February 2005 and its 
                                                            second meeting in 
                                             April 2005, and the committee    
                                             will initially hold              
                                             monthly meetings.                
(5) The Senior Financial                  The Deputy Chief Financial       
Management Oversight Council       X      Officer briefed the              
report to the Secretary of                Secretary of Defense in November 
Defense every 6 months on                                2003 on behalf of 
progress in developing and                DOD's Comptroller, who chairs    
implementing a BEA.                       the Executive                    
                                             Committee. According to the      
                                             program director, the            
                                             Secretary of Defense has not     
                                             been briefed since               
                                             November 2003 on the             
                                             department's progress in         
                                             developing and implementing the  
                                             BEA.                             

Appendix II Status of Prior Recommendations on DOD's Development and
Maintenance of Its Business Enterprise Architecture

                         (Continued From Previous Page)

GAO report information and       ImplemenYes ted? No DOD comments and our  
recommendation                   Partial     assessment                    
(6) The Secretary report every 6             Senate Report 107-213 directs 
months to the                    X                     that the department 
congressional defense                         report every 6 months on the 
authorizing and appropriating                    status of the BEA effort. 
committees on progress in                     DOD submitted status reports 
developing and implementing                         on January 31 and July 
a BEA.                                       31, 2003; January 31 and July 
                                                          30, 2004; and March 
                                                  15, 2005. The 2003 and 2004 
                                                       reports were submitted 
                                                by DOD's Comptroller but were 
                                                            not signed by the 
                                                  members of the Executive or 
                                                         Steering Committees. 
                                                The 2005 report was signed by 
                                                             the Acting Under 
                                                     Secretary of Defense for 
                                                 Acquisition, Technology, and 
                                                    Logistics, who is the     
                                                  vice-chair of the DBSMC.    
GAO-03-458: DOD Business Systems             
Modernization:                               
Improvements to Enterprise                   
Architecture                                 
Development and Implementation               
Efforts Needed.                              
February 28, 2003.                           

(1) The Secretary of Defense      X    We previously reported that DOD had 
ensure that the enterprise                                 established the 
architecture executive committee      Executive and Steering Committees,   
members are singularly                which were                           
and collectively made explicitly      advisory in nature. The department   
accountable to the                    had also                             
Secretary for the delivery of the     established the DO/IT and stated     
enterprise architecture,              that these three                     
including approval of each                     bodies were responsible for 
release of the architecture.                        governing the program. 
                                         However, these groups had not been   
                                         assigned                             
                                         responsibilities for directing,      
                                         overseeing, and                      
                                         approving the BEA. According to key  
                                         department                           
                                         officials, these three entities will 
                                         be replaced.                         
                                          Specifically, in February 2005, DOD 
                                                              established the 
                                          DBSMC, which replaced the Executive 
                                                                 and Steering 
                                                 Committees. According to its 
                                                        charter, the DBSMC is 
                                         accountable and responsible for the  
                                         program. The                         
                                           department plans to establish an   
                                                      underlying              
                                         management structure to support the  
                                         DBSMC in                             
                                                   carrying out its roles and 
                                               responsibilities. In addition, 
                                         program officials have stated the    
                                         department's                         
                                         intention to replace the DO/IT with  
                                                       the DOD                
                                                    Enterprise Transformation 
                                                     Integration Group, whose 
                                               roles and responsibilities and 
                                                        concept of operations 
                                         have yet to be defined.              
(2) The Secretary of Defense            DOD has a strategic communications 
ensure that the enterprise          X                       plan; however, 
architecture program is supported      the plan has yet to be implemented. 
by a proactive                                            According to the 
marketing and communication            communications team, its activities 
program.                                                 have been limited 
                                              to raising awareness because it 
                                                       lacks the authority to 
                                         fully implement the other components 
                                                            of its plan, such 
                                            as achieving buy-in. According to 
                                                           program officials, 
                                         the department intends to revise the 
                                         governance                           
                                                     structure, including the 
                                                  communications strategy, in 
                                         September 2005.                      

Appendix II Status of Prior Recommendations on DOD's Development and Maintenance
                    of Its Business Enterprise Architecture

                         (Continued From Previous Page)

Implemented? GAO report information and recommendation Yes Partial No DOD
comments and our assessment

(3) The Secretary of Defense ensure that the quality assurance function

     o includes the review of adherence to process standards and reliability
       of reported program performance,
     o is made independent of the program management function, and
     o is not performed by subject matter experts involved in the development
       of key architecture products.

X DOD has established a quality assurance function; however, this function
does not address process standards and program performance, nor is it an
independent function. Further, DOD subject matter experts continue to be
involved in the quality assurance function. Program officials stated that
the department had yet to address our recommendation, and they could not
provide a time frame for when they would begin addressing this
recommendation.

GAO-03-1018: DOD Business Systems Modernization: Important Progress Made
to Develop Business Enterprise Architecture, but Much Work Remains.
September 19, 2003.

            Page 53 GAO-05-702 DOD Business Enterprise Architecture

(1) The Secretary of Defense or   X   DOD has taken some actions, but      
his appropriate designee              these actions do                     
implement the core elements in        not fully address our previous       
our Enterprise Architecture           concerns. For example, DOD has  o    
Framework for Assessing and           begun to revise its governance       
Improving Enterprise Architecture     structure to provide                 
Management that we identify in        
this report as not satisfied,         for improved management and          
including ensuring that minutes       oversight, such as establishing the  
of the meetings of the executive      DBSMC and assigning it               
body charged with directing,          accountability and responsibility    
overseeing, and approving the         for directing,                       
architecture                          
are prepared and maintained.          overseeing, and approving the BEA;   
                                         and  o  developed a configuration    
                                         management plan and the related      
                                         procedures, and established a        
                                         configuration control board.         
                                         However, the department has not  o   
                                         established additional governance    
                                         entities to                          
                                         support the DBSMC and outlined their 
                                         roles and responsibilities;  o       
                                         updated the policy for BEA           
                                         development,                         
                                         maintenance, and implementation;  o  
                                         included the missing scope and       
                                         detail in the BEA;  o  finalized,    
                                         approved, and effectively            
                                         implemented the                      
                                         plan, procedures, and charter        
                                         governing the configuration          
                                         management process; and  o           
                                         developed specific results-oriented  
                                         performance                          
                                         metrics.                             
(2) The Secretary of Defense or       Of the 29 elements, program          
his appropriate designee            X officials stated that 3              
update version 1.0 of the             were not applicable and that it      
architecture to include the 29        planned to address an additional 11  
key elements governing the "As        by January 2005. However, these      
Is" architectural content that        officials did not provide any        
our report identified as not          documentation to support             
being fully satisfied.                
                                         this statement. Instead, they        
                                         provided a draft plan that shows the 
                                         department's intent to develop a     
                                         detailed action plan to guide the    
                                         development of an "As Is"            
                                         architecture. According to program   
                                         officials, they plan to update the   
                                         "As Is" architectural description in 
                                         September 2005.                      

Appendix II Status of Prior Recommendations on DOD's Development and
Maintenance of Its Business Enterprise Architecture

(Continued From Previous Page) 
                                  Implemented?
GAO report information and     Yes Partial No DOD comments and our         
recommendation                                assessment                   
(3) The Secretary of Defense               X  DOD officials have provided  
or his appropriate designee                   no evidence that this        
update version 1.0 of the BEA                 recommendation has been      
to include the 30 key elements                addressed or that it intends 
governing the "To Be"                         to implement this            
architectural content that our                recommendation.              
report identified as not being                
fully satisfied.                              

(4) The Secretary of Defense or his      X DOD officials have provided no  
appropriate designee                       evidence that this              
update version 1.0 to ensure that "To      recommendation has been         
Be" architecture                           addressed or that it            
artifacts are internally consistent, to    intends to implement this       
include addressing                         recommendation.                 
the inconsistencies described in this      
report, as well as                         
including user instructions or guidance    
for easier                                 
architecture navigation and use.           
(5) The Secretary of Defense or his        DOD officials provided a draft  
appropriate designee                     X plan that shows the             
update version 1.0 of the architecture     department's intent to develop  
to include (a) the 3                       a detailed action plan          
key elements governing the transition      to guide the development of the 
plan content that                          transition plan;                
our report identified as not being         however, the draft plan does    
fully satisfied and (b)                    not provide time frames         
those system investments that will not     for doing so. According to      
become part of the                         program officials, the          
"To Be" architecture, including time       department will issue a revised 
frames for phasing out                     transition plan in              
those systems.                             September 2005; but, this       
                                              version will not fully          
address our recommendation. (6) The Secretary of Defense or his
appropriate designee X According to program officials, of the 299
outstanding                             
update version 1.0 of the architecture     comments, 137 have been         
to address                                 addressed in Release 2.3        
comments made by the verification and      and earlier releases, 100 were  
validation                                 not applicable, and the         
contractor.                                remaining 62 will be addressed  
                                              in future releases.             
                                              These officials did not provide 
                                              any documentation               
                                              supporting their rationale for  
                                              the 100 that they               
                                              considered not applicable nor   
                                              did they provide plans          
                                              for addressing the 62 remaining 
                                              comments. The                   
                                              verification and validation     
                                              contractor stated that of the   
                                              137 comments that program       
                                              officials stated had been       
                                              addressed, 35 had been          
                                              addressed, 22 were not          
                                              applicable because they were    
                                              either duplicate or no          
                                              longer relevant based on        
                                              updates to prior releases, 22   
                                              had yet to be addressed, and 58 
                                              were not assessed.              
                                              The contractor has yet to       
                                              provide its assessment on       
                                              the 100 comments that DOD said  
                                              were not applicable.            
(7) The Secretary of Defense or his        As discussed in this report,    
appropriate designee                     X DOD has not developed           
develop a well-defined, near-term plan     explicit detailed plans to      
for extending and                          guide day-to-day program        
evolving the architecture and ensure       activities and to enable it to  
that this plan                             evaluate its progress.          
includes addressing our                    According to program officials, 
recommendations, defining roles            the department will             
and responsibilities of all                develop a program baseline by   
stakeholders involved in                   September 30, 2005.             
extending and evolving the                 
architecture, explaining                   
dependencies among planned activities,     
and defining                               
measures of activity progress.             

Source: GAO.

aOn May 20, 2003, the Under Secretary of Defense (Comptroller) issued a
memorandum that renamed and updated the Financial Management Modernization
Program to the Business Management Modernization Program. In addition, the
Financial Management Enterprise Architecture was renamed the Business
Enterprise Architecture.

Appendix II Status of Prior Recommendations on DOD's Development and
Maintenance of Its Business Enterprise Architecture

bDOD 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.

Appendix III

Summary of Several Architecture Frameworks

There are various enterprise architecture frameworks that an organization
can 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.1 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 February 1998, DOD directed its components to use its
C4ISR Architecture Framework, Version 2.0. In August 2003, the department
released Version 1.0 of the DOD Architecture Framework (DODAF)2-an
evolution of the C4ISR Architecture Framework, which supersedes the C4ISR.
The DODAF defines the type and content of the architectural artifacts, as
well as the relationships among the artifacts that are needed to produce a
useful architecture. Briefly, the framework decomposes an architecture
into three primary views: operational,

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

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

Appendix III Summary of Several Architecture Frameworks

systems, and technical standards.3 See figure 3 for an illustration of
these three views. 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 3: Interdependent DODAF Views of an Architecture

Source: DOD Architecture Framework Version 1.0, Volume 1.

In September 1999, the federal 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,

3There 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.

Page 57 GAO-05-702 DOD Business Enterprise Architecture Appendix III
Summary of Several Architecture Frameworks

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.

More recently, 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 information technology (IT)
          investments across the federal government. Version 2.0 of this
          model was released in June 2003.
     o 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.
     o 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

Appendix III Summary of Several Architecture Frameworks

how they support business and/or performance objectives. Version 1.0 of
this model was released in June 2003.

     o 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.
     o 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.
     o 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.

Appendix IV

Description of DOD Architecture Framework Products, Version 1.0

            Page 60 GAO-05-702 DOD Business Enterprise Architecture

Product           Product title       Product description                  
All view (AV)                         
                                         Executive-level summary information  
AV-1 Overview and Summary Information on the scope, purpose, and context   
                                         of the                               
                                         architecture                         
                                         Architecture data repository with    
AV-2 Integrated Dictionary            definitions of all terms used in all 
                                         products                             
Operational view (OV)                 
          High-Level Operational Concept High-level graphical/textual         
OV-1                          Graphic description of what the architecture 
                                         is supposed to                       
                                         do, and how it is supposed to do it  
                                         Graphic depiction of the operational 
OV-2  Operational Node Connectivity   nodes (or organizations) with        
                                         needlines that                       
         Description                     indicate a need to exchange          
                                         information                          
OV-3          Operational Information Information exchanged between nodes  
                         Exchange Matrix and the relevant attributes of that  
                                         exchange                             
OV-4  Organizational Relationships    Command structure or relationships   
         Chart                           among human roles, organizations, or 
                                         organization types that are the key  
                                         players in an architecture           
                                         Operations that are normally         
OV-5  Operational Activity Model      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        
OV-6a      Operational Rules Model    describe operational                 
                                         activity-identifies business         
                                         rules that constrain operations      
              Operational State          One of three products used to        
OV-6b      Transition Description     describe operational                 
                                         activity-identifies business         
                                         process responses to events          
             Operational Event-Trace     One of three products used to        
OV-6c     Description                 describe operational activity-traces 
                                         actions in a                         
                                         scenario or sequence of events       
                                         Documentation of the system data     
OV-7      Logical Data Model          requirements and structural business 
                                         process                              
                                         rules of the operational view        
Systems view (SV)                     
SV-1  Systems Interface Description   Identification of systems nodes,     
                                         systems, and systems items and their 
                                         interconnections, within and between 
                                         nodes                                
         Systems Communications          Specific communications links or     
SV-2  Description                     communications networks and the      
                                         details of                           
                                         their configurations through which   
                                         systems interface                    
                                         Relationships among systems in a     
SV-3  Systems-Systems Matrix          given architecture; can be designed  
                                         to show                              
                                         relationships of interest (e.g.,     
                                         system-type interfaces, planned      
                                         versus existing                      
                                         interfaces)                          
         Systems Functionality           System functional hierarchies and    
SV-4  Description                     system functions, and the system     
                                         data flow                            
                                         between them                         
         Operational Activity to Systems Mapping of relationships between the 
SV-5                         Function set of operational activities and    
                                         the set of                           
         Traceability Matrix             system functions applicable to that  
                                         architecture                         
SV-6  Systems Data Exchange Matrix    Characteristics of the system data   
                                         exchanged between systems            
          Systems Performance Parameters Quantitative characteristics of      
SV-7                           Matrix systems and systems                  
                                         hardware/software items,             
                                         their interfaces, and their          
                                         functions                            

Appendix IV Description of DOD Architecture Framework Products, Version
1.0

(Continued From Previous Page)
Product      Product title          Product description                    
                Systems Evolution      Planned incremental steps toward       
SV-8         Description            migrating a suite of systems to a more 
                                       efficient                              
                                       suite, or toward evolving a current    
                                       system to a future implementation      
                                       Emerging technologies and              
SV-9    Systems Technology Forecast 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                       
SV-10a  Systems Rules Model         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       
SV-10b  Systems State Transition    One of three products used to describe 
           Description                 system functionality-identifies        
                                       responses of a system to events        
SV-10c Systems Event-Trace          One of three products used to describe 
          Description                  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              
SV-11 Physical Schema               Physical implementation of the Logical 
                                       Data Model entities (e.g., message     
                                       formats, file structures, and physical 
                                       schema)                                
Technical standards view (TV)       
                                       Listing of standards that apply to     
TV-1 Technical Standards Profile    systems view elements in a given       
                                       architecture                           
                                       Description of emerging standards and  
TV-2 Technical Standards Forecast   the potential impact on current        
                                       systems                                
                                       view elements, within a set of time    
                                       frames                                 

                                  Source: DOD.

                                   Appendix V

                    Comments from the Department of Defense

Appendix V Comments from the Department of Defense

Appendix VI

                     GAO Contact and Staff Acknowledgments

Randolph C. Hite, (202) 512-3439 or [email protected]

  GAO Contact

In addition to the contact named above, Cynthia Jackson, Assistant

  Acknowledgments

Director; Barbara Collier; Joanne Fiorino; Neelaxi Lakhmani; Anh Le; Freda
Paintsil; Randolph Tekeley; and William Wadsworth made key contributions
to this report.

  GAO's Mission

The Government Accountability Office, the audit, evaluation and
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.

The fastest and easiest way to obtain copies of GAO documents at no cost
is through GAO's Web site ( www.gao.gov) . Each weekday, GAO posts GAO
Reports and newly released reports, testimony, and correspondence on its
Web site. To

have GAO e-mail you a list of newly posted products every afternoon, go to
www.gao.gov and select "Subscribe to Updates."

                             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, Contact:

Web site: www.gao.gov/fraudnet/fraudnet.htm

  E-mail: [email protected]

Federal Programs Automated answering system: (800) 424-5454 or (202)
512-7470

Gloria Jarmon, Managing Director, [email protected] (202) 512-4400 U.S.
Government Accountability Office, 441 G Street NW, Room 7125 Relations
Washington, D.C. 20548

Paul Anderson, Managing Director, [email protected] (202) 512-4800

  Public Affairs

U.S. Government Accountability Office, 441 G Street NW, Room 7149
Washington, D.C. 20548

    PRINTED ON

RECYCLED PAPER
*** End of document. ***