The book “The Bomber Mafia” revolves around the efforts of military officers to develop effective tactics for a bomber force, emphasizing the feedback cycles between operational results and new bombsight and aircraft development. This storyline is timeless: Major military advances like the Blitzkrieg tactics credited with Germany’s rapid gains at the opening of World War II are largely about pioneering new tactics enabled by emerging technology — at that time, aircraft, radios, and armor. While the ability of the U.S. military and its industrial base to bend metal and push the bounds of physics with aircraft design has slowed dramatically as technology and bureaucratic processes have matured, there still lies ahead a bold frontier of new innovation.
Currently, military-technical competitive advantage is driven more by software, data, and artificial intelligence and the new tactics they enable than by bent metal and physics. This is apparent across different military contingencies, from scrappy improvised battle networks in Ukraine to plans for future fighter aircraft that will team with a mix of humans and unmanned systems. New analytics tools and processing algorithms can make nearly real-time sense of data from thousands of sensors scattered across domains. Automated control systems manage vehicle guidance, sensor tasking, and occasionally introduce unexpected failure modes. Planning tools allow operators to innovate on new force packages and tactics and to replay and rehearse scenarios hundreds of times. Software is the glue that binds our military professionals and systems together, and increasingly the loop between development and operations is defined by digital data.
Acquisition leaders can, therefore, deliver results and create a vibrant environment of learning and improvement by following six principles that offer guidance on how to set up infrastructure permitting code to change quickly and securely, how to divvy up complex software efforts into manageable chunks that can still interoperate, and how to embed digital talent, user feedback, and security practices into a project.
The Department of Defense’s acquisition community has been thrown into a turbulent sea of software buzzwords and technological change that does not conform to current bureaucratic processes, industrial base momentum, and external pressures. Indeed, there are important efforts to recognize the need for acquisition authorities to reprioritize how money is spent before the annual budget is passed, new software acquisition frameworks, and even an experimental color of money designed to accommodate the fact that code can shuffle between development and operations several times in a day.
While new tools will be helpful, the acquisition community also recognizes the promise of software for military advantage and can scrape together enough tools and authorities to deliver on this promise today. What would be most useful would be a simple set of principles that can cut through the complexity of choices that program executive officers and program managers face. We’ve recently written a report designed to pick up where the Defense Innovation Board’s seminal Software is Never Done study left off.
In particular, our report found that there is no one-size-fits-all best practice for software acquisition. Every effort is different: Much like logistics professionals orchestrate handoffs between ships, planes, and trucks to deliver goods on time, acquisition professionals must learn to orchestrate between web applications, embedded systems, and middleware systems. They must mix and match between software-as-a-service, source code delivery, and exposed interfaces in order to deliver digital capability for the mission.
There is a proven set of principles that can help program managers skillfully guide their acquisitions as though they are a software company seeking to deliver a weapon system. This is similar to how executives at Amazon, Netflix, Airbnb, and Uber harnessed software, data, and machine learning to deliver market advantage in what were legacy industries of retail, entertainment, hospitality, and transportation. We call these principles “Acquisition Competency Targets for Software.”
Source: Software Defines Tactics: Structuring Military Software Acquisitions for Adaptability and Advantage in a Competitive Era by Jason Weiss and Dan Patt.
The Path to Artificial Intelligence Starts With Allowing Software to Evolve
Data and artificial intelligence and machine learning are widely considered important to the military’s future: Just look at the establishment last year of a new organization that reports directly to the deputy secretary — the Chief Digital and Artificial Intelligence Office. But officials must recognize that the origin of all digital data is software. The fresher and higher quality data is, the better data scientists can define artificial intelligence/machine learning models. Feedback loops are required to validate and mature each specific model. Direct and immediate access to software applications that are designed and built to accept and deploy artificial intelligence/machine learning models create the closed loop. Simply put, software begets data, data begets artificial intelligence/machine learning models, and these models need to be integrated into software to be actualized. The buzz-worthy commercial AI developments of 2022 like ChatGPT or Midjourney are built by processing data at nearly the internet’s scale, but are founded, enabled, and delivered on a robust software foundation. To ignore the role of software in this closed loop in favor of more intentional pursuit of data or artificial intelligence/machine learning strategies offers limited returns: Each part of this digital triad must be advanced simultaneously to realize battlefield advantages.
Software, in particular, must be acquired with an eye to future change — not only to enable artificial intelligence but also to enable security in light of ever-evolving threats. The best means to enable this constant change is a software factory or pipeline, which is the set of tools and processes that take the raw ingredients of working software — including source code — and delivers operational capability. The foundational Acquisition Competency Target for Software charges program executive officers to use a software factory suited to the needs of their particular project, but recognizes that the costs and complexities of building out a functioning software factory are significant. Instead, programs should first evaluate and explore an expanding set of existing Defense Department software factories to determine if one is close to meeting program needs. Investing in closing a small gap is likely cost effective and going to result in access to a functioning software ecosystem faster than starting from scratch.
We also recognize the foundational importance of security in defense software. In fact, it is so important that security checks should be built into the delivery pipeline from the beginning. The Acquisition Competency Target for Software #2 recognizes that this can only happen by working closely with an authorizing official to jointly partner and invest in the ingredients required to achieve a continuous authorization to operate. Early partnership here acknowledges that too many authorizing officials are still unsure what “shifting cybersecurity left into the delivery pipeline” means, what it accomplishes, or why they should support these activities. Education and dialogue along with adoption of a “Yes, if…” mentality will speed deployments into operationally relevant environments.
The DNA of a Better Joint Force is Born From Allowing Systems to Recombine
From the Defense Advanced Research Projects Agency ’s Mosaic Warfare concept to the new Joint Warfighting Concept, the U.S. military’s operational concepts are increasingly built on the idea of being able to flexibly recombine mission systems into an ever-larger array of kill chain options. But the mechanics of this are accomplished by splicing software systems together. The reality is that this process is closer to organ transplant than playing building blocks. There are some key principles that enable this, though — and they start with defining and exposing interfaces, often referred to as application programming interfaces.
Application programming interfaces are the quintessential mechanism for interacting with software. Well-defined interfaces can mitigate data access risks for programs. Acquisition Competency Target for Software #3 emphasizes this point by establishing the need to own your application programming interfaces, even more so than the source code or executable. After all, it is application programming interfaces that are the pre-requisite for establishing tip and cue capabilities between disparate platforms — not data or artificial intelligence/machine learning models. Furthermore, the enterprise architecture will ebb and flow with time, and a robust set of application programming interfaces marginalizes the impact of decommissioning old architectures in favor of new architectures in programs that measure their lifetime in years. Choosing how to define modularity does require good judgement, however.
A recurring theme heard in both government and private sector corporations is that people, not technology, are the most important assets. The need to attract, hire, and retain top-tier technologists means that programs must learn to behave like a software recruiter. Leadership at Kessel Run recognized the futility of recruiting staff using government websites and intentionally turned to social media to create demand. Kessel Run was depicted as an exclusive club, something people should seek to be a part of even if it meant abandoning an existing software start-up to take a government position with a reduced compensation package. The Acquisition Competency Target for Software #4 reminds program managers that they should behave like a software recruiter because digital modernization requires digital talent.
Use Modern Tools, Concepts, and Contracting Approaches to Deliver Resilience
In Silicon Valley venture capital circles, delivering software-as-a-service, usually by charging a monthly fee for a cloud-delivered web application, has been popular for more than a decade. The critical concept that underpins this success is the idea of a contract — a service-level agreement — built on an indicator that defines and quantitatively measures abstract notions like system availability. Development teams use these service level indicators to design and operate a system at a specific level, like 99.9 percent uptime. When one organization partners with another to deliver a service, they forge a service-level agreement that legally stipulates expectations and financial penalties for not meeting a specific service level, like that uptime guarantee. Acquisition Competency Target for Software #5 aims to recognize that anything that can be easily measured in service levels should be a strong candidate for outsourced operation instead of investing time and money towards in-house custom development. This principle is critical and is worth expanding upon.
Accountants think in terms of spreadsheets, graphic artists in terms of page layout, and project managers in terms of the venerable Gantt chart, which depicts deliverables as diamonds plotted against their anticipated time of arrival to assist production planning. The Gantt chart is excellent for assembling a list of tasks, dependencies, and milestones and visualizing progress to date. This project management tool has proven indispensable for coordinating industrial activities across a production floor at a given time. In the industrial setting, the hard part is not connecting the pieces, it is getting all the pieces to arrive on the factory floor at just the right moment.
The very essence of software, and in particular DevOps, is the opposite. To generalize, advanced commercial software for operating a modern enterprise is available on-demand as software-as-a-service. Enterprises can access everything from state-of-the-art resource planning to product life cycle management software, from learning management systems to human resource management systems. The hard part is not getting all the pieces to arrive by a milestone on a calendar using software — the difficulty is connecting them to interoperate reliably and at speed.
The integration between different architectures and application programming interface styles, combined with dozens of competing programming standards, creates delivery delays and affects the reliability and operational speed of a system. Software integration is not analogous to 20th-century industrial integration, and the Gantt chart has proven to be an unreliable management technique for software integration activities.
When a program can cleanly express a need, including its reliability, in a service-level indicator, and if established vendors can have the capability to meet or exceed those metrics, then the program’s first instinct should be to outsource that capability to a commercial or dual-use provider. Doing this allows the program to focus on building novel solutions for the hard-to-define requirements that existing providers cannot demonstrably meet. When the act of production is difficult, Program Executive Offices should want diamonds (on a Gantt chart), and when the speed and reliability of data in motion are difficult, they should want service levels.
The final principle for navigating in an era where “software is eating the world” is Acquisition Competency Target for Software #6: defining zero-trust outcomes within the program’s software applications. This means breaking up software systems into defensible chunks to shift the cybersecurity conversation from the discovery of a vulnerability meaning total compromise to one where intruder actions trigger an active response at the speed of relevance. Designers try to “air gap” the most important networks, making sure that there are no connections to the internet or outside systems via which vulnerabilities can be injected, but even these formidable moats can be stormed by intruders. While this is not an excuse to fail to build in formidable defenses, software is so extensive and dynamic that vulnerabilities and attacks are inevitable.
In recognition of this, the Defense Department has published a Zero Trust Strategy, but program managers also have a role in establishing incentives for realizing software applications that natively exhibit resilience. When built into the structure of the code and the delivery pipeline, attackers are unable to discern if they breached an application’s defenses under a “permit” or a “deny with countermeasures” condition that has alerted its security team and returned invalid and illogical data.
A Strategic Advantage From Better Software Delivery
If the Department of Defense acquires and develops software according to these six Acquisition Competency Targets for Software, with high-speed delivery mechanisms capable of quick changes, then software will enable superior force adaptability for the U.S. military compared to its strategic competitors. Adaptability is not an inherent property of software-defined systems. Once software has been deployed, changing its design and behaviors becomes extremely expensive. Once code has been compiled and deployed and disconnected from the build chain that produced it, it becomes rigid and resistant to change. Together, these six Acquisition Competency Targets for Software offer a counterbalance.
Sustainable operation of a software factory (Acquisition Competency Target for Software #1) running on a system that has embraced the principles of a continuous authorization to operate (Acquisition Competency Target for Software #2) provides a secure pathway for continuous improvement of software, data, and the deployment and feedback required for successful artificial intelligence/machine learning activities. When a program owns its application programming interfaces (Acquisition Competency Target for Software #3), it has the ability to experiment with new vendors, from the small upstart to large prime, constantly adapting to new threats without incurring the overhead of large-scale custom integration. Talent (Acquisition Competency Target for Software #4) is required to create these application programming interfaces and to properly design and build zero trust-enabled software applications (Acquisition Competency Target for Software #6). Finally, those aspects of the software architecture that can easily be measured and delivered to well-defined service levels by existing vendors (Acquisition Competency Target for Software #5) enables programs to maximize investments in novel research and development, not mundane IT operations.
Software delivery is about getting the right bits to the right places at the right time. Making these acquisition competency targets clear for software is another step forward in helping the acquisition community more efficiently navigate the software world. We must recognize and explore the value of diversity of form — the heterogeneity of software and the fact that a one-size-fits-all approach is incongruent with the software-defined world the warfighter must fight in. The Department of Defense must act in a way that recognizes that software, not legacy warfighting platforms, controls the speed and efficacy of the modern kill chain and military dilemma. And finally, the Department of Defense needs to formally recognize the digital triad of software, data, and artificial intelligence/machine learning as equal peers. Doing so will help the Department of Defense find its footing in an era where software defines tactics.