oversight

Information Technology: Observations on Department of Defense's Draft Enterprise Architecture

Published by the Government Accountability Office on 2003-03-28.

Below is a raw (and likely hideous) rendition of the original report. (PDF)

United States General Accounting Office
Washington, DC 20548



          March 28, 2003

          The Honorable John Ensign
          Chairman
          The Honorable Daniel K. Akaka
          Ranking Minority Member
          Subcommittee on Readiness and Management Support
          Committee on Armed Services
          United States Senate

          Subject:        Information Technology: Observations on Department of Defense’s Draft
                          Enterprise Architecture

          The fiscal year 2003 Defense Authorization Act1 requires the Department of Defense
          (DOD) to develop by May 1, 2003, a financial management enterprise architecture,
          including a transition plan, that meets certain requirements. The act also requires that
          we submit to congressional defense committees an assessment of the architecture
          and transition plan within 60 days of their approval. (See enclosure I for the
          requirements of this law.) As part of our ongoing work to satisfy this legislative
          requirement and at the request of your staff, we briefed your offices on March 4, 2003,
          on our preliminary assessment of the DOD draft architecture products dated
          February 7, 2003. As further requested by your staff, this letter transmits the
          observations we made during the briefing. (See enclosure II for a summary of our
          assessment approach.)

          An enterprise architecture provides a clear and comprehensive picture of an entity,
          whether it is an organization (e.g., federal department or agency) or a functional or
          mission area that cuts across more than one organization (e.g., financial management
          or homeland security). This picture consists of snapshots of both the enterprise’s
          current operational and technological environment and its target environment, as
          well as a capital investment road map for transitioning from the current to the target
          environment. These snapshots further consist of “views,” which are basically one or
          more architecture products that provide conceptual or logical representations of the
          enterprise.




          1
              Section 1004 of Public Law 107-314.


          Page 1                                             GAO-03-571R DOD’s Draft Architecture
Based on our preliminary assessment of DOD’s draft architecture products, we made
the following observations during our March 4, 2003, briefing to your staff. To DOD’s
credit, it is
•   following its Command, Control, Communications, Computers, Intelligence,
    Surveillance, and Reconnaissance Architecture framework and planning to
    develop most of the products called for by this framework;
•   using an automated tool to create and maintain the architecture products; and
•   following a defined process for identifying the federal regulatory and legal
    requirements associated with federal accounting standards and financial
    management and reporting requirements (e.g., Joint Financial Management
    Improvement Program and Title 10 U.S. Code—Armed Forces) for the seven
                           2
    business process areas within the “to be” architecture.

However, we also stated that the department had yet to provide a clear definition of
the intended purpose of the April 30, 2003, architecture, which, according to federal
guidance, is needed to establish the architecture’s scope and depth (i.e., the
boundaries and level of detail to be provided in the architecture). Further, according
to DOD officials’ statements and DOD’s architecture plans and schedules, the April
30, 2003, version of the architecture will not fully satisfy the requirements contained
within Section 1004 of Public Law 107-314. (See enclosure III for a summary of DOD’s
architecture development and implementation schedule.)

In addition, we stated that the draft architecture did not include a number of items
recommended by relevant architectural guidance,3 such as
•   the “as is” architecture environment, including descriptions of existing business
    operations and supporting technology;
•   a “to be” security architecture view, which defines the security requirements (e.g.,
    policies, procedures, and controls), including relevant standards to be applied in
    implementing these controls;
•   “to be” architecture descriptions for all key stakeholders (e.g., DOD top
    executives and the Congress), which are intended to provide each with sufficient
    understanding of the architecture to allow for meaningful input;
•   “to be” architecture organization and location views, which define the
    entities/people who will perform the functions, processes, and activities, and
    specify the locations where the functions, processes, and activities will be
    performed;

2
 The seven business process areas are (1) accounting; (2) collection, accounts receivable, and cash
