Software-defined warfare is today’s reality for national security, shifting the emphasis in military operations from hardware to software, “the core of every weapon and supporting system” fielded for defense. The Atlantic Council’s 2025 Commission on Software-Defined Warfare: Final Report defines software-defined warfare as the “continuous integration and delivery of cutting-edge technology and leading interoperable software into legacy and future defense systems.” The report emphasizes the need for speed through artificial intelligence (AI) by calling on national security organizations to “acquire and sustain unified, shared platforms that support and accelerate the end-to-end development, deployment, and governance of AI solutions.”

This blog post examines how software engineering practices can meaningfully address two enterprise challenges for software-defined warfare identified in the Atlantic Council’s report. The first is a shortfall of software pipelines, talent, and resources, and the second is impediments to the use of DevSecOps. Software engineering is the “application of a systematic, disciplined, quantifiable approach” across the lifecycle of software-enabled systems. Over the past four decades, the advances noted in successive versions of the Software Engineering Body of Knowledge (SWEBoK) suggest that software is never done. As software continues to improve, its challenges and opportunities do as well.

Software engineering recognizes the importance of both software code (functional instructions) and architecture (system quality attributes). Although the machine learning (ML) software algorithms for AI systems are different—model-based, able to learn new patterns, and producing output based on statistical modeling—the development and sustainment of those systems is analogous to designing, building, deploying, and improving software-reliant systems.

Software-Defined Warfare, an Evolving Concept

The Department of War (DoW) has long worked toward software-defined control. In the late 1970s, for instance, programs to develop software-defined radios (SDRs) sought to replace incompatible legacy radios with ones that could be configured—and reconfigured—with software. When I served as Commander of the Air Force Research Lab at Griffiss Air Force Base in Rome, New York, our teams developed the first open architecture SDR in the SPEAKeasy (Software Programmable Embedded Architecture) project. SPEAKeasy technology allowed troops to use a single device to communicate with Army, Navy, and Air Force radios, and it was foundational to the later, larger Joint Tactical Radio System (JTRS) programs.

Alberts, Garstka, and Stein described software-defined networking in a 1999 report Network-Centric Warfare: Developing and Leveraging Information Superiority. More recently, DoW’s Project Maven boosted software-defined warfare by applying ML to analyze the tremendous volume of data available. In this decade, the Combined Joint All-Domain Command and Control (CJADC2) initiative emphasizes a comprehensive approach to act “across all domains, and with partners, to deliver information advantage at the speed of relevance.” Today, the DoW is accelerating software-defined warfare with “AI-enabled capability development.”

While critically needed, software-defined warfare is not guaranteed and relies on network connectivity that is both secure and always available. Denied, disrupted, intermittent, and limited (DDIL) environments, a feature of the tactical edge, leave systems vulnerable to cyber-attack and outages. Resilient designs can often overcome this, but there are other impediments, such as a paucity of good training data for AI models, slow procurement processes, a shortage of people with the right skills and expertise, and cultural resistance.

Software Concerns in the Atlantic Council Report

The Atlantic Council, whose commissioners include former DoW officials and software industry leaders, recommends in its report that the DoW “invest in the pillars of software and AI development . . . to empower end users to efficiently generate and operationalize software and AI . . . .” The report poses seven “as is” enterprise challenges to realizing software-defined warfare. This blog post addresses two of them:

1. There is a major shortfall of software pipelines, talent, and resources to meet the demand for software-defined warfare within DoD organizations.
2. The absence of a software-centric culture across the DoD impedes the employment of modern DevSecOps, which fosters rapid iterations and recertifications.

Each Atlantic Council “as is” state is paired with an envisioned “to be” state, leaving a chasm between the two akin to that described in Geoffrey Moore’s Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. In Moore’s analysis, a chasm exists between early adopters (enthusiasts) and early majority users (pragmatists), with the latter being the larger (and more profitable) group to win over. For the DoW and national security, the chasm can be seen between innovations from science and technology (S&T) research prototyping and the establishment of programs of record. This blog post suggests that software engineering, with innovative best practices, can bridge the two states for these two challenges.

Meeting the Shortfall of Software Pipelines, Talent, and Resources

If the DoW cannot meet this shortfall, it risks being unable to build reusable capabilities that develop, deploy, interconnect, and govern software and AI solutions rapidly and at scale. The report’s “to be” state calls for a combination of training in software and AI literacy, targeted recruitment, career path development, and engagement with commercial software firms.

How Software Engineering Mitigates Risk, Accelerates Time to Value

Software engineering lessens DoW’s risk by accelerating the “time to value” for using AI systems through software metrics that emphasize cycle times and ensure interoperability with existing systems. Software engineering can contribute to meeting the shortfalls in pipelines, talent, and resources in the following five ways.

