Today's major defense systems rely heavily on software-enabled capabilities. However, many defense programs acquiring new systems first determine the physical items to develop, assuming the contractors for those items will provide all needed software for the capability. But software by its nature spans physical items: it provides the inter-system communications that have a direct influence on most capabilities, and thus must be architected intelligently, especially when pieces are built by different contractors. If this architecture step is not done properly, a software-reliant project can be set up to fail from the first architectural decision.

Example: The Global Positioning System (GPS)) was divided into ground, user, and satellite segments, and the government issued different contracts for each segment. Many interaction and schedule problems resulted, partly because the segments had different schedules. For example: a satellite was due to launch with new software, so the existing ground segment software was not designed to work with it, but the new ground segment software was not complete.

If, instead, system acquirers ensure that systems engineers address software concerns at the same time as the physical solution is conceptualized, acquirers can opt for a slightly different physical system, whose software architecture is tuned to optimize the provided capabilities.

Acquisition of Defense Systems

The 2018 National Defense Strategy proposed a set of challenges needing solutions. Challenges like a "complex and volatile security environment" and a call for a "more lethal, resilient, and rapidly innovating Joint Force, combined with a robust constellation of allies and partners" can be addressed only by a complex combination of capabilities created from a large number of individual systems.

To start creating capabilities, the Department of Defense (DoD) identifies specific capability gaps and creates an Initial Capabilities Document (ICD) that describes why non-materiel changes alone have been inadequate. Subsequent DoD analysis leads to one or more Capabilities Development Documents (CDDs). A CDD describes requirements for an acquirable system that will provide a specified contribution to the system-of-systems (SoS) capability. The acquirable system's requirements describe "a militarily useful increment of capability" that is feasible to contract out for delivery.

Commandment 4 of the Defense Innovation Board's Ten Commandments of Software (Adopt a DevOps culture for software systems) notes that "Software is never 'finished' but must be constantly updated to maintain capability, address ongoing security issues and potentially add or increase performance." For this reason, the evolvability of software has become a large part of the sustainability of a system. If the software architecture is not modifiable, the system as a whole may not be sustainable.

Figure 1 shows an identified problem leading to a notional solution architecture.

Figure 1. Earliest system engineering converts the problem to the notional solution architecture.

Today's complex capability needs lead to complex capability requirements that can often only be provided by a system of systems. To create the SoS, the program must identify a set of constituent systems that together provide the needed capability and individually are small enough that a single contractor can build each one. Early government analyses (including analysis of alternatives (AoA), performance analysis, and individual technical analyses such as pointing analyses) determine which set of smaller systems will provide an SoS capability that will meet the need. Because SoSs evolve with every added or modified system, the initial system might only provide some of the desired capabilities, but capability deficits can be addressed with subsequent acquisitions.

Historical Division of Contracts along Physical Lines

It is easy to imagine that the SoS creation process outlined above would lead to a separation of contractor responsibilities along the lines of physical systems. A satellite might be built by one contractor, the ground system by another, and user handheld equipment by a third. Back when the interfaces among these systems, such as analog radio channels, were fairly simple and well understood, the desired capabilities existed primarily within the systems contracted out to single contractors. Communication between the systems was fairly easily defined.

In our satellite example, the government could have sought contractors to build each of the three systems and assumed that they would include everything needed to make the systems work, including inter-system communications. This thinking aligns with the 1960-1980 version of satellites that assumed software existed internal to a system, which is described in a previous blog post. In contrast, more recent thinking acknowledges that software drives communication and control paths among all the different physical pieces of a system, making its role in providing SoS capability more critical.

Problems with Separating Along Physical Lines

Especially today, breaking contracts along strictly physical lines is a recipe for integration problems. Software architectures determine software quality attributes. The quality attributes of SoSs are likewise determined to a large degree by the software architecture of the constituent systems and their compatibility with each other. Making a small decision on a simple system can seem minor, but if it breaks the compatibility with other systems, there can be big problems at the SoS level. Today's decisions influence tomorrow's software modifiability, and thus tomorrow's sustainment cost.

