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
|
- Concept of Operations (CONOPs)/OV- 1/TACSIT
- Required Capabilities/CV-2, CV-4. CV-5. and CV-6
- Organizational Relationships Chart/OV- 4
- Mission Thread/OV-6a and OV- 6c
- Information Exchange Requirements (IERs)/OV-3
- Functional Requirements/SV- 5a
|
|
SYSTEM/PLATFORM TECHNICAL BASELINES
|
- Functional Capabilities/SV-4 and SV-7
- System to Node Mapping/SV- 1
- System/Node Connectivity View/SV-2 and SV-6
- 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.