1. Encouraging a holistic view. Because rebuilding infrastructure is costly, disruptive, and resource-intensive, the first step is to fit requirements for an AI system to the mission need and the operating environment. Then, seek quality, relevant, and representative training data for the AI model and enable analysts and operators to identify and report mistakes to improve the system. At all times, pay close attention to security by building in capability to “prevent, avoid, or provide resilience to dangers” because flaws and vulnerabilities can flow across vendor models in the complex AI supply chain. When AI systems fail, security incident response calls for multi-party coordinated vulnerability discovery efforts among data providers, open source libraries and frameworks, model hubs, distribution platforms, and third-party AI distributors (i.e., the capabilities provided by an Artificial Intelligence Security Incident Response Team (AISIRT). Beyond those steps, the holistic view extends to partnering organizations. Those organizations need expertise in (ideally all of) the following: software engineering, systems engineering for software systems, cybersecurity, computer science, AI and machine learning, and federal policy and practice for software acquisition. (“If a team does a poor job of determining the requirements, the project, the product or both are likely to suffer from added costs, delays, cancellations and defects.” —SWEBoK Chapter 1)
2. Measuring cycle time from the first snapshot (commit) to production. With an expanded view of metrics—across model prompt, coding, human or AI agent review, merge, and deploy—AI-supported developer teams can spot and address bottlenecks in programming, testing, and deployment. Those benefits, though, can be lost if monitoring of the AI system does not continue after deployment. AI systems continue to learn and can produce incorrect results unless the systems are retrained. (See SWEBoK Chapter 5 for more on testing and SWEBoK Chapter 9 for more on software engineering management.)
3. Confirming that scalability complements speed. Scalable AI is “the ability of algorithms, data, models, and infrastructure to operate at the size, speed, and complexity of mission needs.” Scalable AI infrastructure—high quality data, reusable pipelines, iterative development (e.g., DevSecOps), and API deployment—can direct the power of AI from data centers to the tactical edge, as long as problems caused by DDIL computing environments are overcome through hardened and resilient architectures. SEI and CMU researchers, for instance, are investigating how to deploy sophisticated analytics on edge devices and extend zero trust architecture to weapon systems operated in DDIL environments. (AI infrastructure and software construction share the goal of producing reliable, efficient systems—SWEBoK—Chapter 4.)
4. Ensuring system interoperability. The DoW should promote the use of flexible standards in code development and a modular architecture approach. Standards such as Future Airborne Capability Environment (FACE) ensure that software is designed for compatibility. A valuable step is the DoW mandate for the use of Modular Open Systems Architecture (MOSA) that extends flexible standardization, allowing “plug-and-play” to add or change modules without system redesign, enhancing interoperability and reducing vendor lock-in. (ISO/IEC/IEEE 12207 (software life cycle processes), for instance, can assure that interoperability is engineered into software-reliant systems—SWEBoK, Chapters 2 and 12.)
5. Defining and developing software competency. The DoW should set qualification and certification standards for its software workforce backed by training and educational opportunities to achieve them. In this respect, software engineers and system designers might borrow from the President’s Cup Cybersecurity Competition, with a focus on identifying and sharpening software talent. (The SEI posted a retrospective of its support for that competition across six years.) Also, the DoW can provide a marketplace where workers can match their skills to mission needs. The SEI published SkillsGrowth, a proof-of-concept platform that allows workers to build profiles based on their expertise. Managers in need of those skills can use those profiles to identify the data/AI talent they need. Those efforts can be fortified by promoting AI literacy to create a common language around AI that encourages collaboration and prevents misunderstanding about AI’s capabilities. (See software engineering professional practice—SWEBoK, Chapter 14).

Overcoming the Absence of a Software-Centric Culture

We examine now the other “as is” software-defined warfare enterprise challenge, which is the lack of a software-centric culture that can effectively employ DevSecOps to support rapid iteration in the development and deployment of systems. The Council’s report notes that, unless the culture is remedied, the DoW will not gain accelerated delivery, reduced cost, secured product, and continuous authorization to operate (cATO) from DevSecOps investments. The “to be” state outlined in the Council’s report envisions a software-centric culture comprising ongoing professional development and talent management, enhanced collaboration with industry, and strong software management leadership.

How Software Engineering Promotes Continual Improvement

The DoW aims to maintain a strategic advantage, which means it must “evolve faster and be more adaptable” than adversaries, by mitigating the potential downside of its successful history, tremendous size, and legacy of traditional systems engineering methods. The DoW has been part of U.S. history since 1789, and the Army, Navy, and Marines date back to 1775, prior to the Declaration of Independence. This long history demonstrates success in ensuring national security. Consider, too, that today’s military represents more than 2.8 million active duty, reserve, and civilian employees, making it the largest employer in the nation. Large organizations with long histories find it hard to be agile, facing the Innovator’s Dilemma. Clayton Christensen’s 1997 book explores why successful companies may fail when faced with disruptive technologies—such as modern software practices and AI. Larger organizations tend to ignore innovations that initially appeal to niche markets (e.g., enthusiasts). At some point, however, those innovations may improve to an extent that they become the preferred ways. By then, these long-standing organizations have fallen behind unless they are able to disrupt themselves and take up the innovations.

To increase organizational agility in a software-centric technology landscape, the DoW could consider the following four actions:

1. Evolving the SWP with an AI-specific sub path for AI-based subsystems. As advocated by the Office of the Under Secretary of War (Acquisition and Sustainment) and the Chief Digital and Artificial Intelligence Office, a Software Acquisition Pathway (SWP) AI sub path would accelerate the deployment of minimum viable capability releases. The extension of the SWP for AI acquisition was a step recommended by participants in the June 2025 AI Acquisition Workshop organized by the SEI. (Chapter 9 of the SWEBoK addresses software engineering management key considerations including acquisition.)
2. Fostering a department-wide digital ecosystem. DoW industry partners use shift-left approaches to deliver “resilient software capability at the speed of relevance.” The DoD Software Modernization Plan and the Atlantic Council report call for a department-wide digital ecosystem to scale advances made in response to the 2019 Defense Innovation Board Software Acquisition and Practices Report. As a result, a software-defined DoW would become agile in acquiring, developing, deploying, and sustaining systems that can respond to emerging threats. (See chapters 6 and 11 of the SWEBoK for information on software engineering operations and methods.)
3. Validating the process. SEI researchers advance the DoW’s vision of creating viable, trusted, and extensible AI systems by leading development of a professional AI Engineering discipline. This discipline refocuses software process on iterative, continuous improvement in development and operation of AI systems. AI Engineering rests on three pillars: robust and secure, scalable, and human centered. Together, those pillars transition AI system development from research prototypes into secure and reliable systems for national security. (Chapter 10 of the SWEBoK details the variety of technical and organizational processes involved in software development and deployment.)

In addition, SEI researchers have been involved in the development of two other certification models that emphasize AI and security. One is the AI Adoption Maturity Model, created in collaboration with Accenture. This model expands on maturity and capability concepts to help organizations use AI technologies more securely since AI systems increase attack surface and invite novel assaults. Because combatting new threats is vital, the SEI and the DoW, in partnership with the Johns Hopkins University Applied Physics Laboratory, co-developed the Cybersecurity Maturity Model Certification (CMMC). The CMMC mandates that defense industrial base (DIB) firms protect Controlled Unclassified Information (CUI) and Federal Contract Information by verifying their adherence to the model’s security requirements. Title 32 Part 170 of the Code of Federal Regulations, which details CMMC, mandates that cloud service providers (CSPs), the majority of which are AI platforms, become authorized to use FedRAMP.

1. Building trust in AI systems. While AI remains a key driver of speed, trustworthiness remains a challenge because AI models are fundamentally statistical approximations and, additionally, algorithms can continue to learn. During deployment, these characteristics, along with an inherent opacity in the largest AI models, hinder the capture of reliable metrics for usability, transparency, and explainability. Humans need those metrics to have confidence in the information AI provides. In addition, an SEI study found that large-language models “are prone to factual errors, hallucinations (i.e., fabrication of new information), overconfidence, and susceptibility to adversarial attacks.” In work for the Under Secretary of War for Research & Engineering, the SEI piloted the Center for Trustworthy Measurement and Evaluation (CaTE) to establish methods for evaluating operator trust and to assure the trustworthiness of AI systems. This initiative published its findings in the Reference Architecture for Assuring Ethical Conduct in Lethal Autonomous Weapon Systems (LAWS) and the CaTE Guidebook for Development and Testing, Evaluation, Verification, and Validation (TEVV) of LAWS to Promote Trustworthiness. (Chapters 3, 4, 12, and 13 of the SWEBoK touch on aspects of software trustworthiness.)

Software-Defined Warfare and Effective Systems for National Security

Sound software engineering for software-defined warfare ensures delivery of resilient AI systems through secure supply chains. The resulting systems will be

• trustworthy in construction, correct in implementation, resilient in the face of operational uncertainties, and updated with assurance
• delivered to warfighters when and where needed—in some instances anticipating the warfighter’s operating tempo
• affordable because their cost (acquisition, development, and operation), despite increased capability, will be predictable and reduced over time (due to value derived from DevSecOps use)
• capable of making new missions possible and improving the likelihood that existing ones will succeed

A fully realized approach for software-defined warfare will be a force multiplier for defense and national security. Assuring that AI-enabled systems provide advantage over the adversary rests on continuing advances in software engineering research, development, and education.