DOD Business Systems Modernization: Military Departments Need to Strengthen Management of Enterprise Architecture Programs
Published: 2008-05-12T00:00:00

Fast Facts:

Highlights:
section_title: Why GAO Did This Study
paragraphs: In 1995, GAO designated Department of Defense (DOD) business systems modernization as a high-risk program, and the program remains on the high-risk list today. A key to successful systems modernization is having and using an enterprise architecture as an authoritative frame of reference, or blueprint, for system investment decisions. To assist DOD in modernizing its business systems, Congress passed legislation consistent with prior GAO recommendations for DOD to develop and implement a business enterprise architecture (BEA). In response, DOD developed a corporate BEA that it intends to federate, or extend, to the military departments and defense agencies. To support GAO's legislative mandate to review DOD's BEA, GAO evaluated the status of the Air Force, Navy, and Army architecture programs. To accomplish this, GAO used its Enterprise Architecture Management Maturity Framework and associated evaluation method.
section_title: What GAO Found
paragraphs: The enterprise architecture programs within the Departments of the Air Force, Navy, and Army have yet to advance to a level that can be considered fully mature. Specifically, all three departments are at the initial stage of GAO's architecture maturity framework. This means that they have not fully satisfied all the core elements associated with the framework's second stage (establishing the management foundation for developing, maintaining, and using the architecture) or any of the framework's higher stages: Stage 3 (developing the architecture), Stage 4 (completing the architecture), and Stage 5 (leveraging the architecture for organizational change). An organization generally needs to have achieved the fifth stage in the framework for it to have an effective architecture program because, at this stage, the management controls and structures are in place for using an approved architecture to guide and constrain system investments in a way that produces institutional results. Although each department is at Stage 1, the status of the programs vary considerably. Specifically, the Air Force far exceeds both the Navy and the Army, while the Navy generally exceeds the Army, in terms of the total percentage of core elements that are fully satisfied. Moreover, of the core elements that have not been fully satisfied by at least one of the three departments, most relate to architecture content, use, and measurement. Even though none of the departments have fully satisfied sufficient core elements to advance beyond Stage 1, the Air Force has at least partially satisfied all the core elements associated with Stages 2 and 3, as well as all but three core elements across all stages, and the Navy has at least partially satisfied all the core elements for Stage 2. In addition, the Air Force has made important progress in the last 2 years in maturing its architecture program, while the Navy's progress has been mixed, and the Army has not made any progress. Collectively, this means that DOD, as a whole, is not as well positioned as it should be to realize the significant benefits that a well-managed federation of architectures can afford its business systems modernization efforts. Individually, it means that the Air Force has a solid architectural foundation on which to continue building, while the Navy and, even more so, the Army has much to accomplish. According to Air Force officials, its progress owes largely to the architecture-related focus, commitment, and leadership of senior department executives, including the Secretary.