management; (3) financial and management reporting; (4) human resource management; (5) logistics;
(6) procurement, payables, acquisition, and disbursing; and (7) strategic planning and budgeting.
3
 See, for example, Institute of Electrical and Electronics Engineers Standard 1471; Software
Engineering Institute Open Systems publications; Federal Enterprise Architecture Framework;
Zachman Framework; and Command, Control, Communications, Computers, Intelligence, Surveillance
and Reconnaissance Architecture framework.



Page 2                                                   GAO-03-571R DOD’s Draft Architecture
•      an explicit definition of architecture drivers and governing principles, which are
       the constraints and requirements that lead to major decisions about the “to be”
       architecture (e.g., the use of centralized versus distributed processing, and the
       standardization of business rules to minimize effect on implementation); and
•      defined structure and linkages among “to be” architecture views, such as the
       linkages among (1) applications and services, (2) organizations using the
       applications and services, and (3) applicable technical standards.4

Given that the draft architecture products are not intended to be complete, we also
noted that our assessment and observations were limited to the state of the draft
products as of February 7, 2003, and that because these products are still being
developed, later versions may include missing views and items.

In commenting on a draft of this letter, DOD Comptroller officials, including the
Director, Business Management Systems Integration Office, stated that they generally
agreed with our assessment of the February 7, 2003, draft architecture products. The
director also commented that the state of DOD’s “as is” architecture products is
appropriate at this point in time and that DOD accepts the risk of not investing
further in defining these products until development of the transition plan requires it
to do so. We agree that further development of the “as is” can coincide with the
development of the transition plan, but also note that not having defined “as is”
operations and technology at this juncture is risky because it defers too late in the
architecture development cycle a very important set of tasks.

The director also commented that the April 30, 2003, version of the architecture
would address all the requirements of the act, but that the degree to which they are
addressed would vary and that subsequent versions of the architecture would provide
missing details. We agree that the April 30, 2003, version of the architecture will likely
address, to some degree, the architecture requirements in the act. However, our
observation was that this version of the architecture would not fully satisfy the act’s
requirements. DOD’s comment is consistent with our observations.

We will be sending copies of this letter to interested congressional committees and
the Director, Office of Management and Budget. This letter will also be available at no
charge on our Web site at www.gao.gov.




4
    Technical standards provide the set of rules that govern system implementation and operation.


Page 3                                                       GAO-03-571R DOD’s Draft Architecture
If you have any questions concerning this information, please contact us at (202) 512-
3439 or (202) 512-9095, respectively. We can also be reached by E-mail at
hiter@gao.gov or kutzg@gao.gov. GAO contacts and key contributors to this letter are
listed in appendix IV.




Randolph C. Hite
Director, Information Technology Architecture
and Systems Issues




Gregory D. Kutz
Director, Financial Management and Assurance

Enclosures




Page 4                                           GAO-03-571R DOD’s Draft Architecture
Enclosure I


         SEC. 1004. [of Public Law 107-314] DEVELOPMENT AND
     IMPLEMENTATION OF FINANCIAL MANAGEMENT ENTERPRISE
                            ARCHITECTURE.

(a) REQUIREMENT FOR ENTERPRISE ARCHITECTURE AND FOR TRANSITION
PLAN—
Not later than May 1, 2003, the Secretary of Defense shall develop—
(1) a financial management enterprise architecture for all budgetary, accounting,
finance, enterprise resource planning, and mixed information systems of the
Department of Defense; and
(2) a transition plan for implementing that financial management enterprise
architecture.

(b) COMPOSITION OF ENTERPRISE ARCHITECTURE—
(1) The financial management enterprise architecture developed under
subsection (a)(1) shall describe an information infrastructure that, at a minimum,
would enable the Department of Defense to—
    (A) comply with all Federal accounting, financial management, and reporting
    requirements;
    (B) routinely produce timely, accurate, and reliable financial information for
    management purposes;
    (C) integrate budget, accounting, and program information and systems; and
    (D) provide for the systematic measurement of performance, including the ability
    to produce timely, relevant, and reliable cost information.
