19 Page 20 21 Appendix C Integrated Architectures Panel

SECTION 3
OVERVIEW OF THE FRAMEWORK

3.1 ANALYTICAL BASIS OF THE FRAMEWORK The proposed Framework is based on the concept of operational, systems, and technical archi-tectural components that work in concert. Although initially developed as a means for describ-ing C4ISR operational, systems, and technical architectures to support warfighting tasks, the Framework that has been developed can be readily extended to other information architectures within the DoD such as for personnel management, systems acquisition, or finance.

3.1.1 Relationship to DoD Policy and Guidance Documents The primary existing guidance on architectures is the TAFIM; DoD Directive (DoDD) 5105.19, and Chairman of the Joint Chiefs of Staff (CJCS) Memorandum of Policy (MOP) 50 and its proposed replacement CJCS Instruction (CJCSI) 6111.11. The TAFIM focuses on technical architectures and establishes a framework for SBA planning and information technology stan-dards. DoDD 5105.19 tasks DISA with developing and maintaining architectures to ensure end- to- end interoperability of strategic and tactical C4 and information systems used by the National Command Authorities and DoD components. CJCS MOP 50/ Instruction 6111.11 establishes policy and guidance for the development and assessment of C4 architectures and planning documents. However, there is no DoD policy, directive, or other guidance for devel-oping and maintaining operational and systems architectures.

The proposed C4ISR Architecture Framework is consistent with the objectives, concepts, and methodologies contained in the TAFIM and provides the necessary extension of these concepts to the development of operational and systems architectures.

3.1.2 Architecture Definitions The architecture definitions agreed to by the Integrated Architecture Panel provide the founda-tion for the Framework.

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

3- 1 20

20 Page 21 22 Integrated Architectures Panel Appendix C

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.

3.1.3 Guiding Principles There were several guiding principles that drove the development of the Framework. These are that architectures should:

Be built with a purpose

Facilitate user understanding and communication among users

Permit comparison and integration

Be modular, expandable, and reusable First, development of architectures should be driven by a particular purpose, and that purpose must be clearly understood. Architectures may be developed to provide an understanding of the complex relationships among tasks, operational elements, information flows, and systems. Within C4ISR, the range of systems to be addressed extends from the sensor, through processing and information systems to the shooter, to include associated communications. Architectures may also be developed to address more focused objectives such as identifying process improvement opportunities, defining and evaluating particular capabilities such as communications capabili-ties, or examining actual versus required interoperability in a subject area. A clear identifica-tion of the purpose will provide the proper perspective for selecting the type of architecture to be built, the depth and breadth that it should cover, and the particular way its information should be portrayed. Since architectures may serve multiple purposes, the various purposes the archi-tecture may ultimately serve should be explored in advance of architecture development so the most efficient use may be made of the often time- consuming data- gathering steps that precede the actual development process.

To facilitate user understanding and communication among users, the ways of presenting archi-tecture information should be chosen with the background and perspective of the expected users in mind. Such methods may include graphics, tables, databases, and text. In addition, the level of detail presented must be tailored to the particular needs of the user and the purposes that the architecture may serve.

3- 2 21

21 Page 22 23 Appendix C Integrated Architectures Panel

The key prerequisite to both the comparison and integration of architectures and to modularity, expandability, and reusability is to build architectures using commonly understood terms and approaches. Definition of a set of essential architecture information, like plastic children's building blocks that come in standard sizes, shapes, and colors, will permit architectures to be built modularly, integrated with each other, expanded upon, and reused. As used here, "integratable" does not necessarily imply that one architecture should be able to "plug into" another or that multiple architectures be physically combined into one architecture document. In this context integration means to analyze multiple architectures to serve a common purpose to identify linkages, gaps, overlays, and redundancies. Even if built for different purposes, architectures built using similar terms and methods will facilitate comparison and make them easier to adapt for other uses.

There are several types or levels of integration: one is integration between hierarchical levels, such as between joint- level and Service- or lower organization- level architectures; another is integration between different architectures at the same hierarchical level; still another is inte-gration among Operational, Systems, and Technical Architecture Components within a single architecture. Figure 3- 1 illustrates these various types of integration. For example, a Navy

architecture on Mine Warfare could be related to a Joint Maritime architecture. An operational architecture for precision strike could be compared to one for integrated air defense to identify where the two may be able to take advantage of common information sources. Alternatively, a systems architecture for theater missile defense may be compared to one for theater air defense to determine if there are opportunities for sharing communications systems and processing

