Home : Home : Warfare Centers : NSWC Dahlgren : Dahlgren Resources : Leading Edge : I&I Leading Edge : Haug
Integrated Capability Framework:
Building a Metadata Structure for Diverse Products 
________________________________________________________

By Stephen R. Haug

There are many producers and users of architecture data in the Integration and Interoperability (I&I) community, including operational mission planning, testing, training, acquisition and development, capability analysis and definition, cost analysis, and many more. No matter the purpose, the architecture created must include sufficient detail to meet the needs of the intended users; it must be created to enable communication and collaboration between the various users of the architecture, including the intended users and the unknown future users. This is especially important given the increasingly collaborative and net-centric nature of Navy and Joint missions. Missions performed by the Navy are rarely performed by a single ship or aircraft; rather, they are usually performed by operators using multiple systems on multiple platforms simultaneously. There are many frameworks1 with different data models and taxonomies (languages) that attempt to enable architecture definition, but most fail to address all issues associated with defining architectures. Many times, frameworks use terms that are not understood by all users or the frameworks focus on one user at the expense of others. Each user has unique needs, but in order to integrate capabilities, the user processes must occur in collaboration across Navy operational, acquisition, test, training, and engineering stakeholders. To solve these issues, a cross System Command (SYSCOM) team created the Integrated Capability Framework (ICF)2 that leverages existing frameworks and is intended to be the common, overarching framework that drives and ties together each of the user processes.

ICF Creation

The first step in creating the ICF was to understand the needs of the various users. The ICF team identified a set of expected users of the ICF (both as architecture creators and users of ICF compliant architectures) and interviewed representatives from those positions and communities. After analyzing interview results, as well as other input from the I&I community, a few common themes emerged:

  • Architectures must be built with consistent taxonomies.
  • Architecture data must be from authoritative sources.
  • Architectures must be based on missions as understood by the operational Navy.
  • Architectures must contain a minimum set of data and views to be useful in defining a mission-based architecture made of people, platforms, and systems.
  • System and mission architectures must be able to be mapped to each other.

Simultaneously, the ICF team evaluated the existing frameworks and taxonomies, as well as the Navy and DoD policy and guidance that constrained the ICF solution. One constraint identified was that all architectures created in the DoD are required to be Department of Defense Architecture Framework (DODAF) compliant. Similarly, the Department of the Navy (DON) Chief Information Officer (CIO) has issued an Architecture Development Guide (ADG) that constrains how DODAF architectures are created.

ICF Solution

The first issue addressed by the ICF was the common taxonomy. Without a common language, including the types of architecture data, the relationships between the data types, and the authoritative source of definitions of that data, architectures cannot be commonly understood or used by all parties. The DODAF Meta Model (DM2), which defines a number of types of data and relationships in architectures, was evaluated to determine the minimum set needed to fully define a mission-based architecture, including a determination that no additional relationships are needed. The resulting data model is shown in Figure 1. In the diagram, a commonly understood term is the first item in each data type block, and (as needed) the DODAF term is provided in parentheses. A definition for each data type is provided in Table 1.         
       

 

DATA ELEMENT  

DESCRIPTION  

TAXONOMY/SOURCE  

Mission Area/Required Operational Capability (ROC)(Capability)

The abilities need to execute specified courses of action, organized into the specific segments of the overall Navy mission.

 Mission Areas and Required Operational Capability/Projected Operational Environment Standards (Office of the Chief of Naval Operations Instruction (OPNAVINST) C3501.2K)

Task (Activity)

Work, not specific to a single organization, weapon system or individual that transforms inputs into outputs or changes their state. (DODAF)

 Navy Tactical Tasks (NTAs) as assigned to platforms/systems/organizations in Navy Mission Essential Task Lists. Note that detailed scenarios may require extending the leaf level activities defined in the NTAs.

Tactics, Techniques, and Procedures (TTP)/ Doctrine (Rules)

Fundamental principles by which the military forces or elements thereof guide their actions in support of national objectives. (JP 1-02)
The constraints placed on any Task or System Function in performance of a mission scenario.

 Operational Plans (OPLANs), Navy TTP

System Function (Activity)

Work assigned to a specific system that transforms inputs to outputs or changes the system state. (DODAF)

 Joint Common System Function List (JCSFL)

                Table 1. Data Element Descriptions and Authoritative Source

