The Battlefield Cannot Wait for the Next Software Release

Bottom line: software-defined warfare changes the meaning of military modernization. The decisive question is no longer only whether the force can field a new digital capability. It is how quickly that capability can change after the force learns something new.

A vulnerability can appear tomorrow. A drone tactic can change next week. A new sensor can enter the force next month. Communications conditions can shift. An AI model can improve. An adversary can adapt.

Physical platforms may serve for decades. Software operates on a different clock.

The Army’s Next Generation Command and Control effort, or NGC2, is becoming an important test of whether the defense enterprise can reconcile those two timelines.

The Most Important Upgrade May Happen Without Replacing the Platform

Military aircraft, ships, vehicles, radars, and command systems are designed to remain in service for years or decades.

The physical platform changes relatively slowly because replacing hardware is expensive, disruptive, and constrained by manufacturing.

Digital capability can change much faster.

A new algorithm can improve targeting or logistics. A software patch can close a vulnerability. A new data source can improve situational awareness. A better interface can reduce operator workload. A new communications pathway can increase resilience.

This creates a central modernization mismatch:

the military owns platforms designed to last decades while increasingly competing through capabilities that change in months, weeks, or days.

The strategic advantage therefore comes partly from separating the lifetime of the platform from the lifetime of the software running on it.

NGC2 Is Becoming a Test of Continuous Military Software Delivery

The Army established the NGC2 common data-layer baseline on June 22, 2026, following operational validation with the 4th Infantry Division and 25th Infantry Division.

Army officials described the decision as a step from prototyping toward scaled product delivery and said NGC2 is entering a phase of continuous delivery.

Project Convergence-Capstone 6 then provided the next major operational test. Conducted at Fort Irwin from July 20 through July 29, PC-C6 expanded NGC2 experimentation into division-scale force-on-force conditions involving joint forces, multinational partners, unmanned systems, sensors, fires, communications, and other emerging capabilities.

The important point is not that one software release passed a test.

It is that the Army is building an operating model for continuous capability evolution.

Traditional Modernization Has a Release-Cycle Problem

The traditional acquisition model is naturally organized around identifiable systems.

Requirements are established. Development occurs. Testing follows. A configuration is approved. The system is fielded. Major upgrades arrive later.

That approach makes sense for many physical systems.

It becomes problematic when software is managed as though it were another static hardware component.

A command application should not require years to incorporate an operational lesson discovered last month. A counter-UAS system should not wait for the next major acquisition increment to recognize a rapidly evolving threat. A logistics application should not preserve an obsolete workflow because fielded software is administratively difficult to change.

Software-defined warfare requires a different measure:

How quickly can the force change after it learns?

Project Convergence Is Becoming a Learning Loop

Project Convergence is valuable because it places emerging technology into conditions that expose assumptions developers cannot fully reproduce in laboratories.

Operational formations use the technology. Networks become constrained. Users behave differently than designers expected. Electronic warfare creates friction. Sensors provide unexpected data. Workflows that looked reasonable on paper become cumbersome under time pressure.

That is not failure.

It is the purpose of experimentation.

The useful development loop becomes:

build → field → observe → learn → change → redeploy → observe again.

That feedback cycle is fundamentally different from treating the warfighter as the final recipient of a finished product.

The Product Is Never Truly Finished

Commercial software users already expect products to evolve continually. Features change, vulnerabilities are patched, performance improves, and interfaces are refined.

Military software has to achieve similar adaptability under substantially harder conditions:

• classified environments;
• disconnected operations;
• cyberattack;
• electromagnetic interference;
• legacy platforms;
• multiple security domains;
• strict authorization requirements;
• multiple vendors;
• and consequences that can be operationally irreversible.

Continuous delivery in defense is therefore not simply commercial software practice transplanted into the Pentagon.

It requires a military-grade architecture for continuous adaptation with continuous assurance.

The Common Data Layer May Matter More Than Any Individual Application

