67 Page 68 69 Appendix C Integrated Architectures Panel
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 CC. 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.
|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 C5. 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
72 Page 73 74 Integrated Architectures Panel Appendix C C- 6
73 Page 74 75 Appendix C Integrated Architectures Panel
96- 0254C- 29 74
74 Page 75 76 Integrated Architectures Panel Appendix C C- 8
96- 0254C- 30 75
75 Page 76 77 Appendix C Integrated Architectures Panel
96- 0254C- 31 76
76 Page 77 78 Integrated Architectures Panel Appendix C C- 10
96- 0254C- 32 77
77 Page 78 79 Appendix C Integrated Architectures Panel
78 Page 79 80 Integrated Architectures Panel Appendix C C- 12
79 Page 80 81 Appendix C Integrated Architectures Panel
80 Page 81 82 Integrated Architectures Panel Appendix C C- 14
81 Page 82 83 Appendix C Integrated Architectures Panel
82 Page 83 84 Integrated Architectures Panel Appendix C C- 16
83 Page 84 85 Appendix C Integrated Architectures Panel
84 Page 85 86 Integrated Architectures Panel Appendix C C- 18
85 Page 86 87 Appendix C Integrated Architectures Panel
86 Page 87 88 Integrated Architectures Panel Appendix C C- 20