There is a sea change coming in System of Systems integration, and the benefits to the warfighter will be monumental.
Over the past decade, we have plunged headfirst into digital transformation initiatives to keep up with the speed of technology, reap its vast rewards, and maintain warfighting dominance. We have updated our tools, streamlined our development processes, and automated our testing based on the latest advancements. We are acutely aware that our warfighters’ success relies on deploying our most advanced technologies faster and more effectively but are only vaguely aware that those technologies are increasingly dependent on progressively complex integrations. Integration is one area that our digital transformation efforts have in large part overlooked.
What does the next generation in Systems Integration look like? To what level of interoperability should we be aspiring and why? How do we achieve our interoperability goals?
Building & Deploying
Today there is significant momentum behind the paradigm referred to in this paper as Build and Deploy. In many DevSecOps initiatives, the focus is centered on improved efficiency of hardware and software design, development, testing, and deployment. The programs instituted as a part of DevSecOps are both material and beneficial to any integration project, including the adaptability and efficiency of the system lifecycle model, process and communication automation, and the integration of security throughout the lifecycle (DoD CIO, 2019).
When it comes to integration, the DevSecOps Reference Design defines Continuous Integration as going one step further than Continuous Build “…with more automated tests and security scans. Any test or security activities that require human intervention can be managed by separate process flows.” The practice’s goals of reduced mean-time to operation, increased deployment frequency, and updates “at the speed of operation” address integration only through the automated testing of that integration. Neither automated integration itself nor automated maintenance of those integrations is addressed. In fact, the entirety of what content (syntax, semantics, behaviors) to integrate and how to perform those integrations prior to testing is left to the integrator (DoD CIO, 2019).
In the Build and Deploy paradigm, when hardware and software must be connected, these connections are facilitated through Hardware and Software Architectures. Traditional integration methodologies, in fact, successfully handle the lower levels of interoperability that address transport and syntax of data. However, issues of integration relationships and composability are deferred. When an integration by commonality approach is consistently applied, a traditional approach is sufficient. However, when commonality is not suitable, semantic connection and composition of behavior must be explicitly addressed through model-based, machine-actionable documentation.
Although there are a great many initiatives right now to improve Build and Deploy, when it comes to the integration of the relevant deployed systems, traditional methods of integration prevail. As such, only the lower levels of interoperability are reached. Automating the Build and Deploy aspects of software development reaps a great many benefits; however, it simply does not address integration connections or the composition and orchestration of behavior.
Relating
The Relate paradigm raises the bar for integrability to include the documentation and interconnection of semantics. Beyond Hardware and Software Architecture, Data Architecture becomes vital.
Although current initiatives address this paradigm, this is almost always done implicitly. Integration work in a DevSecOps program, for instance, would include IDDs and defined APIs (Application Programming Interfaces). Additionally, the integrators would interpret data as they use frameworks, APIs, and messages to develop code. The semantics are implied, but they are not explicitly defined. As such, changes to the message sets, the APIs, or the systems themselves would require human intervention and a re-integration.
Within DevSecOps there is good reason for the focus on automation to replace or augment human processes in the software development lifecycle. Such automation can also benefit other elements within the development pipeline. Explicit documentation and interconnection of semantics with the goal of automating integration, increases the scalability, testability, and adaptability of that integration in the future. It is only through such rigorous documentation that one may begin to address additional challenges to integration in a scalable manner.
Composing
This integration paradigm is characterized by the composition and orchestration of behavior and involves the Data, Software, and Functional Architectures to achieve interoperability of systems and sub-systems. When deploying and maintaining distributed SoS, it is critical to capture these behaviors and the resulting system state. In other words, it is essential for the system to know when to do something, when to wait for something to be done, and when to address the implications of other system’s interactions and data exchanges. Often, these interchanges and resulting implications are encoded in the APIs or data and signal exchange concepts. They are documented in prose in Service Descriptions or, in ideal cases, are elaborated in sequence diagrams using SysML or UML tools. While these approaches are not incorrect, as in the Relating paradigm where one moves from implicit documentation of semantics to explicit documentation of semantics, one must formally document the implications and expectations of behavior. The machine-leverageable documentation of behavioral interactions within an architecture becomes particularly important in the modification and extension phases of distributed mission-critical programs such as Command and Control systems, and distributed sensors and Combat Systems.
The ability to deterministically and algorithmically compose or orchestrate both semantics and behavior among many diverse systems enables new and interesting ways to integrate and deploy software capabilities.
Integration Paradigms & Existing Maturity Models
Figure 1 relates the Integration Paradigms discussed in this paper to the Levels of Conceptual Interoperability and Interface Documentation Maturity Levels (IDML) (Hand, Lombardi, Hunt, & Allport) as further explored in Achieving Warfighting Lethality via System and Semantic System-of-Systems Model-Based Engineering Integration published by the American Society of Naval Engineers (ASNE) in April 2021.
Conclusion
As the number of points of connectivity and the complexity of that connectivity increases, traditional integration methods require ever-increasing numbers of software developers, engineers, and architects to keep critical systems glued together. With each integration, countless assumptions are made about the concept of operations for that system. As new missions, platforms or data are introduced, reintegration becomes necessary. Current approaches to integration yield inflexible, brittle solutions.
When an enemy adapts, the US needs the ability to get new tools, new sensors, and new capabilities into the hands of warfighters as quickly as possible. Defense programs do not always have the luxury of time and resources required for a full tech refresh or to bring down a full battle group for an update.
Programs must adopt new methods capable of more rapidly adapting existing systems to meet changing mission requirements and streamlining the introduction of new capabilities into pertinent systems. Transposing traditional methodologies into digital workflows, models and even automating lifecycle processes such as testing is critical but insufficient.
In addition to these advances, one must begin to think about interoperability and its role in the systems development lifecycle differently. Integration efforts must be in involved early in the cycle, working, beyond syntax, to explicitly define the semantic relationships and the behavioral composition in the design of the architecture. In this manner, integration and even infrastructure become automatable, adaptable and scalable, increasing warfighting value far into the future.
REFERENCES
DoD CIO. (2019). DoD Enterprise DevSecOps Reference Design. Washington, DC: Department of Defense.
Hand, S., Lombardi, D., Hunt, G., & Allport, C. (2018). Interface Documentation Maturity Levels (IDML): An Introduction. Open Group FACE™ / U.S. Army Technical Interchange Meeting. Huntsville, AL.
Tolk, A. (2004). “Composable Mission Spaces and M&S Repositories - Applicability of Open Standards". 2004 Spring Simulation Interoperability Workshop. Washington, DC.
This article includes extracts and adaptations from “Achieving Warfighting Lethality via System and Semantic System-of-Systems Model-Based Engineering Integration” as published and copyrighted by the American Society of Naval Engineers (ASNE) April 2021 and authored by Gordon Hunt, Shaun Foley, Chris Allport and Sonya Hand, Skayl.
Read the full whitepaper here