section_title: Letter
paragraphs: For decades, the Department of Defense (DOD) has been challenged in  modernizing its thousands of business systems. In 1995, we first  designated DOD’s business systems modernization program as high risk,  and we continue to designate it as such today. As our research on public  and private sector organizations shows, one key ingredient to a successful  systems modernization program is having and using a well-defined  enterprise architecture. Accordingly, we made recommendations to the  Secretary of Defense in 2001 that included the means for effectively  developing and implementing an enterprise architecture. Between 2001  and 2005, we reported on challenges that the department faced in its  efforts to develop a business enterprise architecture (BEA) and made  additional recommendations.
To require DOD to address these and other modernization management  challenges, Congress included provisions in the Ronald W. Reagan  National Defense Authorization Act for Fiscal Year 2005 that were  consistent with our recommendations. In response, DOD adopted an  incremental, federated approach to developing its BEA. We subsequently  reported that this approach was consistent with best practices and that the  initial version of the architecture provided a foundation on which to build  and align the department’s BEA with subsidiary architectures (i.e., military  department and defense agency component- and individual program-level  architectures).
In light of the critical role that military department architectures play in  DOD’s federated BEA construct, you asked us to assess the status of the  Departments of the Army, Navy, and Air Force enterprise architecture  programs. To accomplish this, we used a standard data and document  collection instrument to obtain key information about each department’s  architecture governance, content, use, and measurement. On the basis of  the military departments’ responses and supporting documentation, we  analyzed the extent to which each satisfied the 31 core elements in our  architecture maturity framework. We also compared the current status of  each military department’s program against the status that we reported in  2006. We performed our work in the metropolitan area of Washington,  D.C., from September 2007 through March 2008 in accordance with  generally accepted government auditing standards. Those standards  require that we plan and perform the audit to obtain sufficient, appropriate  evidence to provide a reasonable basis for our findings and conclusions  based on our audit objectives. Details on our objectives, scope, and  methodology are provided in appendix I.
subsections: section_title: Background
paragraphs: DOD is a massive and complex organization. To illustrate, the department  reported that its fiscal year 2007 operations involved approximately $1.5  trillion in assets and $2.1 trillion in liabilities, more than 2.9 million  military and civilian personnel, and $544 billion in net cost of operations.
In support of its military operations, the department performs an  assortment of interrelated and interdependent business functions—using  thousands of business systems—related to major business areas such as  weapon systems management, supply chain management, procurement,  health care management, and financial management. The ability of these  systems to operate as intended affects the lives of our warfighters both on  and off the battlefield. As we have previously reported, the DOD systems  environment that supports these business functions is overly complex;  error-prone; and characterized by little standardization across the  department, multiple systems performing the same tasks, the same data  stored in multiple systems, and the need for data to be entered manually  into multiple systems. Moreover, DOD recently reported that this systems  environment is comprised of approximately 3,000 separate business  systems.
For fiscal year 2007, Congress appropriated approximately $15.7 billion to  DOD; for fiscal year 2008, DOD has requested about $15.9 billion in  appropriated funds to operate, maintain, and modernize these business  systems and the associated infrastructures, of which approximately $11  billion was requested for the military departments.
DOD’s pervasive business system and related financial management  deficiencies adversely affect its ability to assess resource requirements;  control costs; ensure basic accountability; anticipate future costs and  claims on the budget; measure performance; maintain funds control;  prevent and detect fraud, waste, and abuse; and address pressing  management issues. In fact, DOD currently bears responsibility, in whole  or in part, for 15 of the 27 federal government’s program areas that we  have designated as high risk. Eight of these areas are specific to DOD and  the department shares responsibility for 7 other governmentwide high-risk  areas. DOD’s business systems modernization is one of the high-risk  areas, and it is an essential component for addressing many of the  department’s other high-risk areas. For example, modernized business  systems are integral to the department’s efforts to address its financial,  supply chain, and information security management high-risk areas. A  well-defined and effectively implemented enterprise architecture is, in  turn, integral to the successful modernization of DOD’s business systems.
subsections: section_title: Enterprise Architecture Is Critical to Achieving Successful Systems Modernization
paragraphs: An enterprise architecture (EA) is a blueprint that describes an  organization’s or a functional area’s current and desired state in both  logical and technical terms, as well as a plan for transitioning between the  two states. As such, it is a recognized tenet of organizational  transformation and IT management in public and private organizations.  Without an EA, it is unlikely that an organization will be able to transform  business processes and modernize supporting systems to minimize overlap  and maximize interoperability. For more than a decade, we have  conducted work to improve agency architecture efforts. To this end, we  developed the Enterprise Architecture Management Maturity Framework  (EAMMF) that provides federal agencies with a common benchmarking  tool for assessing the management of their EA efforts and developing  improvement plans.
subsections: section_title: Enterprise Architecture Description and Importance
paragraphs: An enterprise can be viewed as either a single organization or a functional  area that transcends more than one organization (e.g., financial  management or homeland security). An architecture can be viewed as the  structure (or structural description) of any activity. Thus, EAs are  systematically derived and captured descriptions depicted in models,  diagrams, and narratives.
More specifically, an architecture describes the enterprise in logical terms  (such as interrelated business processes and business rules, information  needs and flows, and work locations and users) as well as in technical  terms (such as hardware, software, data, communications, security  attributes, and performance standards). It provides these perspectives  both for the enterprise’s current, or “as-is,” environment, and for its target,  or “to-be,” environment, and it provides a transition plan for moving from  the “as-is” to the “to-be” environment.
The importance of EAs is a basic tenet of both organizational  transformation and IT management, and their effective use is a recognized  hallmark of successful public and private organizations. For over a  decade, we have promoted the use of architectures, recognizing them as a  crucial means to a challenging end: optimized agency operations and  performance. The alternative, as our work has shown, is the perpetuation  of the kinds of operational environments that saddle many agencies today,  in which the lack of integration among business operations and the IT  resources that support them leads to systems that are duplicative, not well  integrated, and unnecessarily costly to maintain and interface. Employed  in concert with other important IT management controls (such as  portfolio-based capital planning and investment control practices),  architectures can greatly increase the chances that organizations’  operational and IT environments will be configured to optimize mission  performance.
The concept of EAs originated in the mid-1980s; various frameworks for  defining the content of these architectures have been published by  government agencies and the Office of Management and Budget (OMB).  Moreover, legislation and federal guidance requires agencies to develop  and use architectures. (See appendix III for a brief description of  architecture frameworks and related legislation and management  guidance.)
section_title: GAO’s Enterprise Architecture Management Maturity Framework
paragraphs: In 2002, we developed version 1.0 of the EAMMF to provide federal  agencies with a common benchmarking tool for planning and measuring  their efforts to improve enterprise architecture management, as well as to  provide OMB with a means for doing the same governmentwide. We issued  an update of the framework (version 1.1) in 2003. This framework is an  extension of A Practical Guide to Federal Enterprise Architecture,  Version 1.0, published by the Chief Information Officers Council. Version  1.1 of the framework arranges 31 core elements (practices or conditions  that are needed for effective enterprise architecture management) into a  matrix of five hierarchical maturity stages and four critical success  attributes that apply to each stage. Within a given stage, each critical  success attribute includes between one and four core elements. Based on  the implicit dependencies among the core elements, the EAMMF  associates each element with one of five maturity stages (see fig. 1). The  core elements can be further categorized by four groups: architecture  governance, content, use, and measurement.
Stage 1: Creating enterprise architecture awareness. At Stage 1,  either an organization does not have plans to develop and use an  architecture, or it has plans that do not demonstrate an awareness of the  value of having and using an architecture. While Stage 1 agencies may  have initiated some enterprise architecture activity, these agencies’ efforts  are ad hoc and unstructured, lack institutional leadership and direction,  and do not provide the management foundation necessary for successful  enterprise architecture development as defined in Stage 2.
Stage 2: Building the enterprise architecture management  foundation. An organization at Stage 2 recognizes that the EA is a  corporate asset by vesting accountability for it in an executive body that  represents the entire enterprise. At this stage, an organization assigns  architecture management roles and responsibilities and establishes plans  for developing architecture products and for measuring program progress  and product quality; it also commits the resources necessary for  developing an architecture—people, processes, and tools. Specifically, a  Stage 2 organization has designated a chief architect and established and  staffed a program office responsible for EA development and  maintenance. Further, it has established a committee or group that has  responsibility for governance (i.e., directing, overseeing, and approving  architecture development and maintenance). This committee or group  membership has enterprisewide representation. At Stage 2, the  organization either has plans for developing or has started developing at  least some architecture products, and it has developed an enterprisewide  awareness of the value of enterprise architecture and its intended use in  managing its IT investments. The organization has also selected a  framework and a methodology that will be the basis for developing the  architecture products and has selected a tool for automating these  activities.
Stage 3: Developing the enterprise architecture. An organization at  Stage 3 focuses on developing architecture products according to the  selected framework, methodology, tool, and established management  plans. Roles and responsibilities assigned in the previous stage are in  place, and resources are being applied to develop actual products. At this  stage, the scope of the architecture has been defined to encompass the  entire enterprise, whether organization-based or function-based. Although  the products may not be complete, they are intended to describe the  organization in terms of business, performance, information/data,  service/application, and technology (including security explicitly in each),  as provided for in the framework, methodology, tool, and management  plans. Further, the products are to describe the current (“as-is”) and  future (“to-be”) states and the plan for transitioning from the current to the  future state (the sequencing plan). As the products are developed and  evolve, they are subject to configuration management. Further, through  the established enterprise architecture management foundation, the  organization is tracking and measuring its progress against plans,  identifying and addressing variances, as appropriate, and then reporting on  its progress.
Stage 4: Completing the enterprise architecture. An organization at  Stage 4 has completed its architecture products, meaning that the  products have been approved by the EA steering committee (established  in Stage 2) or an investment review board and by the Chief Information  Officer (CIO). The completed products collectively describe the enterprise  in terms of business, performance, information/data, service/application,  and technology for both its current and future operating states; the  products also include a plan for transitioning from the current to the  future state. Further, an independent agent has assessed the quality (i.e.,  completeness and accuracy) of the architecture products. Additionally,  evolution of the approved products is governed by a written EA  maintenance policy approved by the head of the organization.
Stage 5: Leveraging the enterprise architecture to manage  change. An organization at Stage 5 has secured senior leadership  approval of the architecture products and a written institutional policy  stating that IT investments must comply with the architecture, unless  granted an explicit compliance waiver. Further, decision makers are using  the architecture to identify and address ongoing and proposed IT  investments that are conflicting, overlapping, not strategically linked, or  redundant. As a result, Stage 5 entities avoid unwarranted overlap across  investments and ensure maximum systems interoperability. Maximum  interoperability, in turn, ensures the selection and funding of IT  investments with manageable risks and returns. Also, at Stage 5, the  organization tracks and measures EA benefits or return on investment,  and adjustments are continuously made to both the architecture  management process and the enterprise architecture products.
Attribute 1: Demonstrates commitment. Because the EA is a  corporate asset for systematically managing institutional change, the  support and sponsorship of the head of the enterprise are essential to the  success of the architecture effort. An approved enterprise policy statement  provides such support and sponsorship by promoting institutional buy-in  and encouraging resource commitment from participating components.  Equally important in demonstrating commitment is vesting ownership of  the architecture in an executive body that collectively owns the enterprise.
Attribute 2: Provides capability to meet commitment. The success  of the EA effort depends largely on the organization’s capacity to develop,  maintain, and implement the enterprise architecture. Consistent with any  large IT project, these capabilities include providing adequate resources  (i.e., people, processes, and technology), defining clear roles and  responsibilities, and defining and implementing organizational structures  and process management controls that promote accountability and  effective project execution.
Attribute 3: Demonstrates satisfaction of commitment. Satisfaction  of the organization’s commitment to develop, maintain, and implement an  EA is demonstrated by the production of artifacts (e.g., the plans and  products). Such artifacts demonstrate follow through—actual EA  production. Satisfaction of commitment is further demonstrated by senior  leadership approval of enterprise architecture documents and artifacts;  such approval communicates institutional endorsement and ownership of  the architecture and the change that it is intended to drive.
Attribute 4: Verifies satisfaction of commitment. This attribute  focuses on measuring and disclosing the extent to which efforts to  develop, maintain, and implement the EA have fulfilled stated goals or  commitments of the enterprise architecture. Measuring such performance  allows for tracking progress that has been made toward stated goals,  allows appropriate actions to be taken when performance deviates  significantly from goals, and creates incentives to influence both  institutional and individual behaviors. Figure 1 illustrates the EAMMF’s  maturity stages, attributes, and core elements.
The framework’s 31 core elements can also be placed in one of four  groups of architecture-related activities, processes, products, events and  structures. The groups are architecture governance, content, use, and  measurement. Each is defined below.
Governance refers to core elements that provide the management  structures and processes needed to guide and direct the architecture  program.
Content refers to core elements that provide for the scope, depth,  integrity, understanding, and consistency of products and artifacts that  make up the architecture.
Use refers to core elements that provide for an architecture-centric  approach to IT investment management (i.e., treating architecture as the  authoritative frame of reference in guiding and constraining IT  investments).
Measurement refers to core elements that provide for determining and  disclosing progress in developing, maintaining, and using the architecture,  including measurement against plans, process standards, and product  quality standards.
These groups are generally consistent with the capability area descriptions in  the OMB EA assessment tool. For example, OMB’s completion capability  area addresses ensuring that architecture products describe the agency in  terms of processes, services, data, technology, and performance and that the  agency has developed a transition strategy. Similarly, our content group  includes developing and completing these same EA products. In addition,  OMB’s results capability area addresses performance measurement, as does  our measurement group, and OMB’s use capability area addresses many of  the same elements in our governance and use groups. Table 1 lists the core  elements according to EAMMF group.
section_title: DOD’s Efforts to Adopt a Federated Approach to Architecting All of Its Mission Areas
paragraphs: DOD is pursing a federated strategy to develop and implement the many  and varied architectures across the department’s four mission areas— Warfighting, Business, DOD Intelligence, and Enterprise Information  Environment. According to officials in the Office of the Assistant  Secretary of Defense (Networks and Information Integration)/Chief  Information Officer (ASD(NII)/CIO), they have issued a strategy for  evolving DOD’s Global Information Grid (GIG) architecture that is to  provide a comprehensive architectural description of the entire DOD  enterprise, including all mission areas and the relationships between and  among all levels of the enterprise (e.g., mission areas, components, and  programs). Figure 2 provides a simplified, conceptual depiction of DOD’s  EA federation strategy.
ASD(NII)/CIO officials stated that the goal of this strategy is to improve  the ability of DOD’s mission areas, components, and programs to share  architectural information. In this regard, officials stated that the DOD EA  federation strategy will define federation and integration concepts,  alignment (i.e., linking and mapping) processes, and shared services.
The first Business Mission Area (BMA) federation strategy was released in  September 2006, according to ASD(NII)/CIO officials. Its purpose is to  expand on the DOD EA federation strategy and provide details on how  various aspects of the federation will be applied within the department’s  BMA. In this regard, the BMA strategy cites the following four goals:    establish a capability to search for data in member architectures that may  be relevant for analysis, reference, or reuse;   develop a consistent set of standards for architecture configuration  management that will enable users to determine the development status  and quality of data in various architectures;   establish a standard methodology for specifying linkages among existing  component architectures that were developed using different tools and  that are maintained in independent repositories; and    develop a standard methodology to reuse capabilities described by various  architectures.
To assist in accomplishing these goals, the strategy described three  concepts that are to be applied:  1.  Tiered accountability provides for architecture development at each  of the department’s organizational levels.  2.  Net-centricity provides for seamless and timely accessibility to  information where and when needed via the department’s  interconnected network environment.  3.  Federating DOD architectures provides for linking or aligning  subordinate and parent architectures via the mapping of common  architectural information. This concept advocates subordinate  architecture alignment to the parent architecture.
subsections: section_title: DOD Roles and Responsibilities for Business Enterprise Architecture Development and Use
paragraphs: In 2005, DOD reassigned responsibility for directing, overseeing, and  executing its business transformation and systems modernization efforts  to the Defense Business Systems Management Committee (DBSMC) and  the Business Transformation Agency. The DBSMC is chaired by the  Deputy Secretary of Defense and serves as the highest-ranking governance  body for business systems modernization activities. According to its  charter, the DBSMC provides strategic direction and plans for the BMA in  coordination with the Warfighting and the Enterprise Information  Environment Mission Areas. The DBSMC is also responsible for reviewing  and approving the BEA and the Enterprise Transition Plan.
The Business Transformation Agency operates under the authority,  direction, and control of the DBSMC and reports to the Under Secretary of  Defense for Acquisition, Technology, and Logistics in the incumbent’s  capacity as the vice chair of the DBSMC. Oversight for this agency is  provided by the Deputy Under Secretary of Defense for Business  Transformation, and day-to-day management is provided by the director.  The Business Transformation Agency’s primary responsibility is to lead  and coordinate business transformation efforts across the department. In  particular, it is responsible for (1) maintaining and updating the  department’s architecture, (2) ensuring that functional priorities and  requirements of various defense component organizations are reflected in  the architecture, and (3) ensuring the adoption of DOD-wide information  and process standards as defined in the architecture.
Under DOD’s tiered accountability approach to systems modernization,  components are responsible for defining their respective component  architectures and transition plans. Similarly, program managers are  responsible for developing program-level architectures and transition  plans and ensuring integration with the architectures and transition plans  developed and executed at the enterprise and component levels.
section_title: Summary of GAO’s Prior Reviews on Business Enterprise Architecture and Military Department Architectures
paragraphs: Between May 2001 and July 2005, we reported on DOD’s efforts to develop  an architecture and identified serious problems and concerns with the  department’s architecture program, including the lack of specific plans  outlining how DOD would extend and evolve the architecture to include  the missing scope and detail. To address these concerns, in September  2003, we recommended that DOD develop a well-defined, near-term plan  for extending and evolving the architecture and ensure that this plan  would address our recommendations: defining roles and responsibilities of  all stakeholders involved in extending and evolving the architecture,  explaining dependencies among planned activities, and defining measures  of progress for the activities.
In response to our recommendations, in 2005, DOD adopted a 6-month  incremental approach to developing its architecture and released version  3.0 of the BEA and the associated transition plan in September 2005,  describing them as the initial baselines. Since then, DOD has released  three updated versions of both—version 3.1, released on March 15, 2006;  version 4.0, released on September 28, 2006; and version 4.1, released on  March 15, 2007. As we have previously reported, these incremental  versions have provided additional content and clarity and resolved  limitations that we identified in the prior versions. For example, version  4.1 improved the Financial Visibility business enterprise priority area by  including the Standard Financial Information Structure data elements and  business rules to support cost accounting and reporting. In addition,  version 4.1 addressed, to varying degrees, missing elements,  inconsistencies, and usability issues that we previously identified.
In August 2006, we reported that the Departments of the Air Force, Navy,  and Army had fully satisfied about 45, 32, and 3 percent, and partially  satisfied 26, 39, and 42 percent, respectively, of the 31 core elements in our  architecture maturity framework (see table 2).
By comparison, other major federal departments and agencies that we  reviewed had, as a whole, fully satisfied about 67 percent of the  framework’s core elements. Among the key elements that all three military  departments had not fully satisfied were developing architecture products  that describe their respective target architectural environments and  developing transition plans for migrating to a target environment.  Furthermore, while the military departments had partially satisfied  between 26 and 42 percent of the core elements in our framework, we  reported that partially satisfied elements were not necessarily easy to  satisfy fully, such as those that address architecture content; and thus,  partials can have serious implications for the quality and usability of an  architecture. To assist the military departments in addressing their EA  challenges and managing their programs, we recommended that they  develop and implement plans for fully satisfying each of the conditions in  our framework. DOD generally agreed with our findings and  recommendations.
In April 2007, we reported that DOD’s BMA federation strategy provided a  foundation on which to build and align DOD’s parent BEA with its  subordinate architectures (i.e., component- and program-level  architectures). In particular, we found that this strategy (1) stated the  department’s federated architecture goals; (2) described federation  concepts that are to be applied; and (3) included high-level activities,  capabilities, products, and services that are intended to facilitate  implementation of the concepts. However, we also reported that DOD had  yet to define the details needed to execute the strategy, such as how the  architecture federation was to be governed; how alignment with the DOD  federation strategy and other potential mission-area federation strategies  was to be achieved; how component architectures’ alignment with  incremental versions of the BEA was to be achieved; how shared services  would be identified, exposed, and subscribed to; and what milestones  would be used to measure progress and results. As a result, we concluded  that much remained to be decided and accomplished before DOD would  have in place the means to create a federated architecture and thus be able  to fully satisfy both our prior recommendations and legislative  requirements aimed at adopting an architecture-centric approach to  departmentwide business systems investment management.
In May 2007, we concluded that while DOD has made progress in  developing the BEA, much remained to be accomplished. In particular, we  reported that DOD had yet to extend and evolve its corporate BEA  through the development of aligned, subordinate architectures for each of  its component organizations, and while it had developed a strategy for  federating the BEA in this manner, this strategy lacked the detail needed  for it to be fully effective. We also reported that this situation was  compounded by the known immaturity of the military departments’  architecture efforts. Accordingly, we recommended that DOD include in  its annual report to Congress on compliance with section 332 of the Fiscal  Year 2005 National Defense Authorization Act the results of assessments  by its BEA independent verification and validation contractor on the  completeness, consistency, understandability, and usability of its  federated family of business mission architectures, including the  associated transition plans. DOD agreed with this recommendation.
section_title: Maturity of Military Department Enterprise Architecture Programs Continues to Vary
paragraphs: Each of the military departments’ enterprise architecture programs is at  the initial stage of our maturity framework, meaning that each has not  fully satisfied all of the core elements associated with the framework’s  second stage (establishing the management foundation for developing,  maintaining, and using the architecture). Also, none have fully satisfied the  core elements associated with Stage 3 (developing the architecture), 4  (completing the architecture), and 5 (leveraging the architecture for  organizational change). As a result, none have yet to advance to a state  that can be considered fully mature and effective. Although all  departments are at Stage 1, the status of the three vary considerably.  Specifically, the Air Force far exceeds the Navy, which generally exceeds  the Army, in terms of the total number of core elements that are fully  satisfied. Further, even though all three are at Stage 1, the Air Force has at  least partially satisfied all of the core elements associated with Stage 3 and  has partially satisfied all but three core elements across all stages. The  Navy has at least partially satisfied all of the core elements associated with  Stage 2 and all but one of the Stage 3 core elements. Moreover, the Air  Force has made important progress in maturing its EA program over the  last 2 years, while the Navy has made mixed progress, and the Army has  not made progress.
As our research shows, the state of an organization’s EA program owes  largely to the extent to which the program has benefited from sustained  executive leadership. This is because virtually all of the barriers to  effectively developing and using architectures, such as parochialism,  cultural resistance, adequate resources, and top management  understanding, can be addressed through such leadership. In this regard,  Air Force officials attributed their progress toward establishing a fully  mature architecture program to sustained executive leadership. Without  fully mature programs, the departments introduce increased risk of  developing and implementing IT solutions that are duplicative, do not  interoperate, and thus do not optimize departmentwide performance.
subsections: section_title: The Military Departments’ Full Satisfaction of Our Framework’s Core Elements Varies, but None Have Programs That Are Fully Mature
paragraphs: To reach a given stage of maturity under our architecture framework and  associated evaluation methodology, a military department had to fully  satisfy all of the core elements at that stage. Using this criterion, each of  the military departments is at Stage 1, meaning that none could  demonstrate through verifiable documentation that it has established all of  the core foundational commitments and capabilities needed to effectively  manage the development, maintenance, and implementation of an  architecture. However, this does not mean that the departments are at  identical states of maturity. Rather, the Air Force is considerably more  advanced than the Navy and Army. (See appendices IV through VI for  details on the extent to which each military department satisfied each of  the core elements of our maturity framework.)
Assigning the military departments’ architecture programs to a maturity  stage based on whether all elements of a stage are fully satisfied provides  only one perspective on these programs. Another is the extent to which  each program has also fully satisfied core elements across higher stages of  maturity. When the percentage of core elements that have been fully  satisfied across all stages is considered, a similar picture of the  departments’ relative variability is evident. Specifically, the percent of all  core elements that are fully satisfied ranges from a high of 61 percent for  the Air Force to a low of 3 percent for the Army (the Navy fully satisfied   13 percent of the core elements). Table 3 summarizes the percentage of  core elements that are fully satisfied in total, by maturity stage, for each  military department.
Notwithstanding this perspective, it is important to note that the staging of  core elements in our framework provide a hierarchical or systematic  progression to establishing a mature and effective architecture program.  That is, core elements associated with lower framework stages generally  support the effective execution of higher maturity stage core elements.  For instance, if a program has developed its full suite of “as-is” and “to-be”  architecture products, including a sequencing plan (Stage 4 core  elements), but the products are not under configuration management  (Stage 3 core element), then the integrity and consistency of the products  cannot be adequately assured. In this regard, even though the Navy has  partially developed its EA products, the quality of these products is  questionable because the Navy has not placed them under configuration  management.
Further, not satisfying even a single lower stage core element can have a  significant impact on the effectiveness of an architecture program. For  example, not using a defined framework or methodology (Stage 2 core  element) or not performing configuration management (Stage 3 core  element), can significantly limit the quality and utility of an architecture.  DOD’s experience between 2001 and 2005 in developing its BEA is a case  in point. During this time, we made a series of recommendations grounded  in, among other things, our architecture management framework to ensure  that it was successful in doing so. In 2005, we reported that despite  investing hundreds of millions of dollars and 4 years in developing  multiple versions of wide-ranging architecture products, the department  did not have a well-defined architecture, and what it did develop had  limited utility. Among other things, we attributed the poor state of its  architecture products to methodological, human capital, and configuration  management weaknesses.
Looking at related groupings of core elements that are fully satisfied also  provides a useful perspective on the state of the military departments’  architecture programs. As noted earlier, these groupings of core elements  are architecture governance, content, use, and measurement. Overall, the  military departments varied in the extent to which each of the groups were  met. For example, while the Air Force fully satisfied 71 percent of the  governance core elements, the Navy and Army only fully satisfied 14 and 7  percent, respectively. The extent to which each department satisfied the  core elements in each grouping are discussed below. (See table 4 for a  summary of the extent to which each department fully satisfied these  groupings.)
Governance refers to core elements that provide the management  structures and processes needed to guide and direct an architecture  program. Neither the Navy nor the Army has established effective  architecture governance, having satisfied only 14 and 7 percent of these  core elements, respectively. For example, neither has a written or  approved departmentwide policy for EA development and maintenance or  for requiring that IT investments comply with the EA. This is important  because approved policies demonstrate institutional commitment to  having and using an architecture. As our framework states, an approved  enterprisewide policy provides the kind of top management support and  sponsorship needed to overcome the barriers to architecture development  and use. In contrast, the Air Force has fully satisfied the majority of  governance core elements. However, the remaining unsatisfied core  elements are significant. For example, it has not fully established a  committee or group with representation from across the enterprise to  direct, oversee, and approve the architecture. This is significant because  the architecture is a corporate asset that needs to be enterprisewide in  scope and accepted by senior leadership if it is to be leveraged effectively  for organizational change.
Content refers to core elements that provide for the scope, depth,  integrity, understanding, and consistency of products and artifacts that  make up the architecture. Only the Air Force has fully satisfied much in  the way of architecture content, having fully met 60 percent of the core  elements, with the Navy and Army meeting only 10 and 0 percent,  respectively. For example, while the Air Force has placed its EA products  under configuration management and provided for ensuring that its EA  products will describe the “as-is” environment, “to-be” environment, and  sequencing plan, neither the Navy nor the Army has done the same.  Moreover, none of the departments have fully addressed security as part of  their respective “as-is” and “to-be” products developed to date. This is  important because security is relevant and essential to every aspect of an  organization’s operations, and therefore, the nature and substance of  institutionalized security requirements, controls, and standards should be  embedded throughout the architecture. Further, none of the departments  is using an independent verification and validation agent to help ensure  the quality of these products. As we have previously reported, independent  verification and validation is a proven means for obtaining unbiased  insight into such essential architecture qualities as completeness,  understandability, and consistency.
Use refers to core elements that provide for an architecture-centric  approach to IT investment management (i.e., treating architecture as the  authoritative frame of reference for guiding and constraining IT  investments). Again, the Air Force has fully satisfied 50 percent of this  grouping’s core elements, while the Navy and the Army have fully satisfied  none of the core elements. For example, the Air Force has made its EA an  integral component of its IT investment process by requiring that  investments demonstrate their architectural compliance. This is important  because in order for the benefits of an EA to be realized, IT investments  must comply with it. However, neither the Air Force nor the other two  departments could demonstrate that their respective IT investments are  actually in compliance with their respective architectures. This is relevant  because the benefits from using an EA, such as improved information  sharing, increased consolidation, enhanced productivity, and lower costs,  cannot be fully realized unless individual investments are actually in  compliance with, for example, architectural rules and standards.
Measurement refers to core elements that provide for determining and  disclosing progress in developing, maintaining, and using the EA, including  measurement against plans, process standards, and product quality. None  of the departments satisfied many of these core elements. Specifically, the  Air Force fully satisfied 40 percent and the Navy fully satisfied 20 percent  of these core elements, while the Army did not satisfy any. For example,  while the Air Force has plans that call for the development of metrics to  measure EA progress, quality, compliance, and return on investment, and  the Navy is measuring and reporting on progress against plans, none of the  departments is measuring and reporting on IT investment compliance with  its architecture or return on investment from its architecture program.  Without measuring architecture development, maintenance, and use, an  organization is not positioned to take timely corrective action to address  deviations from plans, expectations, and outcomes, which in turn limits  the chances of EA program success.
section_title: The Military Departments’ Partial Satisfaction of Framework’s Core Elements Also Varies, and Provides a Basis from Which to Build
paragraphs: In instances where the military departments have not fully satisfied certain  core elements in our framework, two have at least partially satisfied  many of these elements. To illustrate, the Air Force would improve to  Stage 3 if the criterion for being at a given stage was relaxed to only  partially satisfying a core element. Moreover, the Navy would advance to  Stage 2 under this less demanding criterion. In contrast, the Army would  remain at Stage 1.
Partial satisfaction of a core element is an indicator of some progress and  provides a basis on which to improve. Nevertheless, it also indicates that  more work is needed, for example, to establish architectural commitments  and capabilities and to demonstrate and verify that both exist and are  functioning as intended. Moreover, even though a core element can be  partially satisfied, what remains to fully satisfy it can be significant and  can require considerable time and resources. Thus, it is important to note  that even though the departments have partially satisfied some core  elements, fully satisfying some of them may remain a challenge. It is also  important to note that fully, rather than partially, satisfying certain  elements, such as those that fall within the architecture content group, are  key to the success of an EA. Not fully satisfying these elements can have  important implications for the quality of an architecture, and thus its  usability and results. The extent to which each of the departments partially  satisfied the core elements at each stage of our framework is discussed  below and summarized in table 5.
Metis ArchitectTM is an architecture tool from Troux Technologies, Inc.
EA, these metrics do not address measuring progress against plans. As our  framework states, progress in developing EA products should be  measured against EA plans so that deviations from expectations can be  examined for cause and impact and appropriate actions can be taken to  address them.
The Navy has at least partially satisfied 93 percent of the elements  associated with Stages 2 and 3 and has in place many aspects of the core  elements that support these stages, which it can use to continue  establishing an effective architecture management foundation and  associated plans and products. However, important aspects of certain core  elements are missing. For example, similar to the Air Force, the Navy is  developing its EA using a framework (the DOD Architecture Framework)  and automated tools (Telelogic System Architect® and Metis  ArchitectTM). Also, similar to the Air Force, the Navy does not have a  documented methodology governing how its architecture is being  developed and maintained. In addition, the Navy has yet to establish a  committee or group representing the enterprise that is responsible for  directing, overseeing, or approving the architecture. Establishing such a  governance entity is important because it demonstrates the organization’s  commitment to building and using an architecture and helps to obtain  necessary buy-in from across the organization. Further, while the Navy has  drafted an EA policy, the policy has not yet been approved. Approval is  important because it demonstrates senior leadership commitment to the  architecture and clearly assigns responsibility and accountability for  development and maintenance of the architecture.
The Army has at least partially satisfied 27 percent of the elements  associated with Stages 2 and 3, but has not made progress toward  establishing the commitments and capabilities that comprise the core  elements integral to an effective architecture management foundation and  associated plans and products. In particular, while the Army has an EA  program office, the office does not have an approved charter. A program  charter is important because it defines key aspects about how the office  will operate in order to achieve program goals and outcomes. Further,  while the Army is using an automated tool (System Architect) to capture  architecture products, it is not using a framework or methodology. This is  significant because the framework provides a defined structure and  nomenclature for representing architecture information across the  organization and the methodology describes a common set of procedures  to be used for developing products in a coherent way. Together, they help  to ensure that activities associated with capturing the architecture are  understood by those involved and are completed in a consistent,  accountable, and repeatable manner.
section_title: The Military Departments Varied in the Extent to Which Their Architecture Programs Have Recently Improved
paragraphs: We reported in August 2006 that each of the military departments was at  the initial stage of our architecture maturity framework. More  specifically, we reported that the Air Force, Navy, and Army had fully  satisfied 45, 32, and 3 percent, and that they had partially satisfied 26, 39,  and 42 percent, of the 31 core elements, respectively. Accordingly, we  made recommendations for each department to fully implement the  framework’s core elements.
Since then, the departments have addressed our recommendations to  varying degrees. Specifically, the Air Force has made the most progress,  increasing the percentage of fully satisfied core elements from 45 to 61  percent and increasing the percentage of partially satisfied core elements  from 26 to 29 percent. The Navy has made mixed progress, decreasing the  percentage of fully satisfied core elements from 32 to13 percent and  increasing the percentage of partially satisfied core elements from 39 to 52  percent. The Army has not made progress, keeping the percentage of fully  satisfied core elements at 3 percent while decreasing the percentage of  partially satisfied core elements from 42 to 13 percent. The specific  progress made by each department is discussed below and summarized in  table 6.
The Air Force’s 16 percent increase in the core elements that are fully  satisfied relate to five core elements. For example, we previously reported  that the Air Force’s architecture program plans did not call for developing  metrics to measure EA progress, quality, compliance, and return on  investment. Since then, the Air Force has expanded its plans to include  such metrics. The addition of these metrics is important because they  provide the basis for knowing whether program expectations are being  met, which could prompt timely corrective action to address any  significant deviations. Also, while the Air Force did not previously have its  architecture products under configuration management, it has since done  so. This progress is important because it helps to integrate and align the  products and to track and manage changes to them in a way that ensures  product integrity. Finally, the Air Force has also established the  architecture as an integral component of its IT investment management  process by explicitly requiring that its IT investments align with the EA.  This was not the case in 2006 and represents a significant improvement  because without requiring alignment, investments are more likely to  deviate from the architecture in ways that increase duplication of effort  and decrease interoperability.
The Air Force’s 3 percent increase in the core elements that are partially  satisfied relate to three core elements. For example, we reported in 2006  that the Air Force’s EA products did not address security. Since then, the  Air Force has developed an Information Assurance Domain Architecture  to augment its EA products. To the Air Force’s credit, this document  addresses important aspects of security relative to its technical reference  models. However, it does not similarly address security in relation to the  EA’s business, systems, and information models. For example, the  business models do not address the goals and strategies for addressing  current security risks and future security threats. In addition, while the Air  Force now has a sequencing plan, this plan is not complete because it does  not include, and is not grounded in, an analysis of the gap in capabilities  between the department’s “as-is” and “to-be” architectural environments.  Such a gap analysis is necessary to determine what capabilities are  currently lacking and which capabilities will need to be acquired or  developed in a sequence that is based on a variety of factors.
According to Air Force officials, the positive progress that it has made in  maturing its architecture program is due, in large part, to the focus,  commitment, and leadership of senior department executives, including  the Secretary of the Air Force. In this regard, they said that their  experiences and lessons learned show that such leadership paved the way  for establishing the department’s institutional commitment to its EA. Such  commitment, they said, is demonstrated by the Air Force’s approved EA  policies and funding, and its capabilities to meet commitments, such as the  department’s structures and processes for governing architecture  development and implementation.
The Navy’s 19 percent decrease in the core elements that are fully satisfied  relate to six core elements, and according to Navy officials, are largely due  to the Navy’s recent efforts to expand the scope of its architecture  program beyond that which existed in 2006. More specifically, in 2006, the  Navy’s architecture program was focused on what it refers to as  FORCEnet, which is the Navy’s IT infrastructure architecture. During the  course of our review, the Navy reported that it has adopted DOD’s  federated architecture approach, thereby expanding its program to include  all Navy organizations and all architecture reference models (e.g.,  business, data, performance). However, it has yet to reflect this expansion  in program scope in key governance documents, such as its EA policies  and plans, that relate to these six core elements. Without fully satisfying  these governance core elements, the department will be challenged in its  ability to develop and implement a Navy-wide federated architecture.
The 13 percent increase in the core elements that are partially satisfied are  largely associated with three content-related core elements. For example,  we reported in 2006 that the Navy’s FORCEnet products did not include  descriptions of the “to-be” architecture in terms of, for example, business,  information/data, applications/service, and performance. Under the Navy’s  expanded scope, it has since developed “to-be” architecture products  (DOD Architecture Framework views) that address these areas. However,  these products are not yet sufficiently complete. To illustrate, the  functional areas (e.g., human resources) in the business or operational  views have not been decomposed into functional activities (e.g.,  recruiting) and processes (e.g., interviewing), and the information  exchanges between functional areas in the operational views are not  defined. Moreover, there are no data models to identify and describe  relationships among the data elements within each functional area.
According to Navy officials, the shift to a broader, federated approach to  developing and implementing a Navy enterprise architecture was recently  endorsed by secretariat-level leadership and senior department executives.
The Army continues to fully satisfy one core element (having a chief architect).  However, it has also experienced a 29 percent decrease in those core elements  that it had partially satisfied in 2006 (nine core elements), most of which relate  to such governance topics as EA policies and plans. Specifically, the plans and  policies that the Army had in 2006 were not approved. Because they were not  approved, they did not fully satisfy the various associated core elements. Since  then, the Army official principally responsible for the program told us that the  department’s senior executives, including the Army Vice-Chief of Staff, have  endorsed a new architecture approach in which the Army will use OMB’s  reference models (e.g., business, performance, information/data). To this end,  the officials said that decisions are to be made in the near future about how to  best structure the program to implement this approach, including what the  program’s scope will be and what resources will be needed to sustain it. This  official added that once these decisions are made, as part of the Army’s budget  submission and approval process, the EA policies and plans will be updated to  reflect these decisions.
section_title: Conclusions
paragraphs: If managed effectively, enterprise architectures can be a useful change  management and organizational transformation tool. The conditions for  effectively managing enterprise architecture programs are contained in our five  stage architecture maturity framework. None of the military departments has  fully satisfied all of the conditions needed to achieve Stage 2 or above in the  framework, which means that none have programs that we would currently  consider effective and mature. However, the Navy has partially satisfied most,  and the Air Force has partially satisfied all, of the core elements needed to be at  Stage 3. In addition, among the three military departments, the Air Force has  satisfied the most core elements across all framework stages. Moreover, the Air  Force has demonstrated the most progress in the last 2 years in satisfying the  framework’s core elements. However, the military departments have not yet  met the conditions for the effective governance, content, use and measurement  of their respective architecture programs. The Air Force has a solid foundation  on which to continue building, but the Navy and, even more so, the Army has  much to accomplish before either will have effective and mature architecture  programs. As a result, DOD, as a whole, is not as well positioned as it should be  to realize the significant benefits that a well-managed federation of architecture  programs can provide.
As we have previously reported, the key to having a mature architecture  program, and thereby realizing the benefits of an architecture-centric  approach to IT investment decision making, is sustained executive  leadership. This is because virtually all of the barriers to effectively  developing and using architectures, such as parochialism, cultural  resistance, adequate resources, and top management understanding, can  be addressed through such leadership. For the military departments to  advance their respective architecture programs, sustained executive  leadership will be needed. In this regard, the Navy and the Army could  benefit from the lessons learned and experiences to date of the Air Force’s  efforts to mature its architecture program.
section_title: Recommendation for Executive Action
paragraphs: Because we have outstanding recommendations to the Secretary of  Defense aimed at, among other things, having the Departments of the Air  Force, Navy, and Army fully satisfy each of the core elements in our  architecture framework, we are not making additional recommendations  relative to our framework at this time. However, given the uneven status  and progress of the respective military departments, we reiterate our  outstanding recommendations and further recommend that the Secretary  of Defense direct the Secretaries of the Navy and Army to ensure that their  respective departments reach out to the Department of the Air Force to  learn from and apply the lessons and experiences that have allowed the  Air Force to make the progress it has in maturing its architecture program.
section_title: Agency Comments
paragraphs: In written comments on a draft of this report, signed by the Deputy Under  Secretary of Defense (Business Transformation) and reprinted in appendix  II, the department agreed with our recommendation, and described efforts  underway and planned to implement it.
We are sending copies of this report to interested congressional  committees; the Director, Office of Management and Budget; and the  Secretary of Defense. Copies of this report will be made available to other  interested parties on request. This report will also be available at no  charge on our Web site at http://www.gao.gov.
If you or your staffs have any questions on matters discussed in this  report, please contact me at (202) 512-3439 or hiter@gao.gov. Contact  points for our Offices of Congressional Relations and Public Affairs may  be found on the last page of this report. GAO staff who made major  contributions to this report are listed in appendix VII.
section_title: Appendix I: Objective, Scope, and Methodology
paragraphs: Our objective was to determine the current status of the military  departments’ enterprise architecture efforts. To do so, we used a data  collection instrument based on our Enterprise Architecture Management  Maturity Framework (EAMMF), and related guidance, such as the Office  of Management and Budget Circular A-130 and guidance published by the  federal Chief Information Officers (CIO) Council, as well as our past  reports and guidance on the management and content of enterprise  architectures. We also met with the chief architects of the military  departments to discuss our scope and methodology, share the data  collection instrument, and discuss the type and nature of supporting  documentation needed to verify responses to instrument questions.
On the basis of documentation provided to support the departments’  respective responses to our data collection instrument, we analyzed the  extent to which each department satisfied the 31 core elements in our  EAMMF. To guide our analyses, we used our standard evaluation criteria  for determining whether a given core element was fully satisfied, partially  satisfied, or not satisfied (See tables 7, 8, 9, and 10 for the core elements of  Stages 2, 3, 4, and 5, respectively.) To fully satisfy a core element,  sufficient documentation had to be provided to permit us to verify that all  aspects of the core element were met. To partially satisfy a core element,  sufficient documentation had to be provided to permit us to verify that at  least some aspects of the core element were met. Core elements that did  not meet criteria for fully or partially satisfied were judged to be not  satisfied.
In applying our methodology, we first analyzed and determined the extent  to which each department satisfied the core elements in our framework,  and then met with their representatives to discuss core elements that were  not satisfied and why. As part of this interaction, we sought, and in some  cases were provided, additional supporting documentation. We then  considered this documentation when determining the degree to which  each department satisfied each core element. In applying our evaluation  criteria, we analyzed the results across different core elements to  determine patterns and issues.
We conducted our work in the metropolitan area of Washington, D.C.,  from September 2007 through March 2008, in accordance with generally  accepted government auditing standards. Those standards require that we  plan and perform the audit to obtain sufficient, appropriate evidence to  provide a reasonable basis for our findings and conclusions based on our  audit objectives. We believe that the evidence obtained provides a  reasonable basis for our findings and conclusions based on our audit  objectives.
section_title: Appendix II: Comments from the Department of Defense
section_title: Appendix III: Brief History of Architecture Frameworks and Management Guidance
paragraphs: During the mid-1980s, John Zachman, widely recognized as a leader in the  field of enterprise architecture, identified the need to use a logical  construction blueprint (i.e., an architecture) for defining and controlling  the integration of systems and their components. Accordingly, Zachman  developed a structure, or framework, for defining and capturing an  architecture, which provides for six perspectives, or “windows,” from  which to view the enterprise. Zachman also proposed six abstractions, or  models, associated with each of these perspectives. Zachman’s  framework provides a way to identify and describe an entity’s existing and  planned component parts and the parts’ relationships before the entity  begins the costly and time-consuming efforts associated with developing  or transforming itself.
Since Zachman introduced his framework, a number of frameworks have  emerged within the federal government, beginning with the publication of  the National Institute of Standards and Technology framework in 1989.  Since that time, other federal entities have issued frameworks, including  the Department of Defense and the Department of the Treasury. In  September 1999, the federal Chief Information Officers Council published  the Federal Enterprise Architecture Framework, which was intended to  provide federal agencies with a common construct for their architectures,  thereby facilitating the coordination of common business processes,  technology insertion, information flows, and system investments among  federal agencies. The Federal Enterprise Architecture Framework  described an approach, including models and definitions, for developing  and documenting architecture descriptions for multiorganizational  functional segments of the federal government.
More recently, Office of Management and Budget (OMB) established the  Federal Enterprise Architecture Program Management Office to develop a  federal enterprise architecture according to a collection of five “reference  models” (see table 11). These models are intended to facilitate  governmentwide improvement through cross-agency analysis and the  identification of duplicative investments, gaps, and opportunities for  collaboration, interoperability, and integration within and across  government agencies.
Although these post-Zachman frameworks differ in their nomenclatures  and modeling approaches, each consistently provides for defining an  enterprise’s operations in both logical and technical terms, provides for  defining these perspectives for the enterprise’s current and target  environments, and calls for a transition plan between the two.
Legislation and federal guidance address enterprise architecture.  Specifically, the Clinger-Cohen Act of 1996 directs the CIOs of major  departments and agencies to develop, maintain, and facilitate the  implementation of information technology architectures as a means of  integrating agency goals and business processes with information  technology. Also, OMB Circular A-130, which implements the Clinger- Cohen Act, requires that agencies document and submit their initial  enterprise architectures and that agencies submit updates when significant  changes to their enterprise architectures occur. The circular also directs  OMB to use various reviews to evaluate the adequacy and efficiency of  each agency’s compliance with the circular.
Since then, OMB has developed and implemented an enterprise  architecture assessment tool. According to OMB, the tool helps to  illustrate the current state of an agency’s architecture and assists agencies  in integrating architectures into their decision-making processes. The  latest version of the assessment tool (2.0) was released in December 2005  and includes three capability areas: (1) completion, (2) use, and (3)  results. Table 12 describes each of these areas.
The tool also includes criteria for scoring an agency’s architecture  program on a scale of 0 to 5. In early 2006, the major departments and  agencies were required by OMB to provide a self-assessment of their  architecture programs using the tool. OMB then used the self assessment  to develop its own assessment. These assessment results are to be used in  determining the agency’s e-Government score within the President’s  Management Agenda.
section_title: Appendix IV: Department of the Air Force Assessment
paragraphs: Stage 2: Building the EA management foundation  Committee or group representing the enterprise is responsible for directing, overseeing, and approving EA.
Program office responsible for EA development and maintenance exists.
EA being developed using a framework, methodology, and automated tool.
EA plans call for describing “as-is” environment, “to-be” environment, and sequencing plan.
EA plans call for describing enterprise in terms of business, performance, information/data,  applications/service, and technology.
EA plans call for business, performance, information/data, applications/service, and technology to address  security.
EA plans call for developing metrics to measure EA progress, quality, compliance, and return on investment.
Stage 3: Developing architecture products  Written and approved policy exists for EA development.
EA products are under configuration management.
EA products describe or will describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described or will be described in terms given in Stage 2.
These descriptions address or will address security.
Progress against EA plans is measured and reported.
Stage 4: Completing architecture products  Written and approved policy exists for EA maintenance.
EA products and management processes undergo independent verification and validation.
EA products describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described in terms given in Stage 2.
Committee or group representing the enterprise or the investment review board has approved current   version of EA.
Quality of EA products is measured and reported.
Stage 5: Leveraging the architecture to manage change  Written and approved organization policy exists for IT investment compliance with EA.
Process exists to formally manage EA change.
EA is integral component of IT investment management process.
Organization head has approved current version of EA.
Return on EA investment is measured and reported.
Compliance with EA is measured and reported.
section_title: Appendix V: Department of the Navy Assessment
paragraphs: Stage 2: Building the EA management foundation  Committee or group representing the enterprise is responsible for directing, overseeing, and approving EA.  Partial  Program office responsible for EA development and maintenance exists.
EA being developed using a framework, methodology, and automated tool.
EA plans call for describing “as-is” environment, “to-be” environment, and sequencing plan.
EA plans call for describing enterprise in terms of business, performance, information/data,  applications/service, and technology.
EA plans call for business, performance, information/data, applications/service, and technology to  address security.
EA plans call for developing metrics to measure EA progress, quality, compliance, and return on  investment.
Stage 3: Developing architecture products  Written and approved policy exists for EA development.
EA products are under configuration management.
EA products describe or will describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described or will be described in terms given in Stage 2.
These descriptions address or will address security.
Progress against EA plans is measured and reported.
Stage 4: Completing architecture products  Written and approved policy exists for EA maintenance.
EA products and management processes undergo independent verification and validation.
EA products describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described in terms given in Stage 2.
Organization CIO has approved current version EA.
Committee or group representing the enterprise or the investment review board has approved current  version of EA.
Quality of EA products is measured and reported.
Stage 5: Leveraging the architecture to manage change  Written and approved organization policy exists for IT investment compliance with EA.
Process exists to formally manage EA change.
EA is integral component of IT investment management process.
Organization head has approved current version of EA.
Return on EA investment is measured and reported.
Compliance with EA is measured and reported.
section_title: Appendix VI: Department of the Army Assessment
paragraphs: Stage 2: Building the EA management foundation  Committee or group representing the enterprise is responsible for directing, overseeing, and approving EA.
Program office responsible for EA development and maintenance exists.
EA being developed using a framework, methodology, and automated tool.
EA plans call for describing “as-is” environment, “to-be” environment, and sequencing plan.
EA plans call for describing enterprise in terms of business, performance, information/data,  applications/service, and technology.
EA plans call for business, performance, information/data, applications/service, and technology to   address security.
EA plans call for developing metrics to measure EA progress, quality, compliance, and return on investment.   No  Stage 3: Developing architecture products  Written and approved policy exists for EA development.
EA products are under configuration management.
EA products describe or will describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described or will be described in terms given in Stage 2.
These descriptions address or will address security.
Progress against EA plans is measured and reported.
Stage 4: Completing architecture products  Written and approved policy exists for EA maintenance.
EA products and management processes undergo independent verification and validation.
EA products describe “as-is” environment, “to-be” environment, and sequencing plan.
Both “as-is” and “to-be” environments are described in terms given in Stage 2.
Organization CIO has approved current version of EA.
Committee or group representing the enterprise or the investment review board has approved current   version of EA.
Quality of EA products is measured and reported.
Stage 5: Leveraging the architecture to manage change  Written and approved organization policy exists for IT investment compliance with EA.
Process exists to formally manage EA change.
EA is integral component of IT investment management process.
Organization head has approved current version of EA.
Return on EA investment is measured and reported.
Compliance with EA is measured and reported.
section_title: Appendix VII: GAO Contact and Staff Acknowledgments
subsections: section_title: GAO Contact
section_title: Staff Acknowledgments
paragraphs: In addition to the contact named above, Tonia Johnson (Assistant  Director), Timothy Eagle, Elena Epps, Michael Holland, Neela Lakhmani,  Rebecca LaPaze, Anh Le, and Freda Paintsil made key contributions to this  report.