In June, the Army named Anduril to lead the NGC2 common data baseline, working with Palantir on an edge-to-cloud data mesh and with Raft on data registries, transformation, and federation.

The significance is architectural.

An organization can buy excellent applications indefinitely and remain digitally fragmented if every application creates another isolated data environment.

One system may know friendly-force locations. Another tracks ammunition. Another contains intelligence. Another handles fires. Another receives drone imagery. Another tracks logistics.

If each application structures and stores information differently, developers and operators spend enormous effort rebuilding connections.

A common data layer attempts to reverse that relationship.

Applications become consumers and contributors to a broader operational data environment rather than isolated owners of their own version of the battlefield.

This is a core technology-enablement and enterprise-data architecture problem.

APIs Are Becoming Military Infrastructure

Application programming interfaces sound technical and mundane. Operationally, they determine how easily one system can exchange information with another.

A sensor discovers something. The data enters the architecture. A command application presents it. Intelligence adds context. A fires application evaluates an option. A commander acts. Another system communicates the resulting task.

That sequence may cross multiple vendors, platforms, classifications, networks, and organizations.

The mission cannot depend on engineers building a custom integration every time two systems need to exchange information.

Interfaces therefore become infrastructure.

They determine how quickly new sensors, applications, models, and platforms can enter the force.

Modularity Lets Better Technology Enter Without Rebuilding the Mission

A radar introduced today may be surpassed by another sensor in three years. A better drone may appear. A new AI model may outperform the existing one. A different communications pathway may become more resilient.

If the mission architecture is tightly coupled to the original provider, replacing one component can trigger extensive redesign.

If the architecture is modular, the new component can connect through established data and interface standards.

That turns the force from a collection of fixed programs into a technology ecosystem.

The same principle is visible in the Air Force’s Collaborative Combat Aircraft strategy, where airframes and mission-autonomy software are being deliberately separated. Diamondback’s analysis of how the Air Force is unbundling the fighter examines that architecture in detail.

Across both efforts, the larger principle is the same: the architecture should make future competition and technology insertion easier, not harder.

Continuous Delivery Requires Continuous Testing

Moving faster cannot mean eliminating assurance.

It means making assurance part of the delivery pipeline.

Smaller and more frequent software changes require:

• automated testing;
• security scanning;
• software-composition analysis;
• regression testing;
• configuration validation;
• digital simulation;
• infrastructure testing;
• and operational evaluation.

The objective is to detect problems quickly enough that testing supports delivery speed rather than becoming a separate event months later.

The DoD Software Modernization Implementation Plan explicitly identifies continuous authorization to operate, or cATO, as a priority for reducing one of the most significant barriers to rapid software delivery while maintaining cybersecurity assurance.

Cybersecurity Has to Move at Release Speed

Every software update can introduce risk. Every dependency matters. Open-source packages matter. Development environments matter. Build pipelines matter. Configuration matters.

That means cybersecurity cannot be applied only after development is complete.

Developers, cyber teams, infrastructure engineers, operators, and program leadership increasingly participate in the same delivery process.

The terminology is DevSecOps.

The operational principle is simpler:

a vulnerability discovered on Tuesday should not require a year-long modernization cycle to correct.

This becomes especially consequential when software connects sensors, commanders, and weapons.

Tactical Software Has to Survive the Network Going Away

Commercial software frequently assumes persistent connectivity.

Battlefield software cannot.

Bandwidth may be abundant one moment and constrained the next. Satellite connectivity may disappear. Radios can be jammed. Nodes can be destroyed. A formation may temporarily have only local data.

Applications therefore need intelligent degraded modes.

• Local information should remain usable when enterprise connectivity disappears.
• Data may need to queue and synchronize later.
• Edge services may substitute for cloud services.
• Command nodes may need to move among communications pathways.
• AI applications may need smaller local models when disconnected from enterprise compute.

The design assumption should not be that the network always works.

