57 Page 58 59 Appendix C Integrated Architectures Panel
B- 1 Guiding Principles Revisited
The set of Guiding Principles was initially introduced in Section 3. The following provides some additional considerations on those principles. The set of guiding principles for building architectures has purposely been kept small; therefore, each is critical to the objectives of the guidance. The principles are listed below.1. Architectures should be built with a purpose in mind. Having a specific and com-monly understood purpose before starting to build an architecture greatly increases the efficiency of the effort and the utility of the architecture. The purpose determines the appropriate scope, the characteristics that need to be captured, and the time phases that need to be considered. This principle applies equally to an architecture as a whole and to any portion of an architecture. It can also be said to apply to groups of architec-tures. If groups of architectures built by various organizations are to be compared, it is important that they all be built from the start with the purpose of comparison in mind.
2. Architectures should facilitate, not impede, communication among humans. Architectures must be structured in a way that allows humans to understand them quickly and that guides the human thinking process in discovering, analyzing, and resolving issues. This means that extraneous information must be excluded (see prin-ciple number one) and common terms and definitions must be used. Often, graphical formats are best for rapid human understanding, but the appropriate format for a given purpose must be used, whatever that format may be.
3. Architectures across DoD should be relatable, comparable, and integratable. Like principle number two, this one necessitates the use of common terms and defini-tions. This principle also necessitates that a common set of activities be used as the basis for architectures. A likely candidate for this common set of warfighter and warfighter- support activities is the Universal Joint Task List (UJTL). However, the UJTL is only a list as opposed to a model (for example, a model that shows standard inputs and outputs to each of the activities and that assures input/ output consistency across all levels of all activities) and is only detailed to a finite level of decomposition. Therefore, some architectures may need to use different activities or decompositions of activities; however, deviations from the UJTL should be mapped to any corre-sponding activities within the UJTL.
This principle also dictates that similar- type products developed for different archi-tectures display similar types of information about their respective domains, in simi-lar formats. (This is discussed further in Section 4.)
B- 1 58
58 Page 59 60 Integrated Architectures Panel Appendix C
4. Architectures should be modular and reusable. Architectures should consist of sepa-rate but related pieces that can be recombined with a minimum amount of tailoring, so that they can be used for multiple purposes.A fifth principle could be added to the initial four: 5. Architecture efforts should be designed to obtain the most useful results in the least amount of time. It should not always be necessary to spend large amounts of time, money, and resources in order to obtain useful results from an architecture develop-ment/ analysis effort.
The recommended characteristics (information) to be captured, the set of products to be built to capture those characteristics, and the procedure for using the Framework have all been de-signed to ensure that the above principles are followed. These aspects of the Framework and some guidance for documenting architectures are discussed in following paragraphs.
B- 2 The Role of Products When completed for a given architecture, the set of products constitutes the architecture. These architecture products are distinguished from preexisting information sources that may be used in building architectures, such as existing models, lexicons, operational requirements docu-ments (ORDs), operational concept descriptions, technical reference models, and doctrine. Applicable extracts from these sources may be used in the architecture itself as portions of architecture products. The completed architecture may then become an information source for other architecture development efforts.
Several architecture product types have been developed as part of this Framework guidance. Products of these types, if built in accordance with the guidance and examples provided, will allow architecture builders to capture the characteristics needed for particular analysis efforts. One important purpose of an architecture is to communicate among humans so that specific issues can be analyzed. In order to facilitate this human communication, most of the product types have been designed as graphics, supplemented by text as needed.
As listed in Section 3 and discussed in Section 4, the products form a continuum from the Operational Concept Diagram through the various products associated with operational, sys-tems, and technical architectures. Generally, progressively more detail is provide in each suc-cessive product. Several products have been designed as overlays and extensions to basic product types; for example, cost and node information may be overlaid on activity models and the systems may be overlaid to node connectivity models. This increases the cohesiveness of the set, emphasizes linkages among component types, and maximizes reuse of individual prod-ucts. Such reuse can occur, for example, when one architecture is used to address multiple issues: analysis of the issues may involve the same activity and data models, but require differ-ent overlays.
B- 2 59
59 Page 60 61 Appendix C Integrated Architectures Panel
B- 3 Interrelationships Among the Product Types
No matter what the purpose is for building an architecture, that architecture is intended to "tell
a story" about a given subject area. In order for an architecture to tell a coherent story, all of its
parts must be pieces of that same story, i. e., they must relate to each other in supplementary, not
contradictory, ways. Figure B- 1 illustrates the relationships among the products. The set of
architecture products described here was designed with the intention of having the pieces oper-ate
synergetically, with each providing portions of the story that are built upon in turn by other
products. For convenience, the products are categorized by the architecture type to which they
most appropriately belong, in accordance with the definitions provided earlier. (In the figure,
the categorizations are indicated by color- coding of the icons: blue for operational, orange for
systems, red for technical, and purple for the core, which applies to all types.) In some cases,
there are "gray areas," or cases in which a given product type seems to logically belong to more
than one component. This is caused in part by the progressive nature of the products, which
allows for "systems" characteristics to be overlaid onto "operational" diagrams. Another
type of "gray area" is represented by the Data Dictionary and the Data Model which do not fit
easily into any one product type category and are considered core products. The green arrows
and text highlight the most important of these relationships.
B- 3
96- 0254C- 45 60
60 Page 61 62 Integrated Architectures Panel Appendix C
The decision of what individual architecture products to build is made on the basis of the issue areas the architecture is intended to explore and the resulting characteristics that the architec-ture must capture and describe. A given architecture may therefore consist of all of the products or of a selected subset that is associated with one, two, or all three components. The "binning" of architecture products into operational, systems, or technical categories is a convenient way of describing them, but should not be considered a restriction in building an architecture.B- 4 How to Use the Framework This section expands on the information provided in Section 3 in describing how to apply the Framework in building an architecture. A five- step procedure has been developed.
B- 4.1 The Five- step Procedure 1. Determine the intended architecture use: In most cases, there will not be enough time, money, or resources to build purely top- down, all- inclusive architectures, even within a limited scope. Therefore, before beginning to describe an architecture, one must determine as specifically as possible the issues the architecture is intended to explore, the questions the architecture is expected to help answer, the resources avail-able for building the architecture, and its expected audience and users. This focusing will make the effort more efficient and the architecture more usable.
2. Determine the architecture scope, context, and any other assumptions to be con-sidered: Once the intended use has been decided, the prospective content of the architecture can begin to be addressed. Items to be considered include the scope of the architecture (functional, organizational, time- phased, etc.); the context (the architec-ture development effort's place in the larger scheme, scenarios, circumstances to be depicted); and any other assumptions such as the economic situation or the availabil-ity and capabilities of specific technologies at specific times in the future.
3. Based on the intended use and the scope, determine which characteristics your architecture needs to capture: Care should be taken to determine which character-istics of the subject area need to be described in order to satisfy the purpose of the architecture. If pertinent characteristics are omitted, the architecture may not be us-able; if unnecessary characteristics are included, the architecture effort may prove infeasible given the time and resources available, and the architecture may never be built. Care should be taken as well to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring and reuse.
4. Based on the characteristics to be displayed, determine which architecture com-ponents/ products should be built: Depending on the outcomes of steps one through three, it may not be necessary to build the complete set of architecture components and products. In that case, only those products that display the required characteristics
B- 4 61
61 Page 62 63 Appendix C Integrated Architectures Panel
should be built, and care should be taken to ensure that the products within that subset
are consistent and properly related.
5. Build products, use architecture: The critical last step is to build the required set of architecture products and to use the architecture for the intended purpose. If the archi-tecture needs some tailoring in order to serve its purpose, that tailoring should be done as efficiently as possible. In this regard, it may be useful, resources permitting, to conduct some proof- of- principle analysis of the architecture at various stages of comple-tion.
Table B- 1 shows which of the steps described above promote each of the guiding principles described in Section B- 1.
B- 5 Architecture Development Aids Three architecture development aids have been designed that can facilitate the five- step proce-dure described.
B- 5
|
Principles
Steps |
Architectures should be built with a purpose in mind. | Architectures should facilitate, not impede, communication among humans. | Architectures should be relatable, comparable, and integratable across DoD. | Architectures should be modular and reusable. | Short- term architecture efforts should be useful. |
|---|---|---|---|---|---|
| Determine the intended architecture use. | The intended use is the purpose. | Intended use will determine which architectures to compare. |
Intended use will focus effort.
|
||
| Determine scope, context, environment, other assumptions. | Scoping information will guide reader. | Scoping information will determine which architectures to compare. | Tailored scope will focus effort. | ||
| Determine which characteristics to capture. | Proper choice of characteristics will promote purpose. | Architectures can be compared IAW applicable characteristics. | Additional characteristics can be added for further analyses. | Saves time. | |
| Determine which products should be built. | Product choice can emphasize purpose. | Eliminates unneeded and distracting products. | Products can be added for further analyses. | ||
| Build products, use architecture. | Proper products & use satisfy purpose. | Proper products & use facilitate communication | Consistent products promote comparability, interface descriptions promote integration. | Consistent products promote modularity. |
62 Page 63 64 Integrated Architectures Panel Appendix C
B- 5.1 The Architecture Development Matrix The Architecture Development Matrix summarizes the five- step procedure for developing an architecture, and provides some visual aids for following the procedure. The matrix provides lists of characteristics that may need to be captured in building a given architecture. When a needed characteristic is identified from the listings at the bottom of the matrix, the reader should look up from that listing to determine the graphic style of the product recommended for captur-ing that characteristic, the product's name, and the architecture component of which it is a part. The set of products thus shown to be needed for capturing the appropriate characteristics is the set of products that should be built. The Product Interrelationship Graphic can then help to determine the necessary relationships among the products. See Figure B- 2, The Architecture Development Matrix.B- 6
This matrix is designed to help organizations build architectures to answer specific questions or explore issue areas. It will help focus thinking and answer procedural questions such as "What architecture components do I need to build, and what specific
model/ representations do I need to build, using what methodologies or descriptive techniques?" The steps in using this matrix are described below. 63
63 Page 64 65 Appendix C Integrated Architectures Panel
B- 7
64
64 Page 65 66 Integrated Architectures Panel Appendix C B- 5.2 The Product Interrelationships Graphic The Product Interrelationships Graphic shows the major, high- level relationships among the architecture products and illustrates the general sequence (shown clockwise starting with the Technology Forecast, which is continuous) in which they would be built, assuming that all are required for a given architecture. Figure B- 1, Product Interrelationships, illustrates that the Technology Forecast influences the thinking process in the construction of all the other prod-ucts. The text items describe the "pieces of the story" that each product provides to others. The two "information products," the Data Dictionary and the Data Model, are shown inside the circle of products in order to show that they support and are fed by all the other products.
B- 5.3 The Product Interrelationships N 2 Chart The Product Interrelationships N 2 Chart provides more detail on the connections and relation-ships among the architecture products and can be used in deciding which products need to be built for a given architecture. By reading to the left and upward from each product type listed at the left of the chart, one can see what each product provides that other products build on. Keeping these kinds of product relationships in mind can help to assure that all products con-tribute to the same architecture "story," and that the products selected to be built for a given architecture forms a coherent and logically related set. See Figure B- 3, Product Interrelation-ships N 2 Chart.
Individual products are described in more detail in Section 4.
B- 8 65
65 Page 66 67 Appendix C Integrated Architectures Panel
B- 9
66
66 Page 67 68 Integrated Architectures Panel Appendix C This Page Intentionally Left Blank B- 10 67