In the SEI's examination of the software sustainment phase of the Department of Defense (DoD) acquisition lifecycle, we have noted that the best descriptor for sustainment efforts for software is "continuous engineering." Typically, during this phase, the hardware elements are repaired or have some structural modifications to carry new weapons or sensors. Software, on the other hand, continues to evolve in response to new security threats, new safety approaches, or new functionality provided within the system of systems. In this blog post, I will examine the intersection of three themes--product line practices, software sustainment, and public-private partnerships--that emerged during our work with one government program. I will also highlight some issues we have uncovered that deserve further discussion and research.

Software Product Line Practices

Long before our work on this program, the SEI began to focus on the concept of software product lines, which are a proven way to develop and manage software components more efficiently and at significant cost savings to the producer and its customers, who are often diverse customers that receive similar products from a common core software collection.

While the concept of software product lines has been used effectively in a number of commercial domains, the government acquisition environment presents unique challenges. Successful product lines are often long lived, and some of the systems created from the product-line approach will have entered the sustainment phase. Here the amount of software evolution may be more limited than during full-scale development, but it is likely to be more influenced by real operators at their work stations who want improved utility for their mission.

Meanwhile, other, newer systems may still be in the design phase, working through the mission threads that guide selection of architectural approaches that best support the key quality attributes for their unique functional approaches.

In government settings, managing a product line is harder because each system is typically considered unique in the acquisition universe. The government is obliged to pursue full and open competition for its purchases and avoid sole-source procurements whenever possible. Government acquisition professionals thus worry about "vendor lock" that limits healthy competition for military-specific needs, like stealth fighters or ballistic missile submarines.

Our research efforts in effective product-line architectures and open-system architectures include years of investigation into how software systems can be created to maximize the value of reusing the majority of system elements--a core with new elements to address similar functionality in different hardware packages. These software components typically fit within weapon systems or other hardware with very different operating modes.

For example, a command-and-control system for a surface ship would likely share many capabilities needed for a submarine. Command and control of the unique aspects of submarine operation, such as diving and surfacing, would require that some software systems not be shared across the product line. From a software component perspective, many computer software configuration items (CSCIs) would be identical across the product line. Some CSCIs might be modestly modified; a few might be unique to the specific weapon system under development.

Software Sustainment

Over the years, the SEI has worked closely with government organizations dedicated to the continuous evolution of the software content of various military systems. Long-standing laws require government owned-and-operated sites to assure the continued readiness of our weapon systems after their development by a contractor. Software sustainment was initially viewed as limited to fixing errors with small patches, but the need for greater capability has grown, including major revisions in software design. Consequently, engineers have rethought the idea of conventional software maintenance. Today, they have evolved toward the process as continuous engineering, which lies at the intersection of fixing problems and providing new capabilities made possible by new hardware or new threats that demand new functionality. In this environment, software sustainment needed to become a well-developed capability in the government's software development centers.

Public-Private Partnerships

Various laws governing the DoD's acquisition of weapon systems recognize that many systems must be maintained long after production. The company that built the system may go out of business or move on to different products. U.S. Code 2464 directs government-owned sites to acquire (called "organic," since they are within government rather than "commercial" or contractor sites) needed competencies to preserve wartime capabilities for core systems. These systems are identified early in the acquisition cycle. Over time, Congress added the option for public-private partnerships (PPP) on government sites to expand sustainment capabilities beyond the limits of government hiring. This option provided needed competencies, processes, and equipment and enabled the prime contractor for a system to establish its presence on a government-operated site.

Program Planning for Transition into Sustainment

The SEI brought three themes together when we helped an acquisition organization analyze the software issues of an ACAT I program as it began a product support business case analysis (PS BCA). We were particularly interested in this case because the systems were developed by a single contractor using product-line strategies for both software and hardware. In fact, the initial products in the product line were successfully deployed and in operation. Based on this success, the government is acquiring variants of the system from that contractor.

The variants were developed by a single contractor using a product-line architecture. This approach enabled the contractor to lower the cost and schedule by using common software across the programs. But since the programs were funded separately, the sustainment planning for each was initially approached separately. However, continuing the product line as a whole into sustainment offers the government many advantages. Working through the options was the task of a team assigned to develop courses of action (COAs) that would highlight the alternatives and recommend the team's preferred option. The ultimate decision would be made by senior leadership in the program offices represented.

Early on, the PS BCA team lead gathered the government's product-support leadership. These leaders represented the new acquisition programs that were part of the contractor's product-line suite. The programs were scheduled to transition to sustainment at about the same time (from 2020 to 2022). The SEI helped the leadership team on matters of software engineering and acquisition. These activities made a single PS BCA effort possible. The three program leaders agreed that sustainment upgrades could be managed more efficiently if all three programs were considered as part of a product line. In this way, a single change could be easily offered to each program for integration after initial development. But would the initial development be performed by the organic sustainment unit or by the original contractor? This choice would be evaluated as part of the PS BCA. Each alternative was described as a distinct COA.

The PS BCA report analyzed the transition from development to sustainment in the lifecycle from three perspectives:

• benefits to the DoD
• risks of the strategy
• a 20-year cost estimation for the approach

There were three fundamental COAs to examine: the contractor unit alone, the designated organic (government) software unit alone, or some mix of organic and contractor software engineers. The best approach for a mix is a public-private partnership (PPP), as mentioned above.

To consider the risks and benefits of the COAs, 14 reviewers used Likert scale or risk radar scoring against a variety of potential outcomes. The aggregate answer favored the PPP over either contactor only or organic only software alternatives. Not surprising was that the PPP COA scored highest in "providing the most effective balance between organic and contractor support." More significantly, the experts viewed the PPP as more likely to be more responsive, and therefore more likely to ensure greater system availability. The experts also deemed the PPP was more flexible and efficient than contractor-provided logistics support. The experts viewed the PPP as easier to implement than a transition to pure organic support.

The final decision must also include cost analysis. On this point, the product-line approach also showed its strength. Earlier work by product-line experts at the SEI found that a product-line solution the break-even point is reached at only two systems. A product-line approach thus has immediate payoff for the systems under direct consideration. For product-line changes to any additional system added, that program would logically pay its portion of the changes, with our customer supporting the remainder, thereby realizing more savings. Consequently, this PPP offers the opportunity for the contactor to expand the product line to other DoD services and other government agencies.

The PPP strategy couples nicely with the product-line approach. The shared functionality across the collection of programs that the contractor has mastered suggests maintaining that expertise in the sustainment phase. The customer-facing aspects, unique to the various programs with different user communities, gives the organic software team the opportunity to do what it does best--ongoing and effective communication and support to the warfighter who is geographically close and familiar with the organic team from predecessor systems.

While the PS BCA analysis has been completed, the program leadership of the three acquisition programs have not yet seen the analysis or used it to choose among the alternatives. The potential selection of the PPP alternative, however, creates some interesting future possibilities.

Looking Ahead

Could the government assume full responsibility for the product line at some point? This question is not easily answered today, but it merits study as the transition goes on. Moreover, the learning curve for a system of this complexity is long and requires support from the contractor's product-line experts. While individual transition plans typically span a few years, the company has estimated that expertise across the product line would likely take about 10 years to develop. It is an open question whether transition of product-line ownership is related to concepts like "owning the technical baseline," or how it best fits in the sense of government ownership of long-term sustainment efforts for software reliant systems built on a software product line.

Additional Resources

For other blogs in this series, please visit

/blog/toward-efficient-and-effective-software-sustainment/

Learn more about the SEI's work in product line practices.