Executive Summary ES- 1 Integrated Architectures Panel

EXECUTIVE SUMMARY

The Framework has been developed in close coordination with the ongoing work of the Inte-grated Architectures Panel of the C4ISR Integration Task Force (ITF). The Framework will be provided to the C4ISR ITF as part of the Integrated Architectures Panel's Final Report and will be proposed to the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence as formal direction to DoD. The Framework is expected to be promulgated as direction via appropriate DoD policy directives and guidance instructions.

OBJECTIVE AND SCOPE The objective of the Framework task is to define a common approach for the military Services, unified commands, and Defense agencies to follow in developing their various C4ISR architec-tures. As defined in this report, the Framework provides guidelines and defines a process that can be used across DoD for developing C4ISR architectures with a focus on support to the warfighter. Although developed as a means for describing C4ISR operational, systems, and technical architectures to support warfighting tasks, the Framework can be readily extended to applicability to other architectures within the DoD such as for personnel, accounting, acquisi-tion, etc.

The primary existing DoD guidance specifically focused on architectures is the Technical Ar-chitecture Framework for Information Management (TAFIM), developed by the Defense Infor-mation Systems Agency (DISA). The TAFIM focuses on technical architectures and establishes a framework for Standards Based Architecture (SBA) planning and information technology standards. The Framework defined in this report primarily focuses on operational and systems architectures and is intended to be complementary to the TAFIM.

CURRENT ARCHITECTURE ENVIRONMENT There is currently no commonly used approach for architecture development and use within the DoD. The commanders in chief (CINCs), the military Services, and the DoD agencies (C/ S/ As) are increasingly developing and using architectures to support a variety of objectives, such as visualizing and defining operational and technical concepts, identifying operational require-ments, assessing areas for process improvement, guiding systems development and implemen- 8

8 Page 9 10 Integrated Architectures Panel ES- 2 Executive Summary

There are excellent initiatives, such as Air Force Horizon, Army Enterprise, and Navy Copernicus... Forward, but generally they are not connected. At the DoD- level, there are vari-ous architecture forums, such as the Architecture Methodology Working Group, the Architec-ture and Integration Council, and the Intelligence Systems Board, but they are not readily coupled.

The TAFIM's SBA Methodology describes a process to develop and achieve an integrated in-formation technology architecture that some DoD organizations have chosen to use. Likewise, several of the Services, and some of the commands and agencies have established processes for developing, presenting, and managing architectures. The processes vary according to the orga-nization, and some are more mature than others. This multitrack approach to the command, control, communications, computers, and intelligence (C4I) architectural world often yields stovepiped, inconsistent C4I architectures. The community is unable to fully leverage across various C/ S/ A architectures to develop a seamless, integrated C4ISR environment.

RESULTS OF RECENT DoD ARCHITECTURE INITIATIVES In October 1995, the Deputy Secretary of Defense directed that a DoD- wide effort be under-taken to define and develop better means and processes for ensuring that C4I capabilities meet the needs of warfighters. To accomplish this goal, the C4ISR ITF, under the direction of the ASD (C3I), was established. This task force, consisting of representatives from the Joint Chiefs of Staff, the military Services, and DoD agencies, was organized into various panels, each charged with tackling a different aspect of the problem.

The Integrated Architectures Panel has focused on the processes for DoD to develop coherent integrated C4ISR architectures. Prior to the establishment of this ITF, differing views of archi-tecture persisted in the DoD community at large. These differing views included functional, operational, information, physical, systems, and technical. The four Services had already de-cided to focus on an architecture construct consisting of operational, systems, and technical architectures. Early in the Panel's deliberation, this construct was accepted as the set of archi-tectures required in the DoD. Through efforts of the Panel, consensus regarding the nature and roles of operational, system, and technical architectures has emerged.

The Integrated Architectures Panel has recognized the need for a common approach for devel-oping and presenting architectures. The processes defined by the C/ S/ As provide a substantial foundation that can be used as a springboard to a coordinated DoD approach.

