HomeSoftware

Software Acquisition and Practices (SWAP) Study

 

The FY18 National Defense Authorization Act (NDAA) directs the Secretary of Defense to task the Defense Innovation Board "to undertake a study on streamlining software development and acquisition regulations."

“Software is assessed among the most frequent and most critical challenges, driving program risk on ~60% of acquisition programs.” - Defense Science Board, 2018 Report

U.S. national security increasingly relies on software to execute missions, integrate and collaborate with allies, and manage the defense enterprise. The ability to develop, procure, assure, deploy, and continuously improve software is thus central to national defense. At the same time, the threats that the United States faces are changing at an ever-increasing pace, and the Department of Defense’s (DoD’s) ability to adapt and respond is now determined by its ability to develop and deploy software to the field rapidly. The current approach to software development is broken and is a leading source of risk to DoD: it takes too long, is too expensive, and exposes warfighters to unacceptable risk by delaying their access to tools they need to ensure mission success. Instead, software should enable a more effective joint force, strengthen our ability to work with allies, and improve the business processes of the DoD enterprise.

Countless past studies have recognized the deficiencies in software acquisition and practices within DoD, but little seems to be changing. Rather than simply reprint the 1987 Defense Science Board (DSB) study on military software that pretty much said it all, the Defense Innovation Board’s (DIB’s) congressionally mandated study1 on Software Acquisition and Practices (SWAP) has taken a different approach. By engaging Congress, DoD, Federally Funded Research and Development Centers (FFRDCs), contractors, and the public in an active and iterative conversation about how DoD can take advantage of the strength of the U.S. commercial software ecosystem, we hope to move past the myriad reports and recommendations that have so far resulted in little progress. Past experience suggests we should not anticipate that this report will miraculously result in solutions to every obstacle we have found, but we hope that the two-year conversation around it will provide the impetus for figuring out how to make the changes for which everyone is clamoring.

Our Work

Fix the Department's approach to software

Report Materials:

SWAP Vignettes:

SWAP Concept Papers:

In this report, we emphasize three fundamental themes:

Collapse All Expand All

To maintain advantage, DoD needs to procure, deploy, and update software that works for its users at the speed of mission need, executing more quickly than our adversaries. Statutes, regulations, and cultural norms that get in the way of deploying software to the field quickly weaken our national security and expose our nation to risk.

DoD’s current personnel processes and culture will not allow its military and civilian software capabilities to grow nearly fast or deep enough to meet its mission needs. New mechanisms are needed for attracting, educating, retaining, and promoting digital talent and for supporting the workforce to follow modern practices, including developing software hand in hand with users.

Hardware can be developed, procured, and maintained in a linear fashion. Software is an enduring capability that must be supported and continuously improved throughout its life cycle. DoD must streamline its acquisition process and transform its culture to enable effective delivery and oversight of multiple types of software-enabled systems, at scale, and at the speed of relevance.

To take advantage of the power of software, we advocate four main lines of effort:

Collapse All Expand All

A. Congress and DoD should refactor statutes, regulations, and processes for software, enabling rapid deployment and continuous improvement of software to the field and providing increased insight to reduce the risk of slow, costly, and overgrown programs.

A1. Establish one or more new acquisition pathways for software that prioritize continuous integration and delivery of working software in a secure manner, with continuous oversight from automated analytics

Read More: Draft A1 Implementation Plan

A2. Create a new appropriation category for software capability delivery that allows (relevant types of) software to be funded as a single budget item, with no separation between RDT&E, production, and sustainment

Read More: Draft A2 Implementation Plan

B. The Office of the Secretary of Defense (OSD) and the Services should create and maintain cross-program/cross-Service digital infrastructure that enables rapid deployment, scaling, testing, and optimization of software as an enduring capability; manage them using modern development methods; and eliminate the existing hardware-centric regulations and other barriers.

B1. Establish and maintain digital infrastructure within each Service or Agency that enables rapid deployment of secure software to the field, and incentivize its use by contractors

Read More: Draft B1 Implementation Plan

B2. Create, implement, support, and use fully automatable approaches to testing and evaluation (T&E), including security, that allow high-confidence distribution of software to the field on an iterative basis

Read More: Draft B2 Implementation Plan

B3. Create a mechanism for Authorization to Operate (ATO) reciprocity within and between programs, Services, and other DoD agencies to enable sharing of software platforms, components, and infrastructure and rapid integration of capabilities across (hardware) platforms, (weapon) systems, and Services

Read More: Draft B3 Implementation Plan

C. The Services and OSD will need to create new paths for digital talent (especially internal talent) by establishing software development as a high-visibility, high-priority career track and increasing the level of understanding of modern software within the acquisition workforce.

C1. Create software development units in each Service consisting of military and civilian personnel who develop and deploy software to the field using DevSecOps practices

Read More: Draft C1 Implementation Plan

C2. Expand the use of (specialized) training programs for CIOs, SAEs, PEOs, and PMs that provide (hands-on) insight into modern software development (e.g., Agile, DevOps, DevSecOps) and the authorities available to enable rapid acquisition of software

Read More: Draft C2 Implementation Plan

D. DoD and industry must change the practice of how software is procured and developed by adopting modern software development approaches, prioritizing speed as the critical metric, ensuring cybersecurity is an integrated element of the entire software life cycle, and purchasing existing commercial software whenever possible.