In addition to defining the minimum data set needed for fully defined mission architecture, the ICF includes authoritative sources for the terms and definitions for each type. Without that common definition, architectures cannot be easily understood by all parties. As an example, consider the term used for a sweetened, carbonated beverage. According to the Harvard Dialect Survey3, more than 12% of the country uses the term “coke” to refer to all soft drinks, but a person in the northeast U.S. (where “soda” is the much more common term) may not understand an architecture that used “coke” to refer to anything but Coca-Cola®.

Similarly, without a common data model and taxonomy, architectures cannot easily be used in combination with other architectures. Using the same example, if an architecture was created for a soft-drink dispensing system that was to provide six dispensers of “coke,” and an architecture was created for a restaurant that needed a “Coke” dispenser, putting the two architectures together may not result in the desired effect. Even worse, if the restaurant architecture called for a “soda machine,” the “coke dispenser” may not even be considered.

To identify the appropriate authoritative sources, the ICF team evaluated existing taxonomies for each type of data to identify an authoritative source, taking into account policy and guidance. An important factor in each choice was the appropriate “owner” of the taxonomy. For example, Tasks (Activities), are performed by operational Navy personnel – the enlisted and officer Sailors out in the Fleet. As such, it is appropriate to use a taxonomy in use in the operational Navy, the Universal Naval Task List (UNTL), rather than one made by acquisition personnel. A sample of the resulting ICF taxonomy is provided in Table 1.

Once the minimum data set and the authoritative sources were defined, the ICF team defined a minimum set of products or views into the data. Each product is built from a subset of data in the ICF Data Model, and from the authoritative sources. In addition to the prerequisite Overview and Summary Information (AV-1) that defines the scope and purpose of the architecture, the ICF identifies two major sets of products – the Mission Technical Baselines (MTB) and the System/Platform Technical Baselines (S/PTB). The list of products is shown in Table 2, including a description and the DODAF terminology.

ICF MISSION TECHNICAL BASELINE PRODUCTS

  1. Concept of Operations (CONOPs)/OV- 1/TACSIT
  2. Required Capabilities/CV-2, CV-4. CV-5. and CV-6
  3. Organizational Relationships Chart/OV- 4
  4. Mission Thread/OV-6a and OV- 6c
  5. Information Exchange Requirements (IERs)/OV-3
  6. Functional Requirements/SV- 5a

SYSTEM/PLATFORM TECHNICAL BASELINES

  1. Functional Capabilities/SV-4 and SV-7
  2. System to Node Mapping/SV- 1
  3. System/Node Connectivity View/SV-2 and SV-6
  4. System/Interface Standards/StdV- 1

Table 2. ICF MTB and S/PTB Products

MTB products are based on a Tactical Situation (TACSIT) definition of the mission to be performed, which includes key details such as the desired effect of the mission, the required capabilities, the tactics and rules of engagement (ROE), the tasks to be performed and the measures of performance (MOPs) for each task in support of the desired effect. Also in the TACSIT are the information that must be exchanged, and the system functions needed in support of the operational tasks. It is especially important to capture the ROE and the tactics as the Fleet expects to execute the mission, since these can greatly affect ordering of tasks and who performs them; the ability of the force to meet the desired effect; and even which systems are critical in support of the mission. As an example, if only command nodes are permitted to declare a target hostile, then the communications systems and networks on all platforms become critical systems for the mission even for a self-defense engagement, a detail that could be easily overlooked without the ROE. 

The S/PTB products define the following: the platforms and systems that are expected to be part of the mission; the functionality each must provide and the associated MOPs; the platforms on which each system resides; and the communications between each system and platform.

In order to fully define and evaluate the mission and identify potential interoperability issues, the systems and platforms in the architecture should be specific whenever possible. Instead of generically defining a carrier, helicopter, or radar, the specific hull number, aircraft type, and systems should be specified. Otherwise, details like different data link implementations or different radar performances can be overlooked, and the analysis of mission capability or interoperability of the systems would then be incomplete.

