Home : Home : Warfare Centers : NSWC Dahlgren : Dahlgren Resources : Leading Edge : I&I Leading Edge : Pack
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.

 
Article Images




Figure 1. Integrated vs. Federated Architecture as Modeled in DODAF V1.5



Figure 2. Fleet and Acquisition Community Construct Data Ownership



Figure 3. Communicating Data Needs Absent a Common Data Management Environment



Figure 4. Communicating Data Needs with a Common Data Management Environment



Figure 5. Integrated Capability Framework Data Model Highlighting Integrated Mission Baseline Data Elements



Figure 6. Capability-Based Methodology Acquisition Triad



Figure 7. Data Sources Consumed and Managed by the Mission Architect




Figure 8. Complexity Caused by Independently Functioning Architecture Efforts
       



Figure 9. Simplification of Data Collection and Management Using an Integrated Baseline




Figure 10. Notional Demonstration of Cost Savings Over Time Using Modularized Rework from Past Architectures