In today's software-intensive systems, the software architecture also greatly influences system quality attributes, even when no such connection is apparent to the system designers. This connection is one reason designers must pay attention to the relationship of the needed software to the system-level decomposition: the decomposition creates a structure that constrains the software architecture, which, in turn, affects the system's quality attributes. If the software architecture is incorrectly constrained by the system-level decomposition to physical pieces, this constraint can reduce the functionality that the software provides.

Strong Software-Software Communication Today

With the ubiquity of digital data that has developed in the last decade, communication among systems is a strong contributor to the rapidly expanding capabilities of systems of systems. Today, much more information is communicated from system to system, in many different formats and along different paths, with different critical constraints including timing, privacy, and security. Determination of system and sensor status and sending of commands that achieve control require communication, which is thus a prime contributor to system quality attributes such as quality, safety, and security.

Figure 2 highlights the software that allows the communication to occur, relative to the notional solution architecture. This drawing also shows communication to entities external to the system, such as existing legacy systems and stakeholders, and other systems that may be created in the future. Leaving the requirements for all these kinds of software undetermined often makes the integration and realization of future capability more difficult.

Figure 2. Software provides capability for internal and external communication.

Decisions Needing Software Architects

Rather than focusing on the physical items and ignoring the communication paths, it is now more important than ever that government analysts consider the tradeoffs involved when cutting a system into acquirable pieces. Early systems engineering teams must include people with the background knowledge and the expertise to identify problems that will need further study before tradeoffs can be finalized.

Example: Consider an unmanned aerial vehicle system (a drone, or remotely piloted aircraft) in a battle theater. This drone takes photographs and sends the data back to tactical decision makers. What kind of security should this drone system have? Should the data be encrypted? If so, how will the military have to staff the battle areas to ensure cryptographically qualified workers are available? Should data be processed on the aircraft, leading to heavier aircraft with lower communication bandwidth, or should it be sent raw, with the opposite effects?

Such questions arise in today's SoSs when acquirers are determining the initial capabilities to develop. Without the expertise of systems architects on the government team, the implications of all these decisions to the system architecture--including software cost--are unclear. The initial system's impact is unclear, but even more unclear is the manner in which these decisions will affect later versions of the evolving SoS.

Another integration issue that occurs in complex SoSs is that holders of the various contracts make different assumptions about the software and data. If one contractor has defined 1/360th of a year as a day in their sensor calculations, but this is unclear to an engineer developing the sensor processing algorithm, then the software will produce wrong results. If each contributor to a massive calculation does a Fourier transform from time to frequency or vice-versa, the software may not meet its required timing. Software architects must be aware of the assumptions and of the effect that incorrect assumptions may have on the results. Software architects should define known assumptions and specify how future conflicts in assumptions should be resolved.

Balancing Is a Systems Engineering Job

The Defense Acquisition University's Joint Capabilities Integration and Development System (JCIDS) Primer defines the requirements environment as finding the balance between near-term and long-range requirements, system versatility and optimization, growing demands and fiscal constraints, ambition and achievability, and quantity and quality. Such balancing is part of the defense systems engineering discipline. System engineers ask and attempt to answer questions such as the following:

• Should the individual systems be more powerful at the cost of slower communication, which would delay the signal across the SoS?
• Would the security issues created by transmitting raw data, rather than processed and encrypted data, overwhelm the advantages of having all the processing done on the ground as opposed to in the air or in-orbit?
• Would building a partial system quickly get more needed capability to the field than a slower system with integrated capability?

To answer these questions, the systems engineering team must have a clear idea of the system and software architectural challenges and of modern ways to address such challenges. Such considerations demand either that a software architect with considerable experience in the domain be part of all such early systems engineering teams or that the systems engineers have significant strength in software architecture. The latter is problematic: systems engineers must excel in a broad set of engineering topics and understand the operational domain, while software architects must understand very detailed aspects about software and keep continuously up to date. It is difficult for any one person to master all this information, and the two aspects may be generally suited to different kinds of people: a systems engineer's job is easier if they like interacting with the many people who are needed to provide the broad system overview (For more on this see Development of Systems Engineering Expertise by James R. Armstrong), while software engineers often need to think through a number of complex concepts during a quiet time with a closed door. It is usually best to add a capable, experienced software architect to the systems engineering team.