The mission has to continue when the network does not.

Software Can Change the Physical Command Post

Digital architecture also affects battlefield survivability.

Traditional command posts can require servers, generators, antennas, vehicles, networking hardware, tents, and large staffs. Every component adds setup time, logistics burden, and physical or electromagnetic signature.

On a battlefield saturated with unmanned systems, precision fires, electronic surveillance, and long-range sensing, that footprint creates risk.

More software-defined and distributed infrastructure can reduce the amount of equipment and personnel that have to remain concentrated in one place.

Functions can move among nodes. Data can be distributed. Computing can become more modular. Staff functions do not necessarily have to occupy one large static command post.

Better software architecture can therefore contribute directly to survivability.

User Experience Is a Warfighting Requirement

Military software is often evaluated through technical capability.

Can it process the data? Can the network transmit it? Can the application execute the required function?

The operator still has to use it under pressure.

A soldier managing disconnected applications, multiple passwords, conflicting data, excessive menus, and poorly designed workflows spends cognitive capacity managing technology rather than the mission.

That makes usability operational performance.

The best interface may not display the most information. It may be the one that helps the user understand what matters fastest.

Soldiers Are Becoming Part of the Product Team

Continuous transformation changes the warfighter’s role.

Instead of developers building, acquisition organizations buying, and soldiers receiving a finished product, operators become part of the feedback loop.

They use the capability, expose friction, identify missing functions, and provide operational context. Developers respond. Updated capability returns to the formation.

This shortens the distance between battlefield experience and technical response.

It also produces better requirements because observed operational problems are often more useful than predictions made years before fielding.

This is a natural extension of Diamondback’s diagnostic-driven delivery approach: learn from the operating environment and use that evidence to shape the next iteration.

Contractors Need to Deliver Persistent Product Teams, Not Just Code

Continuous delivery changes the contractor relationship.

A traditional contract may define an application, a delivery date, and a sustainment period.

A continuously evolving mission system requires persistent teams that combine:

• software engineers;
• UX designers;
• cybersecurity specialists;
• data engineers;
• platform and infrastructure engineers;
• test personnel;
• and mission experts.

The government is no longer purchasing only a static artifact.

It is purchasing the ability to keep improving an operational capability.

That requires mission support and workforce models aligned to continuous delivery rather than one-time product creation.

Intellectual Property Can Determine Adaptation Speed

Software-defined architectures create a strategic question: who controls the interfaces, data, and technical baseline?

If government cannot modify a mission system without returning to one original contractor, the architecture may become difficult to evolve. If key interfaces are proprietary, introducing competitors becomes harder.

The answer is not necessarily government ownership of every line of commercial source code.

Commercial intellectual property is an important driver of innovation.

But government needs enough control over mission interfaces, data rights, and architectural rules to preserve the ability to change providers and introduce new technology.

Otherwise, today’s rapid software program can become tomorrow’s vendor lock-in.

Configuration Management Becomes a Battlefield Discipline

Continuous updates create a new operational question:

Which version is the force actually running?

Different units may have different software builds, libraries, sensor drivers, data schemas, security patches, or AI models. In disconnected environments, updates may not reach every formation simultaneously.

The enterprise therefore needs continuous visibility into:

• what is deployed;
• where it is deployed;
• whether it remains secure;
• whether systems remain interoperable;
• and whether an update succeeded.

Continuous delivery without disciplined configuration management can create fragmentation faster.

AI Makes the Delivery Pipeline Even More Important

AI-enabled software may evolve through new models, fine-tuning, updated data, new tools, retrieval sources, prompts, constraints, and operational feedback.

A system’s capability can therefore improve materially without replacing the hardware running it.

But that advantage exists only if models can be:

• evaluated;
• approved;
• distributed;
• monitored;
• rolled back;
• and replaced safely.

This is where AI-augmented delivery becomes an operational pipeline rather than a laboratory activity.

The Adversary Gets Software Updates Too

