Acquisition and the Military Technical Balance
This note drills down on a root problem underlying the larger, broadly accepted problem that the military-technical balance between the United States and great powers is eroding.
In a growing number of mission areas, the performance of software, not hardware, has become the most important factor in determining the overall performance of warfighting platforms. This reality is a natural consequence of warfighting platforms becoming digitized and networked, and of computing systems becoming platforms in and of themselves. In the commercial world, hardware is relegated to a commodity, and software is the source of competitive advantage. In the military context, now it is often more accurate to describe a weapons system as the union of commodity hardware and lethal software, than the other way around.
Notably, the strategy required to ensure cost-efficient delivery of an integrated platform is not just different from the strategy to deliver predesigned hardware platforms; it actually reverses that strategy. That is, the very model that once worked to deliver hardware in the Industrial Age causes failure in the Information Age– and yet theDepartment still tolerates the old model.
In other words, the Department has not yet penetrated to the mother principle: that procurement of an integrated hardware and software capability will succeed only inasmuch as it reflects the nature of software development. More specifically, the strategy must be consistent with the nature of software development in the private sector, where rapid adaptation and continuous software development are foundational practices.
SOURCE OF THE PROBLEM
Why is this so? Because all software is built on computing power, and computing power continues its rapid increase after many years of exponential growth. The inevitable consequence of this technical evolution, and the continuous evolution of the cyber threat, is that after only a few short months, software designs become obsolete and decay in place. This means that platforms designed using iterative development methods can incorporate software that blows away old standards. The capabilities of software-centric platforms represent “discontinuous innovations” that translate into competitive advantages across the battlefield. Nevertheless, despite the fact that the private sector faces many of the same security threats as the Department, the unique compliance requirements of security for Department software and hardware systems impede adopting cheaper and more effective solutions.
Under the prevailing acquisition model, the Department combines investments into large enterprise programs; implements programs over many years; validates detailed requirements at yearly intervals; assumes the risk of custom development; measures progress against program milestones; rewards program managers based on those measurements; and lacks appropriate funding models to resource software development or sustainment. Such incentives set in motion a cycle whereby program managers continually chase a predetermined end state, but never move fast enough to deliver it before the next big thing renders it obsolete. Whereas the Department’s acquisition processes optimize for reliability, safety, consistency, fairness of competition, risk reduction, and cost efficiency, those same processes fail to optimize for the most important virtue in the Information Age: speed.
The prevailing model is based on four outdated assumptions:
Consolidating systems, integrating processes, and standardizing policies are the best ways to collect, analyze, and employ data;
The more money the government spends trying to develop sweeping enterprise platforms, the more capabilities it receives;
Because the government’s requirements are unique, for most capabilities the Department needs a custom-built, government-owned solution; and
The government can set hundreds of detailed software requirements years in advance.
The nature of software development invalidates these assumptions. Because computing power continues to grow at a rapid pace, we should expect to pay less over time for better technology, even in the government. Moreover, while some software requirements are unique to the government, most fundamental software engineering problems are not unique to the government. These false assumptions doom any effort by the Department to adopt commercially available and proven standards that accommodate the IT evolution.
Above all, because design constraints reset on a routine basis, software outcomes cannot be predetermined accurately years in advance. This single fact represents the biggest of the big ideas governing procurement in the Information Age. It has profound implications for the acquisition of integrated systems because the performance gains made possible by such rapid technology development means acquisition programs cannot define requirements fast enough to keep pace with sources of innovation in the global market.
APPROACHING THE PROBLEM
Yet despite numerous acquisition failures resulting from the ground shifting underneath its feet, the Department has presented acquisition reform initiatives in the form of a laundry list, with no apparent prioritization. The Better Buying Power series groups reform initiatives into focus areas, none of which take priority over the other, and all of which appear to ignore the more general problem underlying repeated acquisition failures in the Information Age. The net result is that many reform initiatives address symptoms of the problem, and stand in the way of genuine reform.
Over the past decade, the Defense Department has invested in several large-scale IT projects, including efforts to develop a unifying enterprise architecture, a singular security model, and a transition to cloud technologies. While these initiatives seem beneficial in theory, in practice they have proven impractical to implement, expensive to develop, and hostile to competition. Absent fundamental reform to the prevailing model, poor outcomes will only worsen as the pace of development accelerates and the role of technology in government expands.
For that reason, incremental reforms like those proposed in the Better Buying Power series, and those put in action by various “AT&L initiatives,” do not reverse acquisition strategies, but rather seek ways to get around the failing system. Notably, some initiatives like the Strategic Capabilities Office, Defense Innovation Unit-Experimental, and Defense Digital Service, are pioneering acquisition models consistent with the new reality and have demonstrated traction against the larger problem. However, their combined budgets total less than one percent of the Department’s total acquisition budget. This lack of scale, coupled with the raft of multi-billion dollar services projects promising the moon, virtually guarantees these efforts never displace a program-of-record, even if they work and existing programs clearly do not.
Assuming good people will overcome bad processes will guarantee the erosion of America’s military-technical balance. The key point is not just the change in strategy. For the institution to succeed, it must embrace the opposite of the prevailing strategy, and do so in a way that attracts capital investment from the private sector. Sweeping enterprise architectures and multi-year, multi-billion-dollar Information Technology development (as opposed to procurement) programs should cease to exist as a model for technology investment.
Three principles should frame the Department’s approach to building military-technical advantage:
Data is a critical asset; there are no theories of victory in the future that do not involve mastery of data science, machine learning, and artificial intelligence;
Computer science and related fields are today fundamental warfighting skills that need to be cultivated across the force as a central element of generating combat power; and
Computing power, bandwidth, and automated networks must be abundant.
An effective acquisition model in the Information Age would reverse the prevailing government model, ensuring the government adopts existing capabilities and only develops capabilities designed to meet unique needs within organizations. It would focus investments on proven platforms, test capabilities over weeks and months, and change requirements on a continuous basis. Most important, it would not waste time and money trying to duplicate capabilities that already exist, but instead distinguish universal needs from government-unique needs. When development or customization is required, acquisitions must be defined around the process for delivering the functional products and not the specific functionality of the products themselves. Product owners at the mission level require the flexibility and power to adapt capabilities based on ever-changing mission and user needs.