3- 3

96- 0254C- 04 22

22 Page 23 24 Integrated Architectures Panel Appendix C

algorithms. Within the same subject area, operational and systems architectures for mine war-fare may be compared and linked to each other to ensure that the right systems are in place to meet operational needs.

The end result will be broader understanding of architectures, reduction in the time and expense to build architectures, and ultimately the capability to develop overarching architectures that cut across multiple organizational and functional bounds.

3.1.4 Relationship to Military Doctrine The Framework uses existing military doctrine as the basis for defining the missions, tasks, and activities upon which architectures are based. However, the Framework also recognizes the fact that military doctrine is never static, that it is constantly evolving in response to changes in military strategy and opportunities to exploit advances in technology. This may be particularly true of the rapid revolution in technology associated with C4ISR capabilities.

3.2 OPERATIONAL, SYSTEMS, AND TECHNICAL ARCHITECTURES As a result of the deliberations of the Integrated Architecture Panel, there is now a better under-standing within the DoD of the nature and roles of operational, systems, and technical architec-tures.

The key distinctions among these architectures and the relationships among them are depicted in Figure 3- 2. As shown in this figure, operational architectures are used to identify and document warfighter C4ISR needs,

* systems architectures are used to describe how the needs can be met using identified standards and conventions, and technical architectures specify

* It should be noted that the formal establishment and validation of operational requirements is accomplished via the existing Mission Need Statement (MNS) and Operational Requirements Document (ORD) process.

3- 4

96- 0254C- 02 23

23 Page 24 25 Appendix C Integrated Architectures Panel

the standards to be used for meeting the needs. In addition, the operational architectures pro-vide the context for exploration and time- phased selection of new technologies, while the tech-nical architectures provide new technologies that can be exploited through new operational concepts.

The Operational Architecture, Systems Architecture, Technical Architecture and Integrated Subpanels of the Integrated Architecture Panel have expanded the basic definitions of architec-ture types and have defined basic tenets to which each architecture type adheres. The expanded definitions and tenets are provided in Figures 3- 3, 3- 4, and 3- 5.

3- 5

24 Page 25 26 Integrated Architectures Panel Appendix C

3- 6

25 Page 26 27 Appendix C Integrated Architectures Panel

Architectures are developed according to a defined scope and within a specific context. The scope includes the architecture type, subject area, and time frame for which the architecture is applicable. In general, the subject area for operational architectures is based upon mission areas such as Joint Maritime Operations, Mine Warfare, and Theater Air Defense. The interre-lated conditions that compose the setting in which the architecture exists constitute the context for the architecture. The context includes such things as doctrine; tactics, techniques, and procedures; relevant goals and vision statements; and concepts of operations, scenarios, and environmental conditions. High- level, broad scope architectures embrace the range of poten-tial physical, military, and civil environmental conditions so that the resulting architectures are highly stable and are relatively insensitive to moderate changes in environmental conditions. Specific environmental conditions are reflected in operational plans and may also be more directly reflected in lower level, issue- focused architectures.

3- 7

26 Page 27 28 Integrated Architectures Panel Appendix C

In the context of C4ISR architectures, system architectures are expected to address the full range of automated systems from sensors that collect information and pass it on, through pro-cessing and information systems, communications systems, and shooters that require automated information to accomplish their objectives. System architectures depict the functional and physi-cal automated systems, nodes, platforms, communications paths, and other critical elements that provide for supporting information exchange requirements and warfighter tasks described in the operational architectures. Various attributes of the systems, nodes, and required informa-tion exchanges are included according to the purpose of the specific architecture effort.

Tactical, strategic, and support systems must be able to "plug and play" in a joint, global envi-ronment. To achieve this ability, there must be a mechanism for incorporating information technology consistently, controlling the configuration of technical components, and ensuring compliance with technical "building codes." The technical architecture provides this mecha-nism.

Technical architectures are intended to transition the logical operational architecture to the physi-cal systems architecture by providing the fundamental building blocks on which to base devel-opment. Well- planned and comprehensive technical architectures facilitate integration and promote interoperability across systems and compatibility among related architectures. As part of a disciplined process to build systems, technical architectures reduce information technology costs across an organization by highlighting risks, identifying technical or programmatic is-sues, and driving technology reuse. Adherence to a technical architecture streamlines and ac-celerates systems definition, approval, and implementation.