The United States is not adapting in isolation.

Commercial technology diffuses globally. Open-source tools spread. Combat generates lessons. Drone tactics evolve. Cyber exploits are discovered and patched. Electronic-warfare techniques lose effectiveness as adversaries learn how to counter them.

The side with the best technology at the beginning of a conflict is not guaranteed to retain the advantage.

The advantage may belong to the force able to learn, modify, validate, and deploy faster during the conflict.

Software delivery becomes part of the adaptation contest.

Legacy Systems Still Have to Participate—But Not Forever

No military can discard all existing systems and start again.

NGC2 has to coexist with legacy sensors, networks, applications, weapons, vehicles, and platforms that may remain in service for years.

Adapters, APIs, gateways, transformations, and compatibility layers are therefore necessary.

But integration should not become permanent life support for every historical dependency.

Some legacy systems should eventually retire.

Diamondback’s analysis of why modernization is also deletion addresses the other half of continuous transformation: new capability must be accompanied by disciplined retirement of the systems and processes it replaces.

Continuous Transformation Requires Continuous Retirement

If new software is continuously added while old software remains indefinitely, complexity expands.

Costs rise. Cyber exposure grows. Users support multiple workflows. Interfaces proliferate. Data diverge.

That is not continuous modernization.

It is continuous accumulation.

A mature product model therefore needs another recurring question:

What can now be removed?

Which application has been replaced? Which interface is unnecessary? Which infrastructure can shut down? Which duplicate workflow can disappear?

Modernization succeeds partly through what the organization stops operating.

The Metric Should Be Time to Adapt

Traditional modernization measures remain useful: systems deployed, users onboarded, applications delivered, hardware installed, or contract milestones completed.

A software-defined force needs another metric:

time to adapt.

How long does it take from operational observation to fielded response?

A threat appears. Operators identify the problem. Developers produce a change. Testing and security validation occur. The update reaches the relevant formation.

Months?

Weeks?

Days?

That interval may become one of the most meaningful measures of military technological advantage.

Reducing it is both a strategic modernization objective and an execution problem.

Project Convergence Should Become a Habit, Not Just an Event

Large experimentation events are valuable because they expose systems to realistic failure before those failures occur in combat.

But the deeper philosophy should extend into normal operations.

Exercises should generate software requirements. Product teams should observe operational units. Telemetry should inform development. Users should provide structured feedback. New capability should enter in manageable increments.

The boundary between modernization and operations begins to narrow.

The force becomes a continuously evolving system.

The Future Weapon System Is Never Finished

Project Convergence-Capstone 6 is a useful snapshot of a larger transition.

The Army placed NGC2 into a division-scale environment alongside joint and multinational participants, unmanned systems, sensors, communications, and other emerging technologies. The Army is simultaneously moving the architecture from prototyping toward scaled delivery and continuous iteration.

That is the deeper significance of the effort.

Fielding no longer means the technology is finished.

The battlefield continues changing, so the software has to continue changing.

For contractors, that requires persistent product teams. For acquisition organizations, flexible delivery structures. For cyber teams, faster assurance. For government architects, control of interfaces and data. For operators, a direct role in shaping what comes next.

The United States will continue buying ships, aircraft, vehicles, missiles, radars, and other physical systems expected to remain in service for decades.

Increasingly, however, what those platforms can do tomorrow will depend on software that has not been written today.

In software-defined warfare, the decisive advantage may not be having the best system on day one. It may be being able to become a better system faster than the adversary can.

Primary Sources

• U.S. Army — NGC2 common data baseline and transition toward continuous delivery, June 22, 2026
• U.S. Army — Project Convergence-Capstone 6 announcement and July 20–29 schedule
• U.S. Army — PC-C6 operational experimentation and NGC2 validation
• U.S. Army — Soldiers employ NGC2 during PC-C6
• DoD Chief Information Officer — Software Modernization Implementation Plan FY2025–2026