by CPT Matthew Moellering, USA, and CW3 Nicholas Vettore, USA
Harding Paper 24-2, September 2024

Introduction

The military that best integrates modern software practices into warfighting will gain a decisive advantage in contemporary conflict. Skeptics may consider the fusion of software and combat to be unattainable, or even impractical, but this new battlefield reality is here to stay. Various Army and DoD units are already using cloud platforms and commercial software practices to quickly deliver applications,¹ but the current efforts fall short of the demands of modern warfare. In this new era, where algorithms and machines dictate the tempo of conflict, software has become the new arsenal. In this article, we introduce a new framework, forged from industry best practices, that seeks to revolutionize our warfighting capabilities by seamlessly integrating software, data and cybersecurity, all tailored to the unique needs and challenges of our military forces.

Every Soldier Fights with Software

Take a moment to imagine Sergeant John Smith, a Soldier out on patrol in 2025, equipped with two essential items: an automatic rifle and a cell phone known as an End User Device (EUD). The operating system for this EUD is called Android Team Awareness Kit (ATAK),² and this EUD is a crucial tool on the front lines. It allows Smith to communicate with his squad, send reports to higher command and to control a drone for aerial surveillance—all without exposing himself to enemy fire.

On a mission to join forces with a sister unit for a scouting operation, SGT Smith realizes that both units possess EUDs. It occurs to him that this provides a great opportunity to conduct forward surveillance and to monitor enemy movements on the flanks, which enhances safety. This capability is a game-changer. All he and the other unit’s leader need to do is sync the information on each EUD, which will allow them to share video feeds and send encrypted messages within a certain range.

It’s a good idea, but there are issues. The sister platoon’s EUD is WINTAK—a Windows-based operating system EUD—and one that isn’t natively compatible with ATAK. Their new First-Person-View (FPV) drones are also using a different plug-in that isn’t working on Smith’s ATAK. With only 48 hours left until they are expected to reach their objective, SGT Smith informs his higher echelon command that a small change in each device’s software is needed to make them compatible. However, the response he receives leaves him discouraged: “Due to the current software development and security validation process, we are unable to push this update for 6–8 months.”

What should he do? A junior software engineer could fix this in a few hours, but SGT Smith can’t download a solution from the Play Store—this problem just appeared 10 minutes ago. He has the technology to fly a complex drone on a closed network, to stream data back to command hundreds of kilometers away and to send messages simultaneously. Yet, he can’t share this important information with the Soldier right next to him. It seems absurd, but in truth, he’s fortunate that he even had a good communications shop able to run ATAK at all.

SGT Smith is a professional, but he lacks the tools a professional would expect to have on hand to conduct his craft. A surgeon would not be expected to wait two weeks for a specific tool if he or she encountered a sudden life-threatening complication in the middle of an operation. A firefighting team would not be asked to wait for permission to save the building next to the home where the fire originated because the 911 call didn’t originally specify that they fight the fire at the additional address. Professionals are trained and trusted individuals who should be free to adapt and make decisions based on the demands of the moment; their tools and support systems should enable them instead of holding them back.

Unfortunately, this fictional scenario reflects the imminent reality for Soldiers in many platoons across the Army, and it highlights the challenges that organizations face when they are stuck using outdated methods for software deployment. What we hope software skeptics take away from this illustration is that any organizational structure that puts time and distance between warfighters on the ground and the updates they need to respond to battlefield realities is counterproductive and, ultimately, dangerous. The ways in which software is currently sourced, maintained and integrated are already affecting Soldiers’ abilities to conduct their tactical tasks. Units must regain a measure of control over the software they use on a regular basis. In order to make this leap, software and operations have to become more fully integrated, and the existing organizational barriers between them must be deliberately dismantled.

DevOps: A brief History

