In the world of space acquisitions, agility is a best practice. This is because software development and sustainment no longer follow the norms of the previous century. Repeatedly, the DoD has struggled with fielding software intensive programs in a timely fashion and within a reasonable cost.

One Space and Missile Systems Center program, the Joint Space Operational Center Mission System (JMS), was no exception. Plagued with cost and schedule breaches that led to a critical change in the program in 2016, followed by an Office of the Director, Operational Test & Evaluation (OT&E) report in 2018 that declared the system, “…not operationally effective or suitable for its space awareness mission…” it became apparent that something had to change with how the software was being procured.

“With the pivot to space as a warfighting domain, we recognized the JMS structure wasn’t adequate, and buckled-down and thought about ways we could make the program better in its acquisition process strategy moving forward,” said Col. Stephen Purdy, Director of Space Superiority Systems Directorate.

Some members of the SMC/SY “Kobayashi Maru” Space C2 team help delivered capabilities to the warfighter through rapid acquisition methods to help “protect and defend” U.S. space missions. Photo is courtesy of SMC.

JMS was created to provide space services to enhance the accuracy, sustainability, and responsiveness of space surveillance capabilities as well as a high accuracy space catalog (knowledge of space objects), increased observation verification and capabilities, and improved event processing. However…

In August 2018, two major shifts occurred with the JMS program. First, it was combined with Enterprise Space Battle Management Command and Control (ESBMC2) to focus on providing capabilities for Space Command and Control (C2). Space C2 provides a common, integrated baseline that incorporates capabilities across the domain that enable space warfighters to accomplish their “protect and defend” and theater support missions with an effective end-to-end kill chain.

Subsequently, Space C2 shifted from “waterfall” software builds to agile practices. The waterfall model is a relatively linear sequential design approach for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (“downwards” like a waterfall).

On the other hand, in agile software development, requirements and solutions evolve through collaboration. It promotes adaptive planning, evolutionary development, early delivery and continuous improvement, and it encourages rapid and flexible response to change. Space C2 is doing just that.

“The pivot has been incredible,” said Purdy. “Since the decision was made to go Agile Software, we have completed three rounds of our agile requirements process, completed our second 90-day Program Increment, which delivered capability, and already started our third Program Increment that will deliver more capability in another 90 days. This is how software should be done.”

The DoD 5000 life-cycle process provides a detailed DoD process for setting requirements for complex systems and ensuring delivered systems are compliant with those requirements. DoD 5000 is designed to give Office of the Secretary of Defense, the Service Acquisition Executives, and Congress some level of visibility and oversight into the development, acquisition and sustainment of large weapons systems. Traditionally, software acquisition – with JMS being a prime example – has been shoehorned into this framework with minimal to no success. This framework is largely based on a 1970’s “waterfall” process.   As a result, the software for acquisition was found to be late to need, cost substantially more than originally estimated, could not be easily maintained, and had low acceptance rates by the users.  This often led to software scrap, rework, and repair.

By contrast, current software methods found throughout industry use a much more iterative process, often referred to as “DevOps” or “Agile Software.” Development and operations are continuous efforts that feed off of each other, as shown on the right.

“As the Defense Innovation Board has pointed out in their Do’s and Don’ts for Software, moving to a software development approach will enable the DoD to move from a ‘specify-develop-acquire-sustain’ mentality to a more ‘modern-useful-create-scale-optimize’ mentality also known as DevOps/DevSecOps. Enabling rapid iteration will create a system in which the U.S. can update software at least as fast as our adversaries can change tactics, allowing us to get inside their OODA loop,” said Purdy.