Agile Software Acquisition Brings Continuous Relevance to DoD
November 2, 2020 | Words by Marc Phillips
Somebody go wake up William Gibson. DoD Instruction 500.87 is about to distribute the future a lot more evenly. Released on October 2nd, 2020, Operation of the Software Acquisition Pathway prescribes a transformative approach for accelerating the delivery of effective, resilient, supportable, and affordable software-driven capabilities throughout the Department of Defense. Following these principles will ensure a decisive and sustainable U.S. advantage in an increasingly complex world.
First, this directive calls for the DoD to harness U.S. technological innovation for executing the national defense strategy. Identify promising teams and technologies today. Foster programs and funding for tomorrow. Second, create a culture of performance where outcomes are emphasized over activity. Don’t just think and talk. Do. Deliver. Digitize. Create a vibrant pipeline for the efficient acquisition, development, and continuous deployment of secure and effective software solutions. This transformation cannot wait.
These concepts are not new. In fact, most are common private sector practices today. However, by bringing these principles into the DoD software acquisition pipeline, the stage is set for closing the gap between the fantastic pace of commercial technology innovation and the legacy software acquisition process in the federal space.
Demand modern solutions for modern problems
“Policy: Programs will require government and contractor software teams to use modern iterative software development methodologies, modern tools and techniques (DevSecOps), and human-centered design processes to iteratively deliver software to meet the users’ priority needs.”
The art of the possible is defined by the tools at hand. What was impossible only a few years ago is standard today – modern capabilities created by modern tools. The opposite goes without saying - legacy tools produce legacy results. However, we must keep in mind that modern tools only increase what is possible, not what is probable. They expand potential, not prowess.
Modern tools must be wielded with modern techniques to produce modern results. Therefore, it is the software practice, or more accurately the software practitioner, that defines the new upper boundary of system performance and creates the ultimate advantage. In effect, the DoD strategy for achieving modern results is to select modern teams. Choose forward-thinking vendors for new projects rather than traditional vendors with traditional operating practices. Everything is changing. True, the traditional approach got us all the way here, but it won’t get us where we need to go next.
Serve those who serve
While the instruction sets a pathway for selecting the right humans, it goes on with guidelines for ensuring each acquisition addresses the needs of the humans it is designed to serve. Human-centered design starts with the user “at the glass,” the people dependent on the system for achieving their mission objectives. Architecture decisions and technology choices must serve the goals of each end user and deliver an experience informed by real world operating context. A “technically capable” system that cannot be put to productive use by operators is not a capable system at all. While users don’t have to “fall in love” with the experience (this isn’t the open market after all), the application must actively facilitate their ability to execute their duties both efficiently and effectively under foreseeable circumstances.
“Policy: A rapid, iterative approach to software development reduces costs, technological obsolescence, and acquisition risk. To allocate resources to the most relevant capability needs, DoD or DoD component leadership will make software acquisition and development investment decisions within a framework that addresses tradeoffs between capabilities, affordability, risk tolerance, and other considerations.”
In short, move away from waterfall and toward an agile mindset. Consider. Implement. Learn. Adapt. Repeat. Bring the principles of the OODA Loop to shorten time to value and reduce risk. Observe, orient, decide, act. The future will be controlled not by the biggest force, but by the most consistently relevant. New technology creates new possibilities, but human thoughts and actions are what will extend and maintain our strategic advantage.
What gets measured, gets done
“Policy: Engaged engineering teams are instructed to “instrument software such that critical monitoring functions related to health, security, and operational effectiveness of the software can be automated to the maximum extent practicable.”
The fact that this must be written out as explicit policy speaks to the challenges faced by acquisition officers today. Application instrumentation has been a basic ingredient of private sector software for well over a decade, providing a constant stream of data about system performance, data integrity, and user behavior. It goes without saying that monitoring and analytics require automation both for real-time response and learning to enable iterative improvements over time.
Prioritize, maximize, assess
“Policy: Software development will be done in active collaboration with end users, representing key user groups, to ensure software deliveries address their priority needs, maximize mission impact, and undergo regular assessment of software performance and risk.”
A thousand times yes. This is why we’re here. This is why we build software. To accelerate mission objectives. To enable superior individual and team performance. So, get to know the user, understand their priorities, and keep a close watch on whether they’re becoming more effective through the system delivered iteratively over time. What’s the point of doing anything else?
NIH Syndrome and the Curse of YAGNI
“Policy: Leveraging existing enterprise services, if available, is preferred over creating unique software services for individual programs. These may be procured from the DoD, the DoD components, other government agencies, or commercial providers, and leverage category management solutions and enterprise software agreements.”
Just like medical doctors pledge to “do no harm” in their role as professional healers, software development professionals dedicated to their craft commit to “leverage and integrate” over “build and replace.” Agencies and operators need secure, performant, and relevant capabilities. Maximize both budgetary and scheduling resources to deploy new features, faster. Every project should begin with a search for existing giants with shoulders to stand upon. All that matters is whether or not you can see farther and more clearly than your adversary, not how you got up there.
Furthermore, do not speculate about what else users will need in the future. The world is changing too quickly. If users aren’t calling for it today, don’t build it. You Aren’t Gonna Need It. What you will need is an architecture designed for maximize agility. Fix known problems today, quickly pivot to new problems tomorrow. Design for learning. Every bit of functionality provided by existing enterprise services is functionality that you don’t have to worry about. Budgets are limited. Time is limited. Existing services will continue to evolve and improve as well – at a far greater pace than your team could ever keep up with. Force multiply.
Never trust, always verify
“Policy: The chosen software development methodology will incorporate continuous testing and evaluation, resiliency, and cybersecurity, with maximum possible automation, as persistent requirements and include a risk-based lifecycle management approach to address software vulnerabilities, supply chain and development environment risk, and intelligence threats throughout the entire lifecycle.”
To be blunt, go DevSecOps or go home. Real-time scanning for verifying compliance of code and containers must become the norm. Continuous Authority to Operate (cATO) should always be the goal. We won’t always get all the way there (at least not for a while). However, we’re still reducing the time required to go from updating code in the cloud to unleashing new, verified system capabilities - even when that system is air-gapped or embedded inside hardware at the edge. This instruction sets a path for us to iterate and win.
Execute the mission
Let’s face it. None of these ideas are new. In fact, you could summarize the product development approach of every successful private sector technology company of the last two decades with the same words now used by the DoD. This directive to “rapidly and iteratively design, develop, integrate, test, deliver, and operate resilient and reliable software capabilities that meet the users’ priority needs” is simply an overdue (though quite welcome) acknowledgement of the mismatch between traditional acquisition strategy and the current acquisition imperative. DoD leaders have observed, oriented, and decided on a new course of action for achieving continuous relevance.
It’s time for us to act.