Integrating software and operations is a concept that revolutionized many private sector industries in the 2010s, quickly becoming one of the marks of winning organizations. This approach was popularly proposed in the book The Phoenix Project,³ an allegorical narrative that examines how a struggling car parts company narrowly avoids collapse by completely reversing the way it thinks about and approaches Information Technology (IT). In an early part of the book, the CEO asserts that he considers IT to be an afterthought whose primary responsibility is to not not work. He states that dealing with IT “should be like using the toilet. I use the toilet and I never worry about it not working. What I don’t want is for the toilets to back up and flood the entire building.”⁴ His attitude changes over time as he learns that IT is not just a utility but one of the most powerful tools in his operational arsenal. Through its fictional premise, The Phoenix Project outlines new principles—the Development Operations, or DevOps, principles⁵—and proves how they can dramatically transform organizations from reactionary, stagnant entities into proactive, agile ones. Although originally designed to solve business problems, we believe the DevOps principles can inform the way the military approaches its own software dilemmas.

DevOps principles accelerate the software development lifecycle by promoting feedback loops and fostering organizational learning and experimentation.⁶ Originally introduced in the famous presentation, “10+ Deploys per day: Dev and Ops cooperation at Flickr,”⁷ these principles have shifted from niche to standard practice for all successful tech companies.⁸ When properly implemented, DevOps increases collaboration between software development and IT operations to automate processes and enhance software delivery.⁹ Its unprecedented success and centrality to the way modern enterprises conduct business can be conveyed in numbers. In the short 15 years since its first introduction, DevOps has grown into a $12.4 billion market.¹⁰ Further, many companies attempt to fill their growing number of DevOps positions with top talent, evidenced by the high salaries and demand for experts in the field.¹¹

It is worth mentioning that DevOps has eventually evolved to include cybersecurity and compliance considerations; because of this, it is now known as “DevSecOps.”¹² DevSecOps is important in that it integrates security into every phase of the software development cycle through automation. We primarily refer to DevOps in this article, however, not because cybersecurity is unimportant to Army operations, but because Cyber is a distinct branch within the DoD, making the application of DevSecOps in a military context less directly translatable from private sector practices.

To examine how new DevOps-driven business practices may help the Army to address its own software problems, we can turn to a scene from The Phoenix Project in which developers are tasked with building a new web application over several years. Before DevOps transformed the business, developers would do their work in a silo and then hand the final product over to IT—a process known as “throwing over the wall.” This method of exchange created messy transitions that led to bugs, failed deployments and, ultimately, disappointed customers who would find themselves wanting to use applications that didn’t work. DevOps principles, once applied, brought the team responsible for running the code into the development process.

The integration accomplished two important objectives: 1) facilitating rapid, iterative improvements to the software itself and 2) preparing the IT teams to manage the workflows from developers. The Army¹³ and the larger DoD¹⁴ have started applying these principles to improve software acquisition and integration, but marginal improvements to the existing system, while admirable, are not nearly enough to transform the Army into a “winning” enterprise when it comes to software integration. Even with these improvements, the software acquisition process is too slow to keep pace with tactical innovations on the ground. The structure itself also has more silos and proverbial “walls” than most large businesses did before DevOps transformed their IT organizations in the 2010s.

The most obvious “wall” in the current structure sits between the acquisition units and the communications (IT operations) units that are responsible for implementing new changes. In reality, the handoffs between these units feels less like “throwing over the wall” and more like “dropping off the cliff.” Acquisition representatives rarely interact with the users responsible for implementing new software. The problem doesn’t end here. Even if acquisitions officials and end-users were to suddenly come into perfect harmony, the existing processes for adapting to new changes still take years. There are corners of the DoD that are able to circumvent this dynamic, but most Army units have never had to integrate a developer into their organization.

Introducing DevOpsWar

As outlined, the Army could dramatically improve its adaptability by implementing DevOps principles across its current structure, from acquisitions to the tactical level. However, we recognize that modern business and the military are distinct entities with different constraints. While DevOps focuses on developers, business operations and security compliance, the Army must also consider intelligence, operations, software and network security, as well as the evolving complexities of models and Artificial Intelligence (AI) in modern warfare. These functions are interconnected on the battlefield and should not remain fragmented parts of our military organization.

Simply stating that the Army should adopt DevOps is insufficient and potentially unhelpful, given the Army’s unique mission and structure. Instead, we propose a new approach to integrating software in warfighting, characterized by five core principles, that considers the Army’s unique attributes and prioritizes operational effectiveness. We refer to this new approach throughout the rest of this article as DevWarOps.