3.3 DOCUMENTATION OF ARCHITECTURES Architectures should be developed via a common approach that includes providing summary information, a minimum set of essential architecture information, and specific architecture prod-ucts. The summary information, applicable to all architectures, consists of a clear identification of the type of architecture, its applicable time frame, and the purpose and intended users of the architecture. As used here, the term "architecture products" refers to graphical, textual, and tabular items that are developed in the course of building an architecture. Architecture products describe characteristics pertinent to the architecture and its intended purpose. The set of archi-tecture products used in a given architecture effort vary depending upon the type of architecture being developed, the scope, and the specific purpose and objectives of the architecture. The framework provides templates for development of these textual and graphic architectural prod-ucts using consistent terminology and display techniques to facilitate common understanding and to provide a basis for comparing, and integrating architectures when it is beneficial to do so.

3.3.1 Common Summary Information To facilitate understanding and provide opportunities for comparing and integrating architec-tures, all architecture documentation should include the information described below. This

3- 8 27

27 Page 28 29 Appendix C Integrated Architectures Panel

information should be provided as part of an executive summary or overview section at the beginning of the architecture documentation.

Scope. The first item that should be included in the introductory information is a clear identification of the scope of the architecture in terms of type, subject area, and tem-poral nature.

Type. Operational, systems, or technical. Subject Area. The applicable operational, systems, or technical areas or domains for which the architecture is aimed. For example the subject area could be mine warfare in littoral areas, or precision strike. The subject area could address infrastructure such as satellite communications or UHF broadcasts. Technical architectures may cover the range of standards necessary for a given operational or systems architecture or could focus on a specific area such as data encryption standards for direct broadcast systems.

Temporal Nature. The time frame for which the architecture is applicable. Examples of words used to express temporal nature are "current," "as is," "baseline," "to be," "target," "objective," etc.

Purpose and Intended Users. Architectures should also clearly state why they have been developed and for whom.

Purpose. Why the architecture was developed. Examples include to document exist-ing and desired capabilities," to determine operational requirements that must be ac-commodated in a systems architecture, "to provide a basis for determining applicability of a new technology," and "to provide a basis for identifying the best solution to some identified problem.

Intended Users. Who the architecture is intended to serve. Examples include a full range of potential users such as a regional CINC's J6, the JCS/ J3, JTF Component Commander, the Military Intelligence Board, etc.

Context. The interrelated conditions that compose the setting in which the architec-ture exists constitute the context for the architecture. The context includes such things as doctrine; tactics, techniques, and procedures; relevant goals and vision statements; concepts of operation; scenarios; and environmental conditions. Known or antici-pated linkages to other architectures should be identified. Specific assumptions and constraints regarding the architecture development effort should be documented.

Findings (where applicable). For some architectures, particularly those aimed at providing a basis for assessments, a description of the final results of the architectural effort should be presented. Examples of results can include identification of short-falls, recommended system implementations, opportunities for technology insertion, etc.

3- 9 28

28 Page 29 30 Integrated Architectures Panel Appendix C

3.3.2 Architecture Information Scope and context describe the basic conditions under which the architecture applies, and as such are an essential aspect of any type of architecture. Architectures should present, as re-quired, the following information:

Missions to be accomplished

Operational elements to whom the missions are assigned

Nodes where the operational elements are located

Tasks and activities that the operational elements perform

Information flows required to perform the tasks, to include specification of warfighter information

Systems used to support the accomplishment of tasks and the flow of information

System attributes and performance parameters

The technical criteria that govern development and implementation of the systems The level of detail and specificity to which the above are presented depends on the purpose and objectives of a given architecture effort. Figure 3- 6 (on the next page) provides a graphic representation that shows how information is associated with the three types of architectures. The set of products discussed in Section 4 includes all the essential information described above.

The set of information required for each architecture type is discussed below. Scope and environment are necessary aspects that should be specified for any architecture type. A matrix construct has been used in Figures 3- 7 (on the next page) and 3- 9 (on page 3- 13) to represent the essential information. It is not expected that a given architecture would present this infor-mation via a matrix. For an actual architecture, the information would likely be so extensive that presenting it in a hard copy matrix may be impractical and would probably not be useful. Instead this information readily lends itself to being stored in an automated database with only high- level summary or highlighted summary information provided in the hard copy report. Annex A presents an entity- relationship (E- R) data model showing how these sets of informa-tion are related to each other.

