When Worlds Collide

Why do companies, teams, or the U.S. Government need to align software and systems engineering efforts? Before we answer that question, we need to understand the current state of each profession and the market in which they operate. Software and systems engineers exist in unique and somewhat conflicting domains that must intersect, and that need for collaboration is a growing concern across the DoD.  

Currently, software delivers the majority of defense-related capabilities. For example, the F-35 performs missions such as Close Air Support through advanced avionics software, making it less vulnerable to ground-based threats. Even if software doesn�t directly offer the capability, it likely supports it peripherally.  As data analytics, artificial intelligence, and reliance on autonomous systems become more prevalent, the amount and complexity of required software support will only increase. Software engineers use modern methods and capabilities to build, test, deploy, and modify software, but requirements for software engineers rapidly change.  As such, software engineers focus on releasing working code and making adjustments as needed.

Systems engineers working in the same space think and act very differently.  In the early 1990s, systems engineers focused on integrating complex, joint, or multi-national systems. The Clinger-Cohen Act and the subsequent push for interoperability resulted in the DoD Architecture Framework (DoDAF) to manage these complex systems (originally termed C4ISR Architecture Framework). Since then, systems engineers have focused on defining integrated system architectures that define requirements with traces to system functionality and system form.  Empirical data shows that about 10-15% of a project budget should be spent on systems engineering early in the project lifecycle to maintain costs and schedules. Systems engineers focus on early planning to avoid costly mistakes later in development, integration, fielding, and operations.

Systems engineers think about why a project exists and how it has to work.  They must think strategically when defining a system architecture, considering the development lifecycle and factors influencing the design. Software engineers are concerned with what a project does. They tend to be more pragmatic and focused on performance because software is very complex to manage, develop, and implement. Often, laying out the software architecture is an afterthought compared to the system architecture. As a result, a disconnect manifests between the foundational system architecture and operational software when the two need to be connected. 

As a systems engineer with significant experience in Model-Based Systems Engineering (MBSE), I believe a model-based approach tying systems engineering to software development potentially closes the gap. In 1997, the Object Management Group (OMG) adopted the Unified Modeling Language (UML) to model object-oriented software's behavior, interactions, and structure with limited success. The systems engineering community embraces MBSE to a greater extent with varying levels of success. Challenges remain in the systems engineering community with the adoption of MBSE, but its adoption is growing. The systems engineering community uses UML and the Systems Modeling Language (SysML) to capture requirements, behavior, structure, and parametric models of complex systems. Where DoDAF fell short of modeling the integration of complex systems, SysML demands the integration of system function and form, with a clear definition of a system boundary and interfaces among components that comprise a system. SysML provides a more efficient understanding of a system�s complexity than the traditional document-based approach to systems engineering.  I do not know if the software community will adopt a model-based approach to software development and integration the way systems engineers have adopted it to their domain. However, I believe there are aspects to software integration where a model-based approach can help close the gap between software and systems engineering.

As more software applications turn to cloud-native architectures and microservices, there is an opportunity to apply model-based approaches to the complicated and tedious job of software integration. A model-based approach to software integration can automate time-consuming details like message definition among software applications or components, transport layer definitions, serialization and deserialization of messages, run and build verification, and containerization. Should software applications adhere to different messaging and architecture standards, the transformation from one standard to another can also be automated with assurance using a model-based approach. This enables wider adoption of open standards and different standards to co-exist by streamlining integration.

Model-based software integration lays the groundwork for bringing software and systems engineers together. A modeling environment for software integration allows software engineers to consider the bigger picture similarly to their systems engineering counterparts. A software integration modeling environment enables the software engineer to manage the complexity of a system predominantly composed of software applications talking to one another, reduce the ambiguity across such a  complicated system, integrate innovative technology, and reuse software components where feasible. This approach alleviates the burden of tedious and complex software integration, where issues are typically uncovered much later in the development cycle.  A modeling environment such as this helps software engineers to think like and appreciate the challenges systems engineers face in developing complex systems but also provides a venue where systems engineers can relate to software engineers.     

An environment where software and systems engineers model and communicate must have a defined intersection between the two domains. Systems engineers need to start thinking like software engineers and vice versa. System requirements and mission models need to link to software integration models.  For this to occur, there needs to be formal semantics applied to SysML requirements so they trace back to software integration models. Additionally, SysML internal block diagrams, state machines, and sequence diagrams are promising points of collaboration between software and systems engineering.  Engineers at Tangram Flex are looking into extending the SysML standard for these views to bridge the gap between software engineering and systems engineering.

A model-based approach to software integration tied to an MBSE system architecture offers several benefits to the DoD.  First, it will shorten the schedule to develop, test, and implement new systems or software components integrated into existing systems. This model-based approach will reduce the cost of new software as the schedule shrinks and new code automatically integrates via tooling rather than a manual process. This allows capabilities to be integrated across the DoD with fewer resources and at the speed of necessity, overwhelming our adversaries with strength and agility.  

If software engineers and systems engineers can't find the means to collaborate, the DoD will suffer. We will lose talented engineers to markets that do not demand as much interaction between the two domains, in markets where the systems engineer's role is diminished. The cost of fielding software is reaching a breaking point, and it is getting too expensive to bring new technology to fruition. The complex nature of software integration drives up these costs. Tangram Flex understands these challenges. Stay tuned for capabilities that turn these concepts into reality.