If properly applied, DevWarOps will help our modern military meet the demands of technological innovation, just as the existing Prussian staff system helped Industrial Age armies adapt to faster movement, demanding logistics and frequent communication. The Prussian staff system, though effective for its time, has served its purpose; it is no longer practical in the 21st century. The Army’s continued reliance on it will hinder its ability to keep pace with the technological advancements that are vital to its operational success.

There is precedent for reorganizing in the face of necessity. The Joint Special Operations Command (JSOC), for example, reinvented itself to face combat terrorism in the fight against Al Qaeda in Iraq.¹⁵ It did this by integrating intelligence and operations to manage the vast amounts of available data, tightening its Observe, Orient, Decide, Act (OODA) loops, and, ultimately, helping the operations and intelligence elements to better understand each other’s needs. This transformation echoes the core principles of DevOps discussed above.

JSOC’s transformation is a helpful starting point. However, given the rapid advancements in software development, AI and commercial off-the-shelf (COTS) drone technology, the Army needs a framework that goes beyond the best practices outlined in Team of Teams.¹⁶ DevWarOps represents this framework by integrating intelligence, operations, software and AI and by securing them through modern military and network security to achieve dominance at the pace of battle.

To realize this vision, the U.S. Army should take actionable steps to bridge the gap between practitioners and developers. This includes establishing Software Integration Units (rebranded and reorganized software factories) at the corps level and instituting DevWarOps cells at battalion and higher levels to rapidly integrate changes to command and control (C2) and to drone systems. While a complete overhaul of the current system is unlikely, we recommend an iterative approach that builds on existing successes within the force and draws from industry best practices.

To begin the discussion and facilitate this transition, we propose the following five principles, which should guide unit leaders in rethinking the role software plays in warfare:

1. The software development cycle is the new OODA loop.
2. Data drives operations.
3. Good software is never done.
4. At the unit level, software should enhance warfighting.
5. Software is the door to the cyber domain.

We believe the first military to fully implement these principles will gain a maneuver advantage in the 21st century. In the sections below, we will briefly demonstrate how each principle can be applied using relevant examples.

Principle 1: The software development cycle is the new OODA loop.

Lieutenant Colonel John Boyd invented the OODA loop during the Cold War to help fighter pilots outmaneuver their Soviet opponents in dogfights.¹⁷ Boyd understood that, while he couldn’t alter the fighter planes themselves, he could train pilots to make faster and better decisions, giving them a tactical edge. The OODA loop’s core idea—that the unit completing the loop the fastest will prevail—remains relevant today.¹⁸ Just as we admire skilled quarterbacks who quickly read defenses and adjust their plays accordingly, the ability to rapidly observe, orient, decide and act is crucial in modern warfare.

In Ukraine, the OODA loop has already been integrated into the DevOps software development cycle. Initially, Ukrainian drones effectively targeted Russian vehicles, prompting Russia to adapt with electronic warfare (EW), which in turn forced the Ukrainians to switch to smaller FPV drones. The Russians then adapted their countermeasures, leading the Ukrainians to modify their drone software to extend operational capabilities. Both sides are now experimenting with AI for target identification and autonomous flight. This dynamic approach is not limited to Europe; U.S. forces in Iraq and Syria also recognize the need for DevWarOps and how pressing these same issues are in their own operational environments.¹⁹

A recent RUSI report by Jack Watling highlights the rapid adaptation required to keep drone systems in Ukraine operational, noting that a drone’s effectiveness typically lasts only two-to-six weeks before it must be updated or replaced due to evolving threats.²⁰ That battlefield reality contrasts sharply with the American acquisition system, whose current process for deploying new software takes two-to-five years;²¹ that’s an OODA loop that is 18–135 iterations behind. To gain the tactical edge and succeed in dynamic battlefield environments, the U.S. Army must significantly reduce the time it takes to run through its software development cycle.

Principle 2: Data Drives Operations

