We are in the early stages of a generational defense
cycle that requires unconventional thinking and tools. The invasion of Ukraine
highlights this evolution: comparatively low-cost weapons, from drones to
precision artillery, are leveraging cutting-edge networks, like SpaceX’s
Starlink, to redefine battlefields. Meanwhile, a new variable — attritable tech
— is emerging. The implications are upending how militaries fight.
Defense innovation has always sparked a helix
of action and reaction, where faster evolution means greater success. In World
War II, Turing’s codebreakers at Bletchley Park reacted to Nazi cryptographic
improvements in a running duel that spanned years. The naval Enigma wasn’t
broken once, but dozens of times.
We are in a similar moment today, although the rate and scale of change is accelerated. Consider the lightning speed at which today’s most advanced general computing projects evolve. OpenAI’s GPT-4, which was released a little more than two years after its predecessor, can now ace bar exams and convert sketches to functioning websites — all in a compressed upgrade window that overtook competitors seemingly overnight. As general computing platforms become applicable to a host of defense applications, from programming autonomous behavior to conducting live targeting analysis, sweeping advances in software and other technologies not originally designed for defense have unintentionally compounded computing’s impact on war.
Responding to the paradigm shift requires reengineering the Pentagon’s DNA for a new era. Given that the winner of the next big war will more closely resemble a distributed computer operating at scale — programmatically collecting, sharing, and acting upon data from relatively inexpensive and configurable endpoints, like drones — computing design and organizational principles honed in the tech industry can help provide guidance to meet the challenge.
Here are some ideas for how to do it.
As the Central Intelligence Agency’s Chief Technology
Officer Nand Mulchandani pointed out in his essay “Software-Defined Warfare,” cloud computing (and modern application design,
overall) ushered in an era where hardware components like servers, storage
devices, and networking equipment have become interchangeable and standardized.
The transition to treating servers as “cattle” instead of “pets” presaged a
reduction in operational complexity, driving lower costs through
commoditization. Businesses utilizing cloud resources don’t need to endure long
hardware provisioning cycles just to test out new applications or features, or
over-purchase hardware for peak workloads that might come just once a year.
Businesses adopting cloud native design principles care relatively little about
hardware at all — their workloads are packaged as application containers that
can run on any virtual machine running Linux.
Modern militaries face a similar competitive
landscape, but the consequences are defeat instead of bankruptcy.
For a glimpse of what’s to come, look no
further than the Donbas. The Defense Advanced Research Projects Agency’s (DARPA)
premonition of “Mosaic Warfare” — saturating an adversary with cheap complexity —
has come to life. Modded quadcopters are pairing with artillery to serve as
ubiquitous reconnaissance and attack assets at the lowest tactical levels.
Sometimes, even drones themselves are the munition, as seen in individual tank strikes
and the mass naval attack that heavily damaged the Admiral Makarov, the flagship of Russia’s Black Sea fleet. Drones,
air defense systems, and missiles are democratizing lethality in much the same way offshoring, competition, and
government subsidies relentlessly commoditized computing hardware and chips. This rapid shift in
defense tech has economic implications; cheaper hardware can be deployed en
masse.
Why, then, have hardware costs risen so
dramatically at the Pentagon? The Air Force’s next-generation bomber, the B-21
Raider, is estimated to cost
$700 million per aircraft — a 140x increase in today’s dollars over B-24
Liberators from World War II. Part of the problem is that the Department of
Defense (DoD) doesn’t view most platforms as uniform endpoints in a larger
network. For a substantial portion of the force, they should.
Quantity will matter in the next war. We will need to
mass produce assets at scale — something we haven’t done with next-generation
fighter jets or aircraft carriers. If military hardware isn’t commoditized, it
won’t be replaceable in depth.
To this end, modern production sites for a
commoditized future will look different than legacy facilities that built jets
or carriers. They can be smaller. They can be modular. They can be forward
deployed. They can use “just-in-time” manufacturing techniques like 3D printing
to cut latency. In short, they add a layer of logistical resiliency by
decentralizing a military’s industrial footprint.
Relativity Space’s 3D-printed rocket, which
flew
beyond the maximum dynamic pressure (“Max q”) exerted on the structure during
its first launch, offers a preview of the promise of additive manufacturing. The
effect may extend beyond typical materials categories too. Companies like
Firehawk Aerospace, which 3D prints rocket fuel for solid-propellant
rockets, could enable a distributed logistics model that optimizes for rapid,
on-site production of fuels with finely tuned propellent grain geometries.
Emblematic of the broader sector, Firehawk’s design only uses commonly available
chemical materials – a sea change from current processes.
In combat, the Ukrainians are already using 3D printing to manufacture everything from drones to medical equipment. When combined with a transition toward commoditized hardware, they’ve nascently shown how elements of a 21st century force can be rebuilt on the fly, or reconstituted quickly. This regenerative capacity will be critical in other mission environments like the Pacific, where logistics chains could stretch thousands of miles.
The DoD should own the interfaces for its platforms.
This prevents vendor lock-in and enables the DoD and external startups to
compete within existing programs of record.
In creating the world’s first stealth
aircraft prototype, Have
Blue, which eventually became the
F-117 Nighthawk, Lockheed Martin’s Skunk Works famously re-used F-5 engines,
F-111 flight control actuators, an F-16’s flight control computer, a B-52’s
inertial navigation system, F-15 servos, and an F-18’s heads-up display. To save
time and money, Skunk Works engineers hacked together existing solutions from
individual manufacturers. The two Have
Blue prototypes came in under
budget, at $30 million total — unthinkably inexpensive in today’s
prime-dominated defense procurement environment.
What if this was the norm instead of an outlier? In the spirit of Skunk Works, composability incentivizes startup activity. Major weapons projects would become modular platforms. Important subsystems could be independently researched and procured. Smaller teams can leverage existing tools, frameworks, and libraries to reduce development time and costs. Lower barriers to entry fosters more competition. More competition results in better products at lower costs.
There are security considerations to allowing a
broader category of actors access to certain programs, but these could be
mitigated through a range of measures already in use, such as the testing and
certification process (more below).
An “open API” schema could also offer defense
tech startups revenue stability. Open standards allow them to compete for a
slice of long-term projects in times of budgetary uncertainty. Such
opportunities diversify business lines — just as prime contractors have done —
giving startups a greater chance of surviving in an industry that bends toward
forces of consolidation.
Battlefield data will come in unique forms. Synthetic
aperture radar imagery from an F-16 Fighting Falcon will be different from
infrared video captured by an AH-64 Apache. Instead of prescribing one standard
data format, the DoD needs a robust translation capability for
data that doesn’t throttle new
breakthroughs. Think of it like a compiler.
DARPA’s STITCHES program is a first step in this direction. STITCHES
uses Field and Transform Graphs (FTGs) to link data sets by finding pathways to
translate data between systems. Imagine speaking to someone in Arabic through a
common friend who speaks French. Translations can use existing pipes (English to
French, French to Arabic) to route and translate traffic. They don’t have to be
direct (English to Arabic), requiring each actor to change their behavior (learn
a new language). By avoiding universal standards, “system of systems” designs
accommodate a variety of data sets without imposing inadvertently overbearing
requirements that stifle innovation.
This doesn’t mean some overarching
commonalities shouldn’t be enforced. There are best practices for many
applications. For example, avenues of convergence exist for positional data or
video encoding processes, common areas where DoD platforms have extensive
real-world experience. But focusing on the translation layer versus a
standardization layer takes advantage of our biggest edge: innovative
capacity.
Just as iPhones and Teslas receive frequent software upgrades, so will future defense tech hardware. In order to realize the benefits of a software-first system, though, that hardware will need to be tested and certified rapidly. And, for well-informed safety and security factors, any modifications to an existing DoD asset require exhaustive testing and certification prior to implementation.
The challenge is in balancing these processes against
the benefits of modern software-enabled platforms that invert the
traditional upgrade cadence. Software
updates naturally occur on a more continuous basis than rigid hardware
timelines. Adjusting to a continuous cycle means re-thinking budgeting rhythms
that allocate funding on multi-year schedules guided by hardware updates.
Software-first systems provide rapid upgradeability and redeployment, but their
benefits are only realized if the testing and certification processes can match
their speed.
The DoD should look to startups to help solve
this problem. Automating testing is a clear way to cut development and
deployment times if quality control thresholds can be maintained. Additionally,
the DoD could provide new testing guidelines that delineate between deploying
new software and activating embedded capabilities in existing software that
should shorten recertification timelines. The procurement process needs a
philosophical and operational shift to recognize the value of software not just
commensurate with the value of hardware, but exceeding it. From now on, it’s the
software that matters, the hardware is often a commodity.
Remote data collection — a skill tech companies have honed to a granular level — allows engineers to fix problems with over-the-air code changes. When the Russians began jamming Starlink satellite communications terminals in Ukraine last year, SpaceX engineers identified the type of jamming and pushed a software upgrade to fix it. SpaceX’s engineers didn’t even have to be present to take action; they diagnosed and remedied the issue from a different continent. This kind of capability is unprecedented in modern war.
Future forces will take programmability a step further. They will use fleets of upgradeable autonomous systems across a spectrum of manned counterparts, resulting in compute-centric networks that fight in fluid, more automated ways. Unmanned systems decouple costs from effects, allowing for “kill webs” instead of “kill chains.”
One implication of this software-first structure is the accelerated pace of tactical change. Iterative cycles will be measured in days, hours, and minutes — not years. This pace mirrors the tech world more than traditional defense procurement timelines driven by DoD’s multi-year Planning, Programming, Budgeting, and Execution (PPBE) process. Moving ahead, militaries that expediently gather, incorporate, and iterate on more and better intelligence will be better positioned to win large-scale conflicts.
Ukrainian missions against high-priority Russian
military targets, whether sinking $750 million destroyers like the Moskva or damaging $330 million A-50U AWACS electronic warfare aircraft, have revealed the subtle, but instrumental role
these platforms play in modern communications and air defense systems. Prior to
its sinking, the Moskva
provided a protective radar umbrella for the entire Russian Black Sea fleet.
Attacks like these illuminate the perils of
“citadel-centric” strategies, or a reliance on expensive platforms, as Eliot
Ackerman, the author and Marine veteran, wrote
in the Atlantic last year. The marginal value of sophisticated, centralized
systems declines in proportion to an adversary’s defensive capabilities. This
isn’t to say they aren’t useful, but it doesn’t require a tremendous leap in
logic to see the implications for downstream military strategy: an
adversary can collapse an entire network by targeting critical focal
points.
The solution may lie in a different systems
architecture. Take Starlink. Starlink is difficult to disrupt because it has
more than 3,500 satellites in low Earth orbit (LEO), giving ground terminals
varied pathways to an array of overhead access points. When combined with a subtle electronic intelligence footprint, high
bandwidth, and low latency, it provides a new communications capability that
isn’t easily degraded or destroyed. There are too many discrete nodes.
Drones could also contribute to a decentralized architecture. In the next conflict, they will communicate with each other directly, akin to a peer-to-peer computing network. When synchronized with other computing advances, they will learn from each other too, streamlining software layers that aggregate data. An MQ-9 Reaper will go beyond simply conducting remotely operated surveillance. The drone will learn from what it sees and then relay those lessons to other assets — assets that will be expendable, but whose knowledge won’t be. Permanent memory is an output of resilient data networks.
Procurement officers need to be rewarded for taking
appropriate risks with startups. In the current system, they are
not.
Startups face skewed downside in the
Pentagon’s decision matrix. There is no incentive for a forward-looking official
to select an untested startup for a new contract. On the other hand, picking
incumbent prime contractors is always a safe bet. Even if the project finishes
behind schedule and over cost, no one gets fired for adhering to the status quo.
And, despite a host of initiatives designed to provide high-risk capital to
defense startups, make-or-break program funding is still largely decided by
procurement officials within the Pentagon.
The Defense Innovation Unit in FY23 issued
$1.3 billion in transition funding in 2022, and just over $200 million in
prototype awards — substantial increases from previous years, but less than one
percent of the Pentagon’s budget from the FY22 National Defense Authorization
Act. Moreover, only four percent of the overall U.S. national security budget is
dedicated to innovation. It’s not enough. On a proportional basis, big tech
companies are spending three to five times more than the Pentagon on
research and development.
The larger challenge is: how can the Pentagon offer a broader and faster
pathway for transformational defense startups to access larger contracts?
We need a level playing field that lets the best
tech emerge. Beyond a certain scale, all leaders of large organizations become
capital allocators – priorities get the dollars. But in defense, entire swaths
of dollars go to legacy projects and programs that are kept on life-support for
far too long. It’s time to reallocate the dollars toward the future.
Integrating computing design principles into the military acquisitions process might sound like a reversion — after all, the Pentagon was instrumental in Silicon Valley’s founding, not vice versa — but computing’s pervasiveness demands an immediate strategy adjustment.
Our willingness to adapt matters. What today is considered asymmetric — drones over dreadnoughts — will become the norm. In fact, it’s a dynamic that plays out frequently in the tech industry when startups with new technology and fewer institutional constraints out execute deep-pocketed incumbents. We need to recalibrate our military procurement and design processes to account for that reality. Rewiring the Pentagon as an ambidextrous organization capable of rapidly fielding innovative tech and still delivering on established programs can help us get there.
Porter Smith is a deal partner at CFI Prior to joining CFI he researched autonomous systems for the Defense Innovation Unit and served in the U.S. military for 10 years as an AH-64 Apache and MH-6 Little Bird pilot.
David Ulevitch is a general partner at CFI co-leading the American Dynamism practice. David previously led the Security Business for Cisco Systems and was the founder and CEO of OpenDNS, a cloud-delivered cybersecurity business.
Thanks to Eric Slesinger, Kevin Chlan, Art Morrish, Andy Yakulis, Matt Croce, David Hoyt, Orlando Zambrano, Alex Pruden, Robert Hackett, and Derrick Harris for their invaluable contributions.
* * *
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of CFI or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by CFI While taken from sources believed to be reliable, CFI has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; CFI has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by CFI (An offering to invest in an CFI fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by CFI and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by CFI Corporation (excluding investments for which the issuer has not provided permission for CFI to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.