Systems Engineers Use Trade Studies to Ensure Balance

To achieve this necessary balance across disciplines and over the lifecycle, with recent emphasis on ensuring evolvability due to recognition of high sustainment costs [see here and here], systems engineers perform trade studies. Early trade studies look at multiple ways of meeting the highest-level customer need. During these trades, systems engineers--including those in the acquirer organization--identify a number of options (i.e., architectures) for breaking an early system concept into pieces that are small enough for individual contractors to develop.

Because software fulfills more system capability today than in previous decades, because system solutions tend to be SoSs, and because evolvability is an increasingly important quality attribute, today's systems engineers working in the earliest phases should pay special attention to potential integration issues. They must look at multiple options and conduct trade studies documenting how well each option meets the various success criteria.

Software architects must also be available to look at each potential solution and identify its likelihood of meeting software quality attributes. These architects should be skilled in understanding the implications of various architectures on different kinds of performance. They should also be willing to estimate relative risk across the options given as well as recommend architectural tweaks that could improve the score of any particular option.

The DoD has tried a number of ways to get systems engineers to learn enough about software to make such decisions, including education and experience. However, software is so deep and dynamic that it is difficult to remain knowledgeable about it while also maintaining the broad knowledge systems engineers need.

Hardware engineers will also be expected to provide estimates and implications for each option: estimating cost, schedule, performance, and risk. But both systems engineers and hardware engineers have been included in early efforts for a number of decades, whereas trade-study activities that include software engineers and architects are less common. For example, a 2004 document showed the Navy's mature process at that time for creating trade study data and presenting it to decision makers. The document specifically mentions utility curves as showing how well different options meet the trade study criteria. The word software is not found in the document, thus only the systems engineers considered it relevant.

Solution: Include Software Architects in Early Systems Engineering Efforts

Figure 3 shows how the early design process could look with early involvement of software architects. When trade studies are performed, the software architect helps to identify constraints, risks, performance issues, cost issues, and schedule issues that relate to the software-enabled capabilities of the SoS.

Figure 3. Early Design Process

To make effective use of the software architect on the team, the system engineer should ask the following questions. This paper featuring this list was presented at the 29th Annual INCOSE International Symposium. The answers will be folded into system trade studies.

• What major software architectural decisions are going to be needed? What impact will the various options have at the system level?
• What decisions must be made to ensure that software is not unreasonably constrained, so developers will be able to create the software economically, and it will serve the operational needs correctly, including adaptation, reconfiguration, and graceful degradation?
• What approaches reduce risk of cyberattack, and how might they change?
• What makes development difficult? Would some options be easier to develop than others?
• What software risks could become system risks?
• Will this change be a small change? Or might it become a huge problem?

Not every software engineer will provide the right skills to the systems engineering team. Many programmers will wait until a detailed specification is presented to them to start work. Software engineers may not look for future compatibility and tradeoffs. Generally, good software architects are good systems engineers of software, who may lack knowledge about and experience with non-software pieces of systems. The goal is to include software architects who can reason about the software as a whole in the early stages, are familiar with the domain, and are keeping up as software and cybersecurity best practices evolve.

Looking Ahead

In today's systems, which are often implemented as components of SoSs, it is critical that we recognize the importance of software to provide the necessary capabilities to the customer and user. Splitting the system along physical lines makes software engineering difficult, introduces many risks, and endangers cost, schedule, and system performance goals.

Today and into the future the best way to ensure that a new system's software architecture supports needed capabilities and also system evolvability is to involve software-knowledgeable personnel--specifically software architects--in the early system decisions about breaking up a system into acquirable parts. At this early stage, many software problems are either caused or avoided, and software architects are needed to ensure the latter.

Additional Resources

Read other blog posts by Sarah Sheard.