Data has become a critical asset, driving operations and decision-making with unprecedented precision. This second principle underscores the essential role that data plays in shaping strategies and executing missions. By analyzing extensive data from various sources, military leaders can gain valuable insights into enemy movements, terrain impacts and operational risks. This data-centric approach allows commanders to make more informed decisions, optimize resource allocation and enhance overall mission effectiveness.

Data is to AI what ammunition is to a gun or fuel is to a tank: The latter is virtually useless without the former. As AI is integrated into military workflows, the quality and accuracy of the data used to train models will significantly impact their operational capability. Real-time reconnaissance, surveillance and sensor networks—what we think of as traditional intelligence streams—will merge with logistics and operational data feeds at machine speeds. This will create the common operating picture shared among units and commanders.

AI can amplify the value of data by providing advanced analytical tools that process large datasets quickly and accurately. As AI evolves, its integration with data-driven strategies will further refine operational planning and execution, making military operations more responsive and resilient to dynamic challenges. To fully leverage AI’s capabilities, the Army must adopt processes and organizational structures that support this technology.

AI also introduces a specialized form of DevOps known as Machine Learning Operations (MLOps).²² MLOps manages not only the software but also the data used to train and maintain algorithms and models. As militaries increasingly adopt AI, understanding the impact of MLOps on AI-assisted and AI-enabled weapon systems will be crucial. This is already broadly understood in the technology industry. Meta’s opensource model LLama, for example, has already been updated three times in the past year. Units that are adept at integrating software will be able to adapt, secure and validate these updates effectively. Without this capability, however, units may struggle to address issues as they arise.

More important than managing models is the data engineering aspect of MLOps. Ensuring that data is accurately extracted, transformed and loaded is an ongoing task that will require skilled personnel. The Army is already addressing this need with multiple new data engineering specialties. Mastering how systems generate and report data—and ensuring its accuracy—will become part of the operational art.

Ultimately, while AI, models and their maintenance are often in the spotlight, their effectiveness hinges on a steady stream of accurate data. The Army possesses a wealth of data, but most of it is not formatted or organized in a way that machines can process and use for modeling. Just as a commander would be dissatisfied if the equipment on their hand receipt was accounted for but not fully mission capable, the Army’s data is similarly “not mission capable” if it is not prepared for integration into models that will create the common operating picture of the modern battlefield.

Principle 3: Good software is never done.

For decades, DoD has sought to achieve decision dominance through various initiatives, but none has fully integrated all data streams to the end users. Programs like Network-Centric Warfare,²³ Future Combat Systems,²⁴ Mosaic Warfare²⁵ and Joint All-Domain C2 (JADC2)²⁶ have come and gone. Each had noble intentions, but they all seemed to miss the forest for the trees by overlooking the crucial fact that software is iterative. Rear Admiral Susan BryerJoyner, deputy commanding flag officer of JADC2, underscored this point by noting, “JADC2 isn’t a program; it’s a verb.”²⁷ We agree. Creating effective software, like effective C2, is an ongoing process; it is never truly complete. Commanders must understand that their systems will change, affecting their capability and the weapon systems that they bring to the fight.

This principle also highlights the ongoing challenge of software maintenance, which requires new features, regular updates and bug fixes. Historically, DoD has struggled with managing software contracts, a challenge that will persist as software integration deepens. Our proposal does not aim to replace commercial software solutions or prime contractors; rather, it addresses the issues faced by units on the operational front lines. Multiple levels of abstraction have created a disconnect between software providers and the Soldiers they support. By establishing software units at the corps level, we can improve feedback and maintenance processes, improve industry relationships and ensure that software design better meets the needs of servicemembers adapting to it in the field.

Principle 4: At the unit level, software should enhance warfighting.

Software has the potential to solve many problems for DoD, but maneuver units should focus their software and data initiatives solely on enhancing warfighting capabilities. Most existing software issues within DoD can be resolved with commercial solutions. Modern agile software practices emphasize the importance of user feedback, aligning design decisions with user needs. Companies that ignore this feedback loop often find their products obsolete and face market failure.

However, DoD faces a challenge: purchased software often remains unused, and clunky issued tablets often collect dust in company supply rooms.²⁸ To overcome this, software must be integrated directly into the warfighting process, allowing feedback from units and operational intelligence leads that are actively engaged in battle. This approach ensures that software development remains closely aligned with actual warfighter needs.