(2) That enterprise architecture shall also include policies, procedures, data
standards, and system interface requirements that are to apply uniformly throughout
the Department of Defense.

(c) COMPOSITION OF TRANSITION PLAN—The transition plan developed under
subsection (a)(2) shall include the following:
(1) The acquisition strategy for the enterprise architecture, including specific time-
phased milestones, performance metrics, and financial and nonfinancial resource
needs.
(2) A listing of the mission critical or mission essential operational and
developmental financial and nonfinancial management systems of the Department of
Defense, as defined by the Under Secretary of Defense (Comptroller), consistent with
budget justification documentation, together with--
    (A) the costs to operate and maintain each of those systems during fiscal year
    2002; and
    (B) the estimated cost to operate and maintain each of those systems during
    fiscal year 2003.
(3) A listing of the operational and developmental financial management systems of
the Department of Defense as of the date of the enactment of this Act (known as
‘legacy systems’) that will not be part of the objective financial and nonfinancial
management system, together with the schedule for terminating those legacy systems
that provides for reducing the use of those legacy systems in phases.



Page 5                                           GAO-03-571R DOD’s Draft Architecture
Enclosure I

(d) CONDITIONS FOR OBLIGATION OF SIGNIFICANT AMOUNTS FOR FINANCIAL
SYSTEM IMPROVEMENTS—An amount in excess of $1,000,000 may be obligated for
a defense financial system improvement only if the Under Secretary of Defense
(Comptroller) makes a determination regarding that improvement as follows:
(1) Before the date of an approval specified in paragraph (2), a determination that
the defense financial system improvement is necessary for either of the following
reasons:
    (A) To achieve a critical national security capability or address a critical
    requirement in an area such as safety or security.
    (B) To prevent a significant adverse effect (in terms of a technical matter, cost, or
    schedule) on a project that is needed to achieve an essential capability, taking into
    consideration in the determination the alternative solutions for preventing the
    adverse effect.
(2) On and after the date of any approval by the Secretary of Defense of a financial
management enterprise architecture and a transition plan that satisfy the
requirements of this section, a determination that the defense financial system
improvement is consistent with both the enterprise architecture and the transition
plan.

(e) CONGRESSIONAL REPORTS—Not later than March 15 of each year from 2004
through 2007, the Secretary of Defense shall submit to the congressional defense
committees a report on the progress of the Department of Defense in implementing
the enterprise architecture and transition plan required by this section. Each report
shall include, at a minimum—
(1) a description of the actions taken during the preceding fiscal year to implement
the enterprise architecture and transition plan (together with the estimated costs of
such actions);
(2) an explanation of any action planned in the enterprise architecture and transition
plan to be taken during the preceding fiscal year that was not taken during that fiscal
year;
(3) a description of the actions taken and planned to be taken during the current
fiscal year to implement the enterprise architecture and transition plan (together with
the estimated costs of such actions); and
(4) a description of the actions taken and planned to be taken during the next fiscal
year to implement the enterprise architecture and transition plan (together with the
estimated costs of such actions).

(f) COMPTROLLER GENERAL REVIEW—Not later than 60 days after the approval of
an enterprise architecture and transition plan in accordance with the requirements of
subsection (a), and not later than 60 days after the submission of an annual report
required by subsection (e), the Comptroller General shall submit to the congressional
defense committees an assessment of the extent to which the actions taken by the
Department comply with the requirements of this section.

(g) DEFINITIONS—In this section:
(1) The term ‘defense financial system improvement’ means the acquisition of a new
budgetary, accounting, finance, enterprise resource planning, or mixed information
system for the Department of Defense or a modification of an existing budgetary,


Page 6                                             GAO-03-571R DOD’s Draft Architecture
Enclosure I

accounting, finance, enterprise resource planning, or mixed information system of
the Department of Defense. Such term does not include routine maintenance and
operation of any such system.
(2) The term ‘mixed information system’ means an information system that supports
financial and non-financial functions of the Federal Government as defined in Office
of Management and Budget Circular A-127 (Financial management Systems).