Identifying the owner of the views, is just as necessary as identifying the data and views needed. The view owner has the most understanding of the data in the view and is empowered to make the decisions about the views. For example, the operational view products in a mission-based architecture define the mission from the perspective of the warfighter, including the desired effect, tactics, environment, chain of command, tasks to be performed, etc. In order to be representative of actual Navy operation, this data must all be owned and defined by the Fleet, e.g., organizations like Fleet Forces Command (FFC), Pacific Fleet (PACFLT), the Operational Test and Evaluation Force (OPTEVFOR), and the Warfare Centers of Excellence (WCOEs). Similarly, system view products must all be owned by the program managers who are responsible for producing the platforms and systems.

The final step in creating the ICF compliant mission architectures is to combine the MTB with the several S/PTBs to create an Integrated Capability Technical Baseline (ICTB). Creating the MTB and S/PTBs using the data model and authoritative sources, is significantly easier than when using individually defined terms. As an example, since the MTB defines the required system functions using the Joint Common System Function List (JCSFL), and the S/PBT products define available system functions using the same list, matching needed functionality to provided functionality is possible. Work will still be needed to fully integrate the products, of course. For example, an MTB that says it needs a system to “Acquire and Track Targets” (JCSFL number 2.1.39) will require more analysis to determine what kind of target and how well it must be tracked (e.g., an E2 Hawkeye, designed for air/surface tracking and command and control, will likely be of little use in detecting submarines). However, having all sensor systems that are capable of acquiring and tracking targets as defined in the JCSFL use that term and definition enables discovery of systems that can perform the function – something that is much more difficult if each architecture uses different terms. Figure 2 depicts an ICTB with linkages between the products.

Having a completed ICTB then enables the definition and analysis for the operational, testing, training, and acquisition and development communities that are not easily performed otherwise. For example, a simple analysis can determine if physical communication paths exist among the S/PTBs to enable the operational information exchanges identified in the MTB; more detailed analysis can identify if the communication bandwidth is sufficient, and if there are redundant paths for the data. This analysis can be used to identify additional system requirements to the acquisition community or the need to change the information plans or available platforms/systems for the operational community to complete the mission. Further analysis can begin to identify I&I issues such as how specific platforms and systems will be used, how specific missions enable analysis to determine where functionality is duplicated in the force; or where the same data is transferred via more than one communication path, which can lead to interoperability issues.

The completed ICTB also enables a more complex analysis. As illustrated in Figure 2, each system on each platform has performance requirements defined for the functionality performed. Each system function supports an operational task that has a measure of performance supported by both the system function and the operator, and each operational task measure is linked to the desired effect of the mission being performed. Having this complete linkage allows the Fleet mission planner to evaluate the ability of the force to achieve the desired effect and to define the operator performance level requirements for each supporting system. Having a completed mission thread with those same measures of performance allows the training community to develop training curricula, and the testing community to develop test scenarios to measure system performance and operator proficiency. Similarly, the ICTB allows analysis of the systems, platforms, and sailors to enable definition of gaps linked to Fleet need, as well as defining new DOTMLPF solutions, including prioritization and definition of new and modified systems.

Conclusion

Using the ICF for creating architectures enables all users to more effectively and efficiently perform their tasks and improves collaboration. From the Fleet perspective, use of the ICF enables more complete definition of warfighter need and more effective collaboration with the acquisition community. As the MTB owners, the Fleet will be able to more easily and completely communicate to the acquisition community how they intend to execute the missions, input that is critical for all types of analysis. The acquisition community is already required to generate DODAF-compliant architecture products. Using a mission-based approach in compliance with the ICF and Fleet-owned mission architectures help ensure that the architectures are useful for all communities, with little to no extra cost. Definition of system requirements, analysis of systems, and system test all benefit from having relevant operational scenarios to help ensure completeness and correctness. The ability of the Fleet to use ICTBs will enable definition of training requirements and curricula, and evaluation of operator proficiency. Finally, use of the ICTBs will enable complete, accurate analysis of mission capability, identification of potential interoperability issues, and DOTMLPF solutions to gaps in mission capability.

 


Article Images




Figure 1. Integrated Capability Framework Data Model



Figure 2. Example ICTB Products and Linkages


Article References

  1. “Framework” definition: “A logical structure for classifying and organizing complex information”, Federal Enterprise Architecture Framework.

  2. “Integrated Capability Framework Operational Concept” Document, Version 2.0, 30 September 2013.

  3. Vaux, Bert, and Scott Golder, “The Harvard Dialect Survey”, Harvard University Linguistics Department, 2003.