Please cite Matei, S. A. (2022-2025). Transforming Warfighting: The Case for Software-Centric Strategies. Matei.org/I Think Blog. https://matei.org/ithink/2024/05/27/doing-more-with-less-a-data-model-driven-methodology-for-efficient-war-fighting-platforms-design/
Since time immemorial military technologies have been built “just in case,” focusing on technical superiority features. Firearms, artillery, ships, and later planes and missiles have been imagined as tools adaptable to various situations and contingencies. Doctrine and perception of enemy capabilities also played a role, but the process was rooted in “clinical intuition” and political perceptions; they were rarely linked to evidence-based planning. Although efforts have been made since World War II to predict the future through analyzing the balance of power and future scenarios, determining and supporting new technologies or platforms is still based on subjective evaluations. Net assessments have a limited influence on the design process in policy and high-level planning circles, as they are considered only indirectly and often after the fact. Because of this, not only the design process is fed by ambiguous needs and perceptions, but hardware drives the process, leaving doctrine and applications behind.
I propose that the military technology design process should be driven, metaphorically speaking, by “software.” This should be the data-driven operational model that integrates and projects the power of technology on the battlefield. The proposal is to consider creating kill chains, similar to how companies like Uber or Amazon develop transportation or computing services. Prioritize the software-driven business model first, then add hardware components such as cars for Uber or server farms for Amazon later.
A case for a “software first” military development process
The “software first” proposition will overcome the shortfalls of the current loose planning and design methodology, which puts warfighting needs shape design through a long chain of decisions, including political ones, over-specification, over-engineering, numerous blind alleys, cost overruns, and mission creep.[1]
Before discussing the new method of imagining and designing kill chains driven by data-driven models, let us better define the “hardware-centric design process.” The emphasis falls on specifications and raw capabilities defined in advance based on performance and capabilities. The application of the capabilities comes as an afterthought, which is typically shoehorned into it. We find ourselves in a situation similar to the early days of personal computing, where computers were built to last, capable of upgrades, and adaptable to new software and applications. However, as IBM and Microsoft learned the hard way, software and applications that went far beyond the desktop platform, including the Internet, constantly left the hardware in the rearview mirror. Testimonies are the OS/2, Windows 98, and 2000 OS releases, notoriously out of sync with the hardware development cycles.
More recently, however, the commercial world introduced completely new platforms that treat hardware as a highly flexible, secondary environment designed for rapid obsolescence and broad interoperability. Uber and Amazon Web Services are perfect examples of this. Transportation and computing as a service focus on specific business models, be they decentralized crowdsourced taxi services or instantaneously expanding computing-as-utility services, including machine learning, web applications, or distributed data storage.
Military platforms are woefully inadequate for this new design philosophy. The main reason is that hardware still reigns supreme and the case for a unified “software application” for kill chains driven by credible doctrine-inflected tactical and operational models is at the pre-prototype in the best-case scenario and wish-list phase in most situations. For example, despite valiant efforts and funding invested in JADC2 (Joint All Domain Command and Control) concepts, the operational brains of most war-fighting platforms are still the human ones. Returning to the UBER model, although the military has all the modern digital capabilities to collect GPS data, fuse and display the data on maps and communicate the decisions to the units that execute the fire missions via distributed networks, the decisions are made by the operational equivalent of taxi dispatchers. Human officers look at screens, discuss, and decide, conveying orders via voice and text information. Unlike Uber, the military command and control systems do not have a core business intelligence model that may go beyond data fusion. There is no analytic model that can reveal, metaphorically speaking, who needs a “fire ride,” where, with what effect, and at what economically viable cost. There is no model to indicate where the balance of forces is favorable or unfavorable, suggesting with high probability avenues of attack or summoning optimally various types of firepower to direct at a specific objective. The situation is even worse since simple data interoperability is still on the wish list. The infamous example is the inability of F-35 fighters to exchange data in real-time with no intermediaries with F16s or F18s.
Value propositions
Civilian industry envy should not be the only reason military platforms should be designed starting from an application-driven operational operations model. The prime contractors should not create kill chains, and the military should not acquire them, only to keep up with Uber. There should be an intrinsic value proposition for this kill chain development and employment philosophy.
There are several good economic and competitive reasons why data models should drive future war-fighting platforms. The first and most important is effectiveness. The current systems, such as integrated supply, maintenance, operations, and replenishment of advanced air or land war platforms that are supposed to work together, require an increasingly large number of specialized staff officers who act as information collectors, condensers, and advisors. King pointed out in Command that the 400-strong staff of a modern US division, as reconstituted after 2014, is five to ten times greater that of mid to late twentieth-century divisions. The increase in staff size is not a mere reflection of bureaucratic bloat. The real culprits are information overload and the intrinsic needs of a command-and-control doctrine. Tradition-bound, these needs reserve most of the analysis and decision-support to human actors.
A new command and control system that relies on data-driven models for analysis and decision-making, while still involving human input, can streamline the decision-making process. This would improve access to information, reduce response time, and minimize confusion and uncertainty. Even more importantly, the model will demand and steer the development of new types of hardware as indicated by the measured effectiveness of the technologies already used. The core kill chain “software” will, in effect, serve two purposes: planning and execution of operations, and an evidence-based guide for future kill chain development.
The second reason for designing systems around operational models is cost. A “software” based kill chain can use many types of hardware, including older ones, as long as they are plugged into the use network. When ordering an Uber ride, it matters little if you get a ride in a Toyota Corolla, a Tesla, or a minivan. Similarly, with a software-driven kill chain, you should be able to use any artillery piece available to put fire on a target if the time, place, and distance to the mission are known. If you get to the destination on time, software-based systems can do more with less, not because they are forced to use less, but because they can integrate many parts that otherwise would not fit in the system, regardless of their provenance or level of novelty. The war in Ukraine shows that such systems already exist. The Ukrainian Armed Forces have an Uber-like fire control system that is more effective than the Russian one, even though the Ukrainians must deal with a bewildering diversity of armament types in smaller numbers. The Ukrainian system is potentially superior through effectively integrating drones, satellite imagery, satellite Internet connections, and maneuverability into a data-driven model that decides which targets are most important to hit and which assets can be mobilized the fastest. Using this system, NATO observers claim to have seen deployment times for Western donated kill chains cut down by a factor of ten. The German PzH2000 self-propelled artillery system typically needs 20 minutes to prepare a fire mission. The computer-drive fire mission process used by the Ukrainians brought it down to under 50 seconds.
The Uber-method of firepower control and operational management relies on a simple yet effective principle: cost-per-effect. The system evaluates the return on investment for each shell, drone, and squad attack. Furthermore, this real-time ROI can be fed back into the design or acquisition of new hardware, whose effectiveness at scale can be evaluated before a penny is paid for its purchase.
The third reason to rethink the development of kill chains is to align the latest doctrine and adversary moves with advanced and pre-emptive solutions. An old dictum says that generals are doomed to refight the last war. This can be prevented if we plan for change and integrate old and new tools and doctrines into a model that improves traditions, retrains learned reflexes, and the upsets the bureaucratic status quo.
A fourth reason for adopting a data drive model for development and deployment is that budgets are tight. Designers of kill chains should not only be penny conscious and but they should abstain from being pound-foolish. The matter of fact is that the profligate ways of developing weapons systems only to be scrapped will soon be over. Huge social expenses, the transition to non-fuel oil energy, and a decreased economic prowess will force the United States to lower its military spending. If Congress does not help, inflation or deficits will.
The fifth reason is that the talent and workforce pipeline has narrowed, the supply chains have thinned, or even disappeared. The US military needs to do more with small forces and staff. The armament industry needs to produce more, but continuously, simply, and efficiently, using a smaller pool of talent and labor. Focusing on quality and applications that integrate various hardware solutions is the only sensible way to do more with less.
Finally, a sixth reason is that a “software-centric” kill chain philosophy is similar to the current software startup culture. Anyone with the skills and modest starting infrastructure can design the next killer app, from Angry Birds (Finnish), TikTok (Chinese), Grammarly (Ukrainian), or BitDefender (Romanian). If any software entrepreneur can launch the next global business with an app and a rented server farm, any nation with a sufficiently talented pool of engineers and coders can also surprise the world with new, integrated, software-driven war-fighting solutions. Turkey’s and Iran’s breakout-out acts in drone warfare are just the beginning of an era. Once either of them or another nation (UAE? Kazakhstan? Finland? Malaysia?) gets the hang of it, new generations of a swarm, heterogenous warfare kills chains, land, naval, or space-based will proliferate.
Battleflow: a data-driven operational model for military platforms
Many of the critiques mentioned above are old, even if clothing them with the more colorful proposition of “software” driven kill chains could make them look relatively new. However, what would a data-driven warfighting model that combines existing and future hardware look like? How could this lord of the rings that would “rule them all” perform its magic? In what follows, we will describe a set of specifications prototyped by our own Battleflow model inspired by fluid dynamics in land warfare and quantum mechanics for air and space warfare.
The model starts with a collection of military units characterized by variables such as strength (component elements multiplied by a firepower unit metric), cohesiveness, spatial footprint, time presence, ability to engage the enemy with direct and ranged fire, speed ranges, and mission goal. The units are arrayed in space according to their effective presence in real-time by GPS or other automatic location sensors. Orders are entered as destinations and mission objectives. Movement is tracked, and battle status (advance, rest, retreat, fire mission execution, etc.) is recorded automatically by sensors embedded in the vehicles and personal gear and verified by direct communication with local commanders. Supplies and reserves are also measured and tracked. Enemy estimates are also included in the model via past or real-time sensing and observation, classified by machine learning and vetted by human intelligence operators.
Based on these fundamental parameters, the model can then identify strong and weak troop dispositions, probability of success in case of attack or defeat in case of defense, burn rates for all consumables for various types of missions and configurations, and most important potential operational opportunities. The analytic steps can be used individually for exploring discrete options or can be brought together to run a fully simulated mission model, including a resolution step indicating the probability of success or failure. The model is, in fact, a data-driven automated staff officer that aggregates, organizes, evaluates, and proposes data-driven solutions for various scenarios.
The model stands out by several features:
- Follows the fundamental military doctrine: fight as one
- Continuous flow replaces discrete agents, dramatically lowering computational costs
- Aggregated group (unit) behavior takes precedence over individual behavior
- All groups are divisible down to their unit components
- Unit movements are a function of determinable factors:
- Measurable cohesiveness and cohesiveness
- Terrain impedance
- Own and opposing firepower
- Measurable morale
- Mission goals
We tested the concept of a continuous flow operational model using as a scenario Pickett’s charge during the Gettysburg battle of July 2-4, 1863. The model included mobile and static units (Confederate and Union) at the brigade/regiment level and ranged artillery fire. As mentioned before, the model can constantly be enhanced with any unit and any characteristics, including armored and mobile units, air or naval assets, or space communication. We preferred this model as a simple and well-documented military engagement with high temporal and spatial resolution.
The model tested a simple scenario, a frontal confederate attack starting from the positions recorded by history. The model created 1000 synthetic battle scenarios, each using the same historical orders with variations of strength and disposition of troops within the margin of error. They all produced attack trajectories for the attacking confederate troops consistent with historical events. Most importantly, given each side’s actual strength and effectiveness, the Confederates only broke through the Union lines and had fewer losses in 60 of the 1000 simulations.
We can easily envision a more complex model describing the initial situation of a battalion, brigade, or division, including various assets and orders that confront any enemy. We can expand the model to joint operations, involving naval, air, and even cyber capabilities. The model can be used before an operation to evaluate choices or during the battle to deploy different types of assets or reserves.
Most important, going back to the original argument of this paper, the model can also predict or test hypotheses about potential assets or technologies that may enhance the effectiveness of future operations. Thus, the design of future kill chain elements restarts with each battle. The possibilities are enormous. The success of such a design and warfighting philosophy depends, however, on a clear-headed assessment and decision to dramatically shift the way we think about the kill chain and military operations.
NOTE
[1] A famous example of mission creep in the design of modern warfighting systems was immortalized by James Fallows’ 1981 book National Defense (1981), which described the development of the fourth-generation fighter jets (F 14-18) after the poor performance of the F-100, 105, and F-4s in the Vietnam war. The Vietnam-era planes were designed to be robust, multi-role platforms. They had large frames and engines carrying a variety of powerful weapons. However, they were sluggish in aerial combat, their mass being sub-optimally supported by their powerplants. The losses relative to their costs and power were substantial. Although the theoretical revolution of Col. Boyd’s energy-mass (EM) theory helped usher in the design of highly maneuverable and lethal fighters, such as F14, 15, 16, and 18, these newer generations of soldiers were constantly plagued by mission creep capability drifts. None of them survived without additions that decreased fighter performance and increased cost. Later, the F35, meant to break the mold, suffered from the same ills.