3.3.3 Operational Architecture Information The essential data derives from the definition of an operational architecture (tasks, operational elements, and information flows) and attributes necessary to describe the information flow. The relationship across the three basic entities (tasks, operational elements, and information flow) is expressed in the information exchange requirement (IER). The IER is defined as the require-ment for information to be passed between and among forces, organizations, or administrative structures concerning ongoing activities. IERs identify who exchanges what information with

3- 10 29

29 Page 30 31 Appendix C Integrated Architectures Panel

3- 11 30

30 Page 31 32 Integrated Architectures Panel Appendix C

whom, as well as why the information is necessary and how that information will be used. The quality (i. e. frequency, timeliness, security), quantity (i. e. volume, speed), and type of informa-tion (i. e. data, voice, video) are attributes of the information exchange included in the IER. IERs may also identify particular capabilities needed such as large screen displays, interactive database query, color graphics, etc. The specific attributes used in any given operational archi-tecture will depend on the purpose and level of detail of that effort.

Depending on the specific objectives of the operational architecture, information requirements may be specified in a data model with an accompanying data dictionary, using DoD standard data where possible.

Tasks should be related to the JCS's Universal Joint Task List (UJTL). Figure 3- 8 shows how the UJTL can be extended down, through derivative unified command- level Joint Mission Es-sential Task Lists, Service- level Mission Essential Task Lists, to the missions required to be performed by an operational element. The UJTL covers all DoD warfighting tasks such as gathering intelligence, maneuvering forces, and delivering weapons on targets as well as nonwarfighting tasks such as providing logistics support, acquiring weapon systems, and train-ing personnel. It provides a common basis for defining any mission, task, or activity for which a C4ISR architecture must be defined.

A node is defined as a sender or receiver of information or data. In the context of operational architectures, a node could be an organization, organizational element, an activity, or even a person depending on the objectives of the specific architecture and the level at which the archi-3-

12

31 Page 32 33 Appendix C Integrated Architectures Panel

tecture was being developed. Either notional or physical assignments to nodes may be used depending on the needs and objectives of the specific architecture effort.

The information elements exchanged must be identified along with their relevant attributes. There is no single, universally accepted list of elements of information within the DoD that can provide a common basis of understanding of information flows. As an initial step to fill this gap, the Framework proposes as a strawman the definition of four major categories of warfighter information into which virtually all types of information needed to support warfighting activi-ties can be placed. These categories are information about the enemy, friendly forces, the environment, and the situation. An initial top- level description of Elements of Warfighter Infor-mation is presented in Annex D as a starting point. A common list of information elements, agreed upon by the JCS, the Services, and the DoD agencies akin to the UJTL will facilitate identification of opportunities for sharing information among operational elements, establish-ing linkages among systems that can provide such information, and promoting the development of technical standards for information exchange.

As the framework evolves, common definitions should also be developed to describe other categories of architecture information such as required capabilities and operational elements.

3.3.4 Systems Architecture Essential Information Systems architectures capture the information flows between nodes, the systems supporting that flow, and the communication systems supporting the interconnection. As defined above,

3- 13

B- A 32

32 Page 33 34 Integrated Architectures Panel Appendix C

nodes are senders, processors, and/ or receivers of information. As shown in Figure 3- 9, nodes are identified by the relevant system and platform. Nodes may also be described by identifying the organization and the location associated with the node. The organization and location may be physical or notional depending on the specific architecture.

Systems architectures also include information and system characteristics appropriate to the objectives of the architecture effort. It is important to note that what constitutes a node depends upon the level of detail represented in a given architecture. For example, in a high- level archi-tecture, "U. S. Army" may be considered a node, but in a detailed architecture "workstation A" may be a node. The characteristics captured in the systems architecture will depend on the purpose of that architecture, but could include such things as applications, operating environ-ment object names, external interface specifications, and security level. For communication interconnections, the characteristics could include such things as capacity, security level, per-formance bounds, electronic waveform, and transport media.

3.3.5 Technical Architecture Essential Information The technical architecture should contain the services, configurations, standards, and conven-tion that are to be implemented in the systems architecture. This technical guidance should be provided in a time- phased manner. As in the operational and systems architecture, scope and context must be specified for a technical architecture. The scope should include the specifica-tion of the subject area and its bounds, and also the timeframe considered in the architecture. The following are other essential elements of a technical architecture:

Specification of Architecture Models - the conceptual paradigms of the processing, database, and communications parts or elements of a system required for the operat-ing environment. Examples of these models are (1) computing: host- based and client/ server; (2) database: relational, object- oriented, distributed, and centralized; and (3) communications: local area network (LAN), metropolitan area network (MAN), and wide area network (WAN). These models provide a basis for technical standards selection.