In support of the C4ISR ITF Integrated Architectures Panel, the C4I Integration Support Activ-ity (CISA) undertook the task of leading an effort to develop a C4ISR Architecture Framework that establishes a standardized set of rules and guidance for the Services, commands, and DoD agencies to use in their development and documentation of C4ISR architectures. This Frame- 9

9 Page 10 11 Executive Summary ES- 3 Integrated Architectures Panel

Once adopted, the Framework will provide a common basis for developing architectures that can be universally understood and readily compared and contrasted to other architectures. It will facilitate the reuse of architectural information and results and will serve as the foundation for expansion and integration of architectures across organizational and functional boundaries. In addition, the C4ISR Architecture Framework will promote effective communications be-tween warfighters and system developers by providing a context within which operational analysis and systems engineering can be integrated to provide logical connectivity from strategic objec-tives down to processes and supporting system elements. Ultimate potentials include facilitat-ing the creation of a joint, integrated C4ISR environment, facilitating development of common solutions for similar needs across C/ S/ As, and improving compatibility, interoperability, and integration among C4ISR capabilities.

Development of the Framework has been an evolutionary process, paralleling and keeping pace with the deliberations and conclusions of the Integrated Architectures Panel and its subpanels. Consequently, the Framework as presented here represents a snapshot in time of the current thinking and will evolve and be refined as it is put into practice.

ARCHITECTURE DEFINITIONS AND LINKAGES The Integrated Architectures Panel has agreed to the following definitions:

Architecture. The structure of components, their relationships, and the principles and guide-lines governing their design and evolution over time. (IEEE STD 610.12)

Operational Architecture. Descriptions of the tasks, operational elements, and informa-tion flows required to accomplish or support a warfighting function

Systems Architecture. Descriptions, including graphics, of systems and interconnections providing for or supporting warfighting functions

Technical Architecture. A minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements

These definitions clarify the distinctions among the types of architectures, emphasizing the precept that operational architectures present the functional or logical requirements for C4ISR support to the warfighter, while system and technical architectures describe the physical capa-bilities and attributes that actually meet operational needs. Expanded definitions of the three architecture types are provided in Section 3. 10

10 Page 11 12 Integrated Architectures Panel ES- 4 Executive Summary

THE FRAMEWORK FOR C4ISR ARCHITECTURES The architecture definitions and linkages agreed to by the Integrated Architectures Panel are the foundation of the Framework. In addition, the Framework is intended to be consistent with the objectives, concepts, and methodologies contained in the TAFIM.

The Framework provides a base methodology for developing architectures. It is not intended to be a rigid "cookie- cutter" approach to architecture development. It does not mandate specific techniques or automated tools. Instead, the guidelines are intended to allow sufficient flexibil-ity so that they do not restrict organizations in achieving their own analysis needs.

The Framework calls for consistent summary information, essential data and specific products according to architecture type. The summary information, applicable to all architectures, con-sists of a clear identification of the type of architecture, its scope, the purpose and intended users, the context for which the architecture is designed, and, if applicable, any findings derived from the architecture. For each architecture type, a minimum set of data is defined that must be present to satisfy the definition of that architecture type and to provide the appropriate basis for generating products.

Architecture Products As used here, "architecture products" are graphical, textual, and tabular items that are devel-oped in the course of building an architecture and describe characteristics pertinent to the archi-tecture and its purpose. The set of architecture products varies depending upon the type of

Figure ES- 1: Linkages Among Architecture Types Processing and Information Exchange Requirements Time- phased Technical Guidance

Processing and Information Exchange Requirements New Technological Capabilities

Systems

Operational Identifies Standards and Conventions Technical

Overlays Capabilities and Requirements to Identified Standards 96- 0254C- 02 Identifies Warfighter Needs 11

11 Page 12 13 Executive Summary ES- 5 Integrated Architectures Panel

The following are proposed standard architecture products. Each is addressed in the main body of this report with a discussion of the characteristics the product should capture; a description of how the product can be used or why it is needed; a generic, graphic template, where appro-priate; and a real- world example product.

Operational Architecture