(h) REPEAL—(1) Section 2222 of title 10, United States Code, is repealed. The table
of sections at the beginning of chapter 131 of such title is amended by striking the
item relating to such section.
(2) Section 185(d) of such title is amended by striking ‘has the meaning given that
term in section 2222(c)(2) of this title’ and inserting ‘means an automated or manual
system from which information is derived for a financial management system or an
accounting system’.




Page 7                                           GAO-03-571R DOD’s Draft Architecture
Enclosure II


                          Summary of Assessment Approach

As part of our ongoing work under Section 1004 of Public Law 107-314, we performed
a preliminary assessment of Department of Defense (DOD) draft enterprise
architecture products dated February 7, 2003. This assessment included analyzing
relevant criteria5 to identify the architecture views that are needed to provide key
stakeholders a complete understanding of the architecture and searching all the draft
products to determine whether these views existed. In searching the products, we
specifically focused on governing principles, standards, and security, because they
are fundamental elements of a well-defined and enforceable architecture. In addition,
we traced linkages between the different views to determine if these linkages had
been specifically identified to ensure ease of stakeholder navigation and
understanding. We also reviewed DOD’s schedule of deliverables and its October
2002 transition plan strategy to ascertain the department’s future plans for later
versions of the architecture.

To determine whether DOD had a defined process for identifying the federal
regulatory and legal requirements associated with federal accounting standards and
financial management and reporting (e.g., Joint Financial Management Improvement
Program and Title 10 U.S. Code—Armed Forces), we obtained and performed a
preliminary review of the traceability matrices prepared by the DOD program office
that documented these requirements for each of the seven business process areas
within the “to be” architecture. We also interviewed program officials to obtain an
understanding of the methodology being used to identify, track, validate, and update
the information contained within these matrices. We did not evaluate the
completeness or validity of the requirements developed as part of the draft
architecture. Also, we did not review the process related to investment management
as described in Section 1004 of Public Law 107-314. Additionally, because we
assessed draft architecture products as of February 7, 2003, our observations are
limited to the state of these products as of that date.

We performed our work from February 2003 through March 2003 in accordance with
generally accepted government auditing standards.




5
 See, for example, Institute of Electrical and Electronics Engineers Standard 1471, Software
Engineering Institute Open Systems publications, Federal Enterprise Architecture Framework,
Zachman Framework, and Command, Control, Communications, Computers, Intelligence, Surveillance
and Reconnaissance Architecture framework.




Page 8                                                GAO-03-571R DOD’s Draft Architecture
Enclosure III


                   Summary of Architecture Development and Implementation Schedule




Notes: GAO analysis based on DOD information.
OV is Operational View. OV is to depict the organization-wide business environment and activities that need to occur to achieve the “to be” state.
SV is Systems View. SV is to describe the set of system capabilities that are to provide DOD with accurate, reliable, and timely access to business
management and associated financial information.

TV is Technical View. TV is to contain the set of rules that govern system implementation and operation.
According to DOD, subsequent architecture versions (9/30/2003) will include (1) relevant standards (e.g., data) to guide projects and investments,
(2) life-cycle costs for systems, and (3) security in OV and SV products.




Page 9                                                                                             GAO-03-571R DOD’s Draft Architecture
Enclosure IV


                 GAO Contacts and Staff Acknowledgments

GAO Contacts        Cynthia Jackson, (202) 512-5086
                    Jenniffer Wilson, (202) 512-9192

Acknowledgments In addition to the individuals named above, key contributors to
                this letter included Nabajyoti Barkakati, Barbara Collier,
                Neelaxi Lakhmani, Anh Le, Evelyn Logue, Mai Nguyen, Stacey
                Smith, Al Steiner, Randolph Tekeley, and William Wadsworth.




(310253)



Page 10                                        GAO-03-571R DOD’s Draft Architecture