Integrated Mission Baselines:
Using Fleet-Owned, System Command Serviced Architectures to Improve System Integration and Interoperability
__________________________________________________________________________
By Joseph Pack
Current acquisitions require the use of architectures during both the design and integration phases of development in accordance with a series of Department of Defense (DoD) and civilian publications that regulate system development and engineering best practices. Within specific development communities, such as communication and networking, architectures are used far more effectively because of their obvious benefits in managing diverse resources and data types across complex enterprises. However, for many Navy weapons, sensors, and combat systems, as well as other future technologies, architectures have been used more frequently to maintain compliance with current acquisition regulations than to aid in predicting and mitigating future interoperability problems that risk degrading Fleet readiness or preventing an emerging technology from improving Fleet readiness to its full potential.
The objective of Navy integration and interoperability (I&I), as articulated in the Vice Chief of Naval Operation’s-endorsed I&I charter, is to improve existing acquisition practices by establishing a Navy organization that better works across acquisition communities and program offices. This is accomplished in part by encouraging data management and exchange throughout organizations that have traditionally experienced stovepipe behavior. Architectures, being proven effective for integrating diverse data types and relationships, can be used to realize the I&I objective of improved data sharing. This article will examine the application of developing mission reference architectures that focus on capability and operationally driven models. The application of such models ranges from simplifying collaboration between the acquisition community and the Fleet, to providing validated mission context toward systems and modeling development.
System Architecture and Mission
Architecture Integration Using Integrated
Mission Baselines (IMBs)
Traditional use of architectures has focused on system, system-of-systems, and software architecture, with emphasis on the material aspects of a given enterprise or on the satisfaction of interfacing and resource exchange requirements. Mission architectures are fundamentally different from these forms of architecture in their focus on the Fleet’s desired effect and the operations required not only to achieve the desired effect but also on a mission’s doctrine, training, and conditional constraints. These differences are more clearly understood by observing different architecture types articulated in past and present Department of Defense Architecture Framework (DODAF) specifications.
An “integrated architecture” is said to be a product where all architectural viewpoints and models uniquely define and consistently interpret data. Architecture is said to be integrated when it meets the following criteria:
- The architectural objects common to more than one view are identical or linked by underlying data relationships.
- All objects that have relationships across views are linked by underlying data relationships.
For many, if not most system architectures, these definitions sufficiently describe the level of integration built into their products, and for good reason. System architectures exist to adequately describe an individual system’s full functionality, physical configuration, and employment. This implies a level of independence from a larger enterprise that makes anything more than an integrated architecture of limited value to component engineers and systems analysts.
However, an integrated architecture does not physically exist in absence of a larger enterprise. Both physical configuration and employment strategies for a given system are informed by the larger Navy enterprise architecture. This larger architecture is referred to as a “federated architecture,” defined in DODAF v1.5 as a product that “allows the architecture user a means to examine the enterprise from all aspects of the Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel and Facilities (DOTMLPF) concept.” This implies that even though a system architecture may exist at the integrated architecture level, it is dependent on the information contained in a larger federated architecture. For systems developed for strategic and tactical applications, a larger federated architecture is represented through mission area architectures owned by senior uniformed leadership and the numbered Fleets as depicted in Figure 1.
While system architectures contain the entire functionality of a given system and a description of its use, in context of its design-to-platform or system-of-systems, mission architectures contain the partial functionality of multiple systems required to achieve a given desired effect or mission outcome; both products rely on information from the other. Mission architecture informed from the design-to-functionality and performance from the system architecture, and the system architecture must adhere to the strategic and tactical employment schemas articulated in the mission architecture, as illustrated in Figure 2. This relationship identifies the requirements for systems engineers to support mechanisms that allow for both the information publishing and subscribing to some form of federated mission architecture. One such mechanism is the IMB.
Definition
An IMB is a mission-based reference architecture that models the capabilities and activities required to achieve a desired effect for a particular mission and set of environments or conditions. Similar to reference architecture in software engineering practices, an IMB is used as a template to begin production of a fully federated architecture using platforms and systems that span multiple program offices, platforms, and DoD services. By serving as a reference across multiple organizations, an IMB serves as a mechanism whereby disparate system architectures originating from different organizations may converge on a common understanding of how a mission is executed by the Fleet.
Architecturally, the IMB is heavily reliant on Capability Viewpoints (CVs) and Operational Viewpoints (OV). Selected viewpoints focus on defining the mission to be executed; the complimentary capabilities required to complete the mission; activities required of personnel, platforms, and organizations for each activity; and doctrinal constraints placed on mission execution by virtue of relevant conditions (e.g., environmental, geopolitical) and locations.
The role of an IMB is to serve as the Fleet-owned and endorsed mission reference for system employment and enterprise readiness evaluation. The significance of Fleet ownership is nontrivial. Current mission architectures, if produced at all, are the result of data collection efforts on the part of system commands (SYSCOMs) and program offices. When each program office is responsible for its own mission architectural development, the potential exists for multiple interpretations of the same mission, as illustrated in Figure 3. The material risk to the Navy is the deployment of multiple systems into the Fleet built on non-standard battlefield interpretations, resulting in inconsistent or unpredictable mission performance. More often than not, this inconsistency or unpredictable mission performance results in a degraded Fleet readiness until sufficient interoperability mitigation strategies can be developed, vetted, and implemented. The use of Fleet-owned IMBs enforces a level of consistency among program offices that mitigates this risk, as illustrated in Figure 4.
Structure and Use-Case
|
VIEWPOINT
|
ACRONYM
|
PURPOSE
|
|
Overview and Summary Information
|
AV-1
|
Provides a brief overview of information contained within the product
|
|
Integrated Dictionary
|
AV-2
|
Architecture data repository with definitions of all terms used in all products.
|
|
Capability Taxonomy
|
CV-2
|
A hierarchy of capabilities which specifies all the capabilities that are referenced throughout one ore more Architectural Descriptions.
|
|
Capability Dependencies
|
CV-4
|
The dependencies between planned capabilities and the definition of logical groupings of capabilities.
|
| Capability to Operational Activity Mapping |
CV-6
|
This view describes the mapping between the capabilities required and the activities that enable those capabilities. |
| High-Level Operational Concept |
OV-1
|
High-level graphical/textual description of operational concept. |
| Operational Node Connectivity Descriptions |
OV-2
|
Information and resources exchanged between nodes and the relevant attributes of that exchange. |
| Organizational Relationships Chart |
OV-4
|
Organizational, role or other relationships among organizations. |
| Operational Activity Taxonomy |
OV-5a
|
Taxonomy of all activities included in the given architecture - useful for identifying the operational scope of the architecture. |
| Operational Activity Mapping |
OV-5b
|
Mapping of relationships between tasks that helps to identify the required sequence of events that may take place given a known set of initial conditions. |
|
|
Table 1: Integrated Mission Baseline Core Models
|
Throughout fiscal year 2013, an I&I-funded effort sought to define, construct, and investigate IMB usage. The Naval Surface Warfare Center, Dahlgren Division (NSWCDD), took the lead by developing a surface warfare IMB, focused on missions typical of Littoral Combat Ships. Architecturally, the IMB consisted of the All Viewpoint (AV), CV, and OV products in Table 1.
The selection of IMB viewpoints focuses on accurately capturing data elements from the Integrated Capability Framework Data Model that sufficiently and distinctly identifies what the Fleet is trying to accomplish, how it is trying to accomplish it, and which agencies, operators or performers are required to accomplish it. Figure 5 depicts these elements.
The architectural approach taken to create the products in the surface warfare IMB followed a methodology developed for the sole purpose of modeling Navy missions called the Capability-Based Modeling Methodology (CBMM).
Fleet-First Architectural Methodology
The importance of using CBMM instead of other common methodologies is due to its focus on Fleet capabilities. CBMM was developed based on the theory that most Fleet stakeholders can be categorized into one of three domains: Fleet Capability, Operational, and Technical (see Figure 6). The relationships between these domains aid in identifying necessary authorities for sources of data as well as potential consumers.
The CBMM primarily focuses on the Fleet’s desired effect; without this, the mission would not exist. Therefore, it is the Fleet’s desired effect that is often the most well-defined part of a mission, especially since the method of mission execution and performance of relevant systems may be highly variable on external factors not fully realized before the mission is executed.
For this reason, the CBMM encourages initially establishing a capability taxonomy to accurately characterize the nature of the Fleet’s desired effects. Following the capability taxonomy, architecturally called a CV-2, architects can begin identifying dependencies between capabilities (CV-4) and activities required for successful achievement of a capability (CV-6). Only after capabilities have been properly characterized and mapped can OV and System Viewpoint (SV) creation begin.
This approach forces architects to focus on the Fleet first rather than a particular system or systems. It puts Fleet-owned data, such as doctrine and current rules of engagement, in front of an engineer’s understanding or a program office’s interpretation of the missions of interest. Because of this Fleet-first approach and because of the genesis in AV and CV products, the CBMM serves as an efficient method of architectural development for a mission baseline-level reference architecture.
Impacts to Architecture Development
As with most models, modeling languages, and engineering tools, architectures are only useful if designed for the correct purpose. Currently, many program offices, SYSCOMs, and Fleet organizations use architectures for communication, collaboration, and compliance. These purposes, while important for the daily function of all Navy organizations, do not lend themselves to achieving goals set forth in the DODAF regarding integrated and federated architectures.
Improvements to Current Architecture
Development
Architectures are currently required by both the Joint Capability Integration and Development System’s acquisition process and the latest iteration of DoD Instruction 5000.02E, “Operation of the Defense Acquisition System.” Though required, the proper generation, use, and governance over architectures has traditionally been ambiguous. Programs interested in acquiring a new system, making modifications to an existing system, or attempting to transition a new technology, use mission architectures to map system functionality into Navy operations using DODAF viewpoints. As mentioned earlier, mission architectures represent a form of federated architecture under the DODAF construct and, as such, require the architects to understand not only their specific system focus but also systems used throughout the entirety of the mission as well as how operations are conducted by the uniformed organizations of interest.
Under the previous, non-I&I-informed system, it was up to the individual program offices or field components to develop, verify, validate, and exploit their mission architectures. For SYSCOMs, this required architects to compile data from numerous internal and external sources. Some sources of information were known and others were combined through known associations and professional contacts. Even today, system data tends to be better understood, as are sponsors, direct users or stakeholders identified by the sponsor, as well as initial performance requirements and capability analyses. The SYSCOM-level engineer may not understand without proper integration with Fleet components the latest tactics, doctrine, training (including relevant mission essential tasks), personnel or manning, platform readiness and availability, and other relevant geopolitical information critical to the successful employment of a new system or technology.
To the individual architect, this may not seem like any more of a burden on one party than another (see Figure 7). However, there are numerous programs—all reaching out to the same (or similar) organizations—asking for common data for each independent architectural effort, as shown in Figure 8. The result is a risk of overburdening data requests on relevant Fleet components and redundant manpower investments by the Navy. There is also a risk that two independent programs attempting to address a common mission area or environment may base their architectures on data originating from disparate sources, which often results in different solutions or inefficiently integrated products into a common mission area. Figure 8 illustrates how multiple architectural efforts, when accessing common data sources, can create unnecessary complexity and additional task loading on Fleet organizations.
If architects were to use an IMB established and
maintained by the new I&I organization and owned
by the Fleet, the Fleet would not be overburdened
by redundant requests for data. Common use of
single data sets also allows for more consistent data
gathering and exchange among architects spanning
across different and distinct Navy programs, as shown
in Figure 9.
Implications to Increased Fidelity and
Consistency of Modeling and Simulation
(M&S)
Following an IMB construct benefits an organization
not only through managing data gathering
among architects but also in managing and coordinating
data gathering among those in the acquisition
community who need readily accessible data external
to their corporate organization. A prime example of
this type of data sharing occurs during investigations
and development of M&S strategies as well as
each tool’s verification and validation process. For a
modeling tool to maintain integrity with the mission
and to correlate with data produced by other tools,
it must access data external to the technical community
and owned by the Fleet, such as doctrine,
tactics, and physical limitations of the deployed force.
To the individual M&S team, it may seem viable to
simply contact the Fleet components relevant to a
given modeling effort. However, when viewed from
the Fleet component perspective, a single engineering
or acquisition organization may have multiple M&S
teams contacting a single Fleet component office for
common sets of data. This not only risks damaging
the Fleet’s perception of that engineering organization
but also reduces the Fleet’s willingness to work with
the engineering community.
These organizational risks can be alleviated by
implementing IMBs into the data sharing and gathering
process, which will provide Fleet components a
single technical point of contact from which they may
publish and subscribe data. This also alleviates the
responsibility of each M&S team to contact multiple
Fleet components, allowing them instead to simply
consult a single IMB reference product that contains
vetted and validated Fleet information.
Effort Cost Savings
Typically, as project complexity decreases, so does
estimated cost. As previously noted, complexities in
organizing architecture and M&S data needs can
be greatly simplified through the use of IMBs. This
represents significant potential for reductions in labor
spent developing, maintaining, and exploiting contacts
and releases architectures and M&S developers
for more prudent tasking.
Future fiscal year efforts may also experience
cost saving by way of architecture reuse, as shown in
Figure 10. By leveraging the CBMM architectural
methodology, IMB products are inherently compartmentalized
by capability. Suppose a mission architecture
contains capabilities for conducting intelligence,
surveillance, and reconnaissance (ISR) operations
and capabilities for conducting small caliber gunfire
engagements. During the next fiscal year, suppose the
same organization wants to produce a similar mission
architecture but instead, looks at engagements with
directed energy weapons. Both the former and latter
architectures would use the same ISR capabilities,
thereby preventing the latter architectural effort from
investing in redundant capabilities.
Using an activity-based architectural approach
would require a revalidation of the activity flow
throughout the architecture and an object-based
approach would require revalidation of platforms
since key engagement systems were changed. However,
because the CBMM organizes everything by
capability, the architecture contains an inherent
modularity. The IMB, composed using the CBMM
approach, enjoys the same modularity and, therefore,
may experience significant cost savings as more IMBs
are produced.
Additional cost savings may be realized through
the effective and efficient consolidating of data gathering
and consistent use of known information. In a
new age of austerity, where funding for data collection
during live at-sea events and opportunities for
costly tests are diminishing, engineers must maintain
clear and open lines of data gathering and sharing
to ensure programmatic limitations do not degrade
the mission competence used to produce systems for
warfighters. Using an IMB to coordinate data across
development teams and programs mitigates risks
created by inconsistent and insufficient data collection
and interpretation, which in turn leads to unexpected
expenses associated with data reconciliation.
Conclusion:
IMB is Architecture Used Properly
Models are developed for a purpose; an architecture’s
purpose being the management of data in
accordance with a data model. The purpose of an IMB
is to coordinate data gathering and sharing and to
maintain open data availability across an enterprise.
Use of an IMB allows integrated system architectures
to connect into the larger federated Navy enterprise,
which supports the goals of DODAF and the Global
Information Grid Architecture. By integrating system
architectures into Fleet-owned and -validated mission
architectures, program offices may predict I&I
problems before investing heavily in manufacturing
and prototyping. The IMB serves as the vehicle that
allows program offices to consume that Fleet-owned
data necessary for such I&I analysis.
IMBs also serve the important purpose of reducing
cross-organizational complexity. The “spirit of I&I”
has been one of collaboration and open data exchange.
Without some mechanism to act as a catalyst for the
tenets I&I endeavors to establish, changing the current
means of architectural and system development will
be difficult. By building, supporting, and encouraging,
if not enforcing, the use of IMB-like architectures,
that catalyst exists and enables many of the parallel
efforts articulated in the I&I charter.
By integrating efficient data management through
use of IMBs, the broader Navy community is better
enabled to avoid costly problems with system interoperability
and ensure efficient material and non-material
solution integration to create a high level of
readiness throughout the Fleet.