Commanders must enforce this principle by focusing exclusively on how software integrates with drones and mission command systems. Operational Data Science Teams should prioritize metrics that enhance warfighting capabilities and offer actionable insights based on the AI that is in use. As drones become increasingly important, development efforts should address the evolving software needs related to drone and counter-drone operations. While it may be tempting to improve or adapt cumbersome staff functions and business practices, commanders must always ask the pivotal question that this principle raises: How does this enhance warfighting?

Principle 5: Software is the door to the cyber domain.

It may seem obvious, but it’s important to emphasize that cybersecurity must not be an afterthought when integrating software and data science into operational spaces. Adding new software can introduce vulnerabilities and increase risk. To mitigate these risks, industry best practices suggest embedding cybersecurity personnel directly within development and operations teams.²⁹

Establishing software units presents a valuable opportunity to integrate cybersecurity professionals directly into maneuver forces. This integration could also pave the way for enhanced offensive cyber capabilities in the long run. As maneuver units gain a deeper understanding of how their DevOps pipelines affect warfighting, they will be better equipped to grasp the role of cybersecurity and its influence both on their own operations and on the enemy’s.

As units begin to handle their own data and software development, they must ensure that cybersecurity is incorporated at every stage of the process. Software development intersects with the cyber domain, yet many cyber units remain poorly integrated with maneuver units, and their impact is often limited.³⁰ This needs to change, but deeper integration and small iterative improvements could reveal the path forward. As one senior National Security Agency leader noted, we are still in the “biplane era” of cyber war.³¹

Conclusion: Adapt, or Die

Army Chief of Staff General Randy George recently emphasized that units need to be ready to “transform in contact,” but this mandate requires cultural and organizational transformations that have yet to begin.³² Small pockets of excellence often navigate around the organizational culture to produce quick wins, but these victories rarely become repeatable successes. In a rapidly evolving technological landscape, maintaining pace will require units to meet the goal of “10 commits a day”—ten daily code changes in production. Technology has become integral to modern warfare processes; it is not just an add-on. Such a transformation will require a unified effort across the Army structure. We recommend the following steps to begin the process:

1. Establish software units at the corps level: Create software integration units at the corps level to take leadership for the role software plays on the battlefield. This would also provide the platform for data science teams to integrate with staff processes and for our proposed DevWarOps units to integrate software changes to drone units.
2. Continue to iterate through the DevWarOps principles: As more Army leaders become data-literate, they should reassess the role software plays in their organization and consider how more responsive, customized technology might improve their ability to execute core competencies. The current planning and staff processes are more of a waterfall process, but the digital age relies on agility. The five DevWarOps principles outlined here should serve as a foundation in this process, and we expect them to evolve as leaders engage with them.

Diffuse technological innovation, rapid software development and advanced EW capabilities currently allow the enemy to adapt to battlefield innovations in previously inconceivable timelines—as short as four-to-six weeks; the existing Prussian staff and American acquisition systems are hopelessly ill equipped to compete in this new environment. Just as JSOC combined intel and ops to increase targeting,³³ DevWarOps insists on integrating software development and operations, through the DevOps principles, to equip units to adapt to enemy techniques and to better integrate technology at the pace of battle. Technology is changing the way that we fight faster than we are currently able to leverage it. Whether we like it or not, the Army must adapt. The changes that we call for here have the potential to separate forces at the rate that maneuver warfare did at the end of the last industrial revolution.³⁴

★  ★  ★  ★

CPT Matthew Moellering previously served at the Army Artificial Intelligence and Integration Center after completing the AI Scholar Program. He also volunteers for the Irregular Warfare Initiative, serving as a cohost for the Irregular Warfare podcast. Matt is currently a LTG (Ret) James Dubik Writing Fellow.

CW3 Nicholas Vettore has served over 19 years of service as an Army Communications specialist. Nick has deployed to Afghanistan and Europe, and he has a strong background in both tactical and strategic level communications. Nick is currently serving at the Artificial Intelligence Factory at the Artificial Intelligence Integration Center.

Notes▼