Specification of an Operating Environment (OE) - the specific implementation of the appropriate common reference model, such as the Joint Technical Architecture (JTA). It defines and integrates support applications, platform services, and interfaces that constitute the infrastructure. It also provides a basis for technical standards selec-tion. A technical architecture is a set of "building codes" for a collection of "building blocks" that must be viewed as a single entity. An OE, by defining how the "building blocks" interact and fit together, is the core of that single entity. Individual OE seg-ments often provide a complete service or a part of a service to other segments in addition to the external environment. Thus each element of the OE cannot be consid-ered as an independent function but must be considered in consonance with the other elements. As the core, the OE defines a set of services and interfaces common to all systems at and below that level.

3- 14 33

33 Page 34 35 Appendix C Integrated Architectures Panel

Specification of Standards - the complete, consistent suite of guideline documenta-tion that reflects consensus among the affected organizational bodies on products, practices, or operations. Based upon the OE and architecture models, it provides a profile of technical standards and descriptions of standards deficiencies. The profile must specify the features, options, and extensions of each standard to the level of detail necessary to meet the TA's objectives.

Data Dictionary - a repository of information about data such as definition, relation-ships to other data, origin, usage, and format. It provides a common reference point for the definition of information, documents information structures, and identifies standard data elements. Standard data elements are the fundamental feature enabling interoperability of all systems; they are the basis for common interpretation, process-ing, display of information, and communications efficiency. While the data dictionary is an essential aspect of a technical architecture, it is also important for operational and systems architectures.

Technical References - the set of references such as policy, directives, conventions, transition guidance, emerging technologies, compliance criteria, and common prac-tices that influence architectural decisions.

3.3.6 Architecture Information Relationships As illustrated in Figure 3- 10 (on the next page), from the operational architecture the IERs, which define the required flow of information between nodes in support of a task, map into the portion of the systems architecture that defines the information being passed from node to node. Through this mapping the IERs are associated with the systems supporting the informa-tion. Similarly, the systems with their associated platforms and characteristics within the sys-tems architecture can be associated back to the information flow, operational elements (nodes), and operational activities in the operational architecture. The standards defined in the technical architecture map into the portion of the systems architecture that describes the system charac-teristics.

3.3.7 Architecture Products A common set of architecture products should be used to present architectural information in a consistent way. Figure 3- 11 (on the next page) presents the initial candidate set of architecture products. The products are presented starting from the operational architecture products upon which the systems products are based and ending with the technical architecture products. Some products, such as the Systems Overlays on the Node Connectivity Diagrams, can be viewed as being either operational or system architecture products, or both. This overlap is due to differ-ences in perspective and in the particular needs of architecture developers and users. What matters is to capture the information that these particular products call for and not what type of architectural product they represent. Data models and a data dictionary are considered core products because they are relevant to each architecture type.

3- 15 34

34 Page 35 36 Integrated Architectures Panel Appendix C

3- 16

35 Page 36 37 Appendix C Integrated Architectures Panel

This list is not meant to imply that every architecture of any particular type must include the full list of its associated products. Instead, individual products from the list should be devel-oped as they support the objectives of a specific architecture effort. In addition, the level of detail to which any particular product needs to be developed varies depending upon the specific objectives that the architecture is designed to meet.

3.4 USING THE FRAMEWORK 3.4.1 Architecture Development Process The following series of steps should be followed in developing an architecture:

1. Determine the intended use of the architecture (e. g., document capabilities, assess issues)

2. Determine architecture's scope and context to include any assumptions or constraints to be considered

3. In accordance with the above, determine what specific architecture characteristics must be captured or displayed

4. Based on the characteristics to be displayed, determine which types of architecture products should be built. To meet any specific objective, products representing one, two, or all three types of architectures may need to be developed. Also, for each type of architecture one, two, or all of the constituent products may be required. In some cases only selected products are needed.

5. Build the products and use the architecture. Additional information on the architecture development process is provided in Annex B.

3.4.2 Use of Architecture Products Figure 3- 12 (on the next page) shows an example of how different architecture products can be used to answer sample questions often posed of architectures. As can be seen in this figure, it may take several products, often representing different types of architectures to answer a par-ticular question. Also any given product can often be used to answer more than one kind of question.

3- 17 36

36 Page 37 38 Integrated Architectures Panel Appendix C

3- 18