D1. Require access to source code, software frameworks, and development toolchains—with appropriate IP rights—for DoD-specific code, enabling full security testing and rebuilding of binaries from source

Read More: Draft D1 Implementation Plan

D2. Make security a first-order consideration for all software-intensive systems, recognizing that security-at-the-perimeter is not enough

Read More: Draft D2 Implementation Plan

D3. Shift from the use of rigid lists of requirements for software programs to a list of desired features and required interfaces/characteristics to avoid requirements creep, overly ambitious requirements, and program delays

Read More: Draft D3 Implementation Plan

 

The main report provides an assessment of the current and desired states for software acquisition and practices, as well as a review of previous reports and an assessment of why little has changed in the way DoD acquires software, with emphasis on three fundamental themes. The report’s recommendations are broken into four lines of effort, with a set of primary recommendations provided for each (bold), along with additional recommendations that can provide further improvements. Each recommendation is accompanied by a draft implementation plan and potential legislative language.

April 30, 2019:

Software Is Never Done: Refactoring the Acquisition Code for Competitive Advantage (Final SWAP Report)

March 26, 2019:

DIB-SWAP Report Front Matter

DIB-SWAP Report Main Body

DIB-SWAP Report Supporting Information

March 13, 2019:

DIB-SWAP Study Report [DRAFT]

March 6, 2019:

SWAP Study Vignettes

February 22, 2019:

DIB-SWAP Study Report: [DRAFT] Main Body

DIB-SWAP Study Report: [DRAFT] Supplementary Docs

January 11, 2019:

TL;DR: One-Page Summary

README: Five-Page Summary

Sec 805 Draft Possible Language

Data & Metrics Subgroup Input

Preliminary Recommendations for Feedback

Appropriations Subgroup Report

October 10, 2018:

Is Your Compute Environment Holding You Back? A DIB Guide for the Acquisition Community

Is Your Development Environment Holding You Back? A DIB Guide for the Acquisition Community

Defense Innovation Board Case Study Questions

DIB Guide: Detecting Agile BS

Defense Innovation Board Do’s and Don’ts for Software

Version 0.7, last modified 1 Nov 2018

Version 0.6, last modified 2 Oct 2018

July 10, 2018: Defense Innovation Board Metrics for Software Development

April 20, 2018: Defense Innovation Board Ten Commandments of Software

Go to Module Settings to setup module display.

Learn More

Overview: Defense Innovation Board Software Acquisition and Practices Study (SWAP) | Directed by Section 872 of the 2018 National Defense Authorization Act
Overview: Defense Innovation Board Software Acquisition and Practices Study (SWAP) | Directed by Section 872 of the 2018 National Defense Authorization Act
DoD’s systems continue to grow in software size and complexity –Today software enables almost 100% of capability and is a major driver of cost (SEI)
DoD’s systems continue to grow in software size and complexity –Today software enables almost 100% of capability and is a major driver of cost (SEI)
“Every program that’s busted in the Air Force is software  related.”
-Dr. Will Roper,  Assistant Secretary of the  Air Force for Acquisition, Technology and Logistics

“Software is assessed among the most frequent and most critical challenges, driving  program risk on ~60% of acquisition programs.” 
-Defense Science Board, 2018 Report
“Every program that’s busted in the Air Force is software related.” -Dr. Will Roper, Assistant Secretary of the Air Force for Acquisition, Technology and Logistics “Software is assessed among the most frequent and most critical challenges, driving program risk on ~60% of acquisition programs.” -Defense Science... ...More
Fix the Department’s approach to software
Fix the Department’s approach to software
Congress’ Charge
The FY18 National Defense Authorization Act (NDAA) directs the Secretary of Defense to task the Defense Innovation Board "to undertake a study on streamlining software development and acquisition regulations."
FY18 NDAA Sec.  872: Dec 12, 2017
SecDef Delegation  Memo: Jan 2, 2018
A&S  TOR: April 5, 2018
Interim Report to Congress: May 15, 2018
FY18 NDAA Sec. 872: Dec 12, 2017 SecDef Delegation Memo: Jan 2, 2018 A&S TOR: April 5, 2018 Interim Report to Congress: May 15, 2018
DIB SWAP Study Membership
Defense Innovation Board Subcommittee Members
10 Commandments of Software: Study Hypothesis
10 Commandments of Software: Study Hypothesis
Overview: Defense Innovation Board Software Acquisition and Practices Study (SWAP) | Directed by Section 872 of the 2018 National Defense Authorization Act
DoD’s systems continue to grow in software size and complexity –Today software enables almost 100% of capability and is a major driver of cost (SEI)
“Every program that’s busted in the Air Force is software  related.”
-Dr. Will Roper,  Assistant Secretary of the  Air Force for Acquisition, Technology and Logistics

“Software is assessed among the most frequent and most critical challenges, driving  program risk on ~60% of acquisition programs.” 
-Defense Science Board, 2018 Report
Fix the Department’s approach to software
Congress’ Charge
Deliverables
FY18 NDAA Sec.  872: Dec 12, 2017
SecDef Delegation  Memo: Jan 2, 2018
A&S  TOR: April 5, 2018
Interim Report to Congress: May 15, 2018
DIB SWAP Study Membership
SWAP Study Plan
10 Commandments of Software: Study Hypothesis
Twitter
818
Follow Us