67 Page 68 69 Appendix C Integrated Architectures Panel

ANNEX C
The Broadcast/ Receive Example Architecture Study

C. 1 Background An example case study has been undertaken that illustrates both the principles of the Frame-work guidance and an applicable set of architecture products. The example selected is the Broad-cast/ Receive Working Group effort that was jointly sponsored by CISA and the Intelligence Systems Secretariat/ Intelligence Systems Board (ISS/ ISB).

As a part of the larger intelligence migration initiative to reduce the number of separate intelli-gence systems, the working group was formed in 1994 to examine the existing Ultra High Frequency (UHF) intelligence broadcast services and one emerging concept for combining the services (Binocular). The group's objective was to uncover and examine issues surrounding the potential combining of service functionality into a smaller number of servicesÐ functional re-dundancy, inefficiency, and impacts on the user; resource duplication; formatting issues; band-width contentionÐ and to make recommendations concerning concepts warranting further study. It is important for purposes of this illustrative case study to realize that the purpose of the working group was not primarily to solve issues, but rather to identify, frame, and examine them and to recommend next steps.

The part of the group's work that is pertinent to the Framework guidance is the modeling effort that was undertaken to provide a basis for quickly comparing the different services. The pri-mary method used to provide this comparison was activity modeling: a template model was constructed that provided a view of the activities any intelligence broadcast service would per-form; then, a separate model was constructed of each service, and the Binocular concept, fol-lowing the template's format but tailored to describe the individual activities and characteristics of each service. A corresponding node diagram was also prepared for each service, which pro-vided a more physical view. This means of comparatively evaluating the broadcast services facilitated communication within the group, revealed some issues, and focused the group's recommendations on issue areas.

The case study presented here is in a sense a "reverse engineering" of the group's work. It describes how the work could have been done in accordance with the Framework guidance, if the guidance had been available then. That is, the case walks through the Framework's five recommended steps to building an architecture and provides examples of the appropriate archi-tecture products. Some of the products shown were actually developed during the working group, some are modifications of actual products, and some are newly created for the case study. The intent of these modified and new products is not necessarily to construct complete products that are accurate in every detail. Rather, the intent is to provide enough plausible detail to be able to illustrate the recommended process, the applicable products, and the link-ages among the products; and to show how these products help to realize the objectives of the architecture.

C- 1 68

68 Page 69 70 Integrated Architectures Panel Appendix C

C. 2 AN ARCHITECTURAL THREAD: The Development and Integration of Architec-ture Products That Support Intelligence Broadcast Issues Analysis

Steps 1. Determine intended architecture use (e. g., document capabilities, assess issues) The Intelligence Broadcast architecture will be used to compare and assess capabili-ties of similar intelligence broadcast services, in identifying potential issues for sys-tem migration and recommending avenues for resolving those issues.

2. Determine architecture scope, context, environment, and any assumptions to be considered.

Much of the scope and context from the original study also applies to this archi-tectural thread:

Focus on UHF intelligence broadcast services, namely Tactical- Related Appli-cations/ TRAP Data Dissemination System (TRAP/ TDDS), Tactical Intelligence Broadcast Service (TIBS), Tactical Reconnaissance Intelligence Exchange Sys-tem (TRIXS), and the Binocular Concept.

"Service" refers to an entire Broadcast/ Receive provider/ receiver/ user (i. e., TRAP/ TDDS, TIBS, TRIXS, Binocular); "system" refers to automated infor-mation systems, communications systems, sensors, receivers, etc., used in con-junction with or as a part of the broadcast service.

Focus on information flow/ exchange. Specifically for purposes of this Architectural Thread the focus has been narrowed down:

Scope problem- solving down to one issue (the "Common Format" issue) from an identifiable set of issues. This represents additional narrowing of scope for this example thread.

Maintain development of the architecture at an unclassified level. Since this study is not intended to be a full- blown architecture, but rather simply a thread, the classified information contained in the referenced report to the Intelligence Broadcast Working Group has been omitted from this case study.

Focus on comparison of broadcast capabilities, independent of programmatics, in issue identification and problem- solving.

C- 2 69

69 Page 70 71 Appendix C Integrated Architectures Panel

3. Based on the intended use and the scope, determine which characteristics your architecture needs to capture.

Based on the intended use, scope, and assumptions from steps one and two, this architecture thread needs to show:

A high- level functional description of intelligence broadcasting

Activities that are supported by one or more of the services

Key nodes (receive or transmit) that support each of the broadcast services

Activities that each node performs

Systems used by each node

Possible issues related to activities

In- depth view of additional formatting requirements and attributes

Issue- specific detail (i. e., formatting requirements, attributes, and information ex-change)

Definitions of terms that will facilitate a common understanding. 4. Based on the characteristics to be displayed, determine which architecture com-ponents/ products should be built.

Using the Architecture Development Matrix as an aid, one can determine that the following products need to be built; the rationale for each product is shown below in Figure C- 1.

C- 3

Figure C- 1: Products Required for Example Architecture Thread

Characteristic Needed	Why Characteristic Needs to be Captured	Product to Build to Capture Characteristic
High- level activities	Get disparate group reading off "same sheet of music"	Generic activity model
Activities supported by one or more of the services.	1- page comparison of functional scope	Color- coded hierarchy chart
Information exchanges	Comparison of services information exchanges, functional complexity	Activity models of each service
Definitions of terms used	Get disparate group reading off same sheet of music	Integrated dictionary
Key nodes (XMIT/ RCV) that support the services	Facilitate comparison of nodes' functional redundancy	Basic node connectivity model of each service
Activities keyed to nodes	Facilitate comparison of nodes' functional redundancy	Basic node connectivity model of each service
Systems used by nodes	Examine system redundancies	Systems overlays to node connectivity models
Possible issues related to activities	Frame issues for selection (format issue selected)	Overlays to activity model (possible issue areas highlighted)
In- depth view of additional formatting requirements and attributes	Issue selected may require more depth	Overlays to activity model (annotations on arrows)
Detail of services' formatting processes	Issue selected does require more depth	Overlays to activity models (decomposition)
Further detail on information exchanges as appropriate for issue	Need to illustrate issue for group discussion	Overlays to activity models (further decomposition)

70 Page 71 72 Integrated Architectures Panel Appendix C

5. Build products, use architecture. The products built are illustrated below (Figures C- 2 through C- 10) with explanatory text showing how they helped in comparing the services, in scoping down the architecture thread to one issue, and in illustrating the issue. Figure subtitles are used to map the products listed in Figure C- 1 to the product illustrations. In addition, the Product Interrelationships N2 Chart (Figure C- 11) highlights the relationships between products built for this architectural thread.

One of the most important steps in architecture development is providing an integrated dictio-nary of terms to facilitate a common understanding of all broadcast activities and related terms of reference used in the architecture. The integrated dictionary has not been attached here, but would be when developing a full- blown architecture.

The modeling and the discussions it triggered resulted in a Working Group recommendation to undertake a formal study of the feasibility of using a common message format for all intelli-gence broadcast services.

C- 4 71

71 Page 72 73 Appendix C Integrated Architectures Panel

C- 5