Software Acquisition

AAF  >  Software Acquisition

Software Acquisition


This pathway is to facilitate rapid and iterative delivery of software capability to the user.

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.



Reference Source: DODI 5000.02 Section 4.2


This pathway is designed for software-intensive systems. The pathway objective is to facilitate rapid and iterative delivery of software capability to the user. This pathway integrates modern software development practice such as Agile Software Development, DevSecOps, and Lean Practices. Capitalizing on active user engagement and leveraging enterprise services, working software is rapidly and iteratively delivered to meet the highest priority user needs. Tightly coupled mission-focused government-industry software teams leverage automated tools for development, integration, testing and certification to iteratively deploy software capabilities to the operational environment.

Lifecycle View of Software Acquisition

Software Development Infrastructure, Cybersecurity, and Enterprise Services Design Architecture.  Development. Active User Engagements User Engagement Strategies Assess Value Develop Strategies Define Capability Needs Roadmap Planning Phase Execution Phase Cost Estimate MVP/MVCR

Overarching Policies for the Software Acquisition Pathway

Reference Source: DODI 5000.87 Section 1.2


The overarching management principles that govern the defense acquisition system (DAS) are described in DoD Directive 5000.01 and DoD Instruction (DoDI) 5000.02. The objective of the DAS is to implement the national defense strategy, through the development of a more lethal force based on U.S. technological innovation and a culture of performance that yields a decisive and sustained U.S. military advantage. To achieve that objective, DoD will employ an adaptive acquisition framework (AAF) comprised of multiple acquisition pathways. The AAF supports the DAS with the objective of delivering effective, resilient, supportable, and affordable solutions to the end user while enabling execution at the speed of relevance.


The software acquisition pathway is for the timely acquisition of custom software capabilities developed for the DoD. Software programs that meet the definition of a covered Defense Business System (DBS) should use the DBS pathway in accordance with DoDI 5000.75 but may elect to incorporate this pathway for custom developed software.


Programs executing the software acquisition pathway are not subject to the Joint Capabilities Integration and Development System (JCIDS), and will be handled as specifically provided for by the Vice Chairman of the Joint Chiefs of Staff, in consultation with Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) and each service acquisition executive.


Programs executing the software acquisition pathway will not be treated as major defense acquisition programs even if exceeding thresholds in Section 2430 of Title 10, United States Code. See Section 800 of Public Law 116-92.


Programs using the software acquisition pathway will demonstrate the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated to develop the new software capability. New capabilities will be delivered to operations at least annually to iteratively meet requirements, but more frequent updates and deliveries are encouraged where practical. For programs using the embedded software path, this annual update applies after initial operational acceptance of the system in which the software is embedded and should be aligned with the associated system’s schedule. Before the operational acceptance of the system in which the software is embedded, software deliveries will be delivered to an operationally representative environment at least annually.


Programs will require government and contractor software teams to use modern iterative software development methodologies (e.g., agile or lean), modern tools and techniques (e.g., development, security, and operations (DevSecOps)), and human-centered design processes to iteratively deliver software to meet the users’ priority needs. These modern approaches will also instrument software such that critical monitoring functions related to the health, security, and operational effectiveness of the software can be automated to the maximum extent practicable.


Software development will be done in active collaboration with end users, representing key user groups, to ensure software deliveries address their priority needs, maximize mission impact, and undergo regular assessment of software performance and risk.


Leveraging existing enterprise services, if available, is preferred over creating unique software services for individual programs. These may be procured from the DoD, the DoD components, other government agencies, or commercial providers, and leverage category management solutions and enterprise software agreements.


Cybersecurity and program protection will be addressed from program inception throughout the program’s lifecycle in accordance with applicable cybersecurity policies and issuances. A risk-based management approach will be an integral part of the program’s strategies, processes, designs, infrastructure, development, test, integration, delivery, and operations. Software assurance, cyber security, test and evaluation are integral parts of this approach to continually assess and measure cybersecurity preparedness and responsiveness, identify and address risks and execute mitigation actions.


Intellectual property (IP) will be addressed from program inception throughout the program’s lifecycle in accordance with DoDI 5010.44 and other applicable DoDIs. IP considerations will be integrated with, and support, all other program strategies to ensure return on government investment and enhance competitive options for development, integration, test, deployment, modernization, modular open systems approaches, and product support of software-intensive systems.


Software development testing, government developmental testing, system safety assessment, security certification, and operational test and evaluation will be integrated, streamlined, and automated to the maximum extent practicable to accelerate delivery timelines based on early and iterative risk assessments. Maximum sharing, reciprocity, availability, and reuse of results and artifacts between the various testing and certification organizations is encouraged.


Programs using the software acquisition pathway will report a set of data to the Office of the USD(A&S) on a semi-annual basis as defined in the AAF Software Acquisition Pathway Guidance located at Data reported under this pathway will be used to monitor the effectiveness of the pathway and will not be used for program oversight.

General Procedures

Reference Source: DODI 5000.87 Section 3.1


A rapid, iterative approach to software development reduces costs, technological obsolescence, and acquisition risk.  To allocate resources to the most relevant capability needs, DoD or DoD component leadership will make software acquisition and development investment decisions within a framework that addresses tradeoffs between capabilities, affordability, risk tolerance, and other considerations.  The software acquisition pathway has two phases: planning and execution.  Figure 1 outlines key activities and artifacts of the two phases that enable rapid and iterative software development and delivery.


There are two paths within the software acquisition pathway:  applications and embedded software.  Except where specifically noted, the guidance in this issuance applies to both paths equally.


  • The applications path provides for rapid development and deployment of software running on commercial hardware, including modified hardware, and cloud computing platforms.
  • The embedded software path provides for the rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and other military-unique hardware systems.  The system in which the software is embedded could be acquired via other acquisition pathways (e.g., major capability acquisition).


The DA will document the decision and rationale for a program to use the software acquisition pathway in an acquisition decision memorandum.


Existing acquisition programs may elect to update their acquisition strategy to transition to the software acquisition pathway or use it in addition to their current acquisition pathway.  The PM and applicable stakeholders will identify, and the DA will approve, a transition approach to tailor processes, reviews, and documentation to effectively deliver software capabilities.


Value assessments will be performed at least annually after the software is fielded to determine if the mission improvements or efficiencies realized from the delivered software are timely and worth the current and future investments from the end user perspective.  More frequent value assessments are encouraged if practical.

Why the Software Acquisition Pathway?

Reference Source: OUSD(A&S) Guidance

There is an urgency to modernize DoD capabilities and software is at the heart of most emerging technologies that will shape the future of warfare. Autonomy, artificial intelligence, cyber, and space are all software intensive. Software is driving an exponential increase in system performance and mission impact while decreasing costs and operational timelines. Some key strategic direction include:

National Defense Strategy

“Deliver performance at the speed of relevance. Success no longer goes to the country that develops a new technology first, but rather to the one that better integrates it and adapts its way of fighting. [DoD will] prioritize speed of delivery, continuous adaptation, and frequent modular upgrades. “

Defense Science Board Design and Acquisition of Software for Defense Systems

“The DoD must have the ability to update our systems rapidly.”

Defense Innovation Board Software Acquisition and Practices

“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.

  • Speed and cycle time matter.
  • Faster is more reliable, secure, and possible.
  • Recommend DoD to establish a new software acquisition pathway”

National Security Commission on Artificial Intelligence (NSCAI) report and testimony

“DoD’s regulations are antithetical to prioritizing AI. DoD needs regulatory and cultural change adapted to software that continuously evolves and consumed as a fuel. Our acquisitions are designed for building big systems and monolithic upgrades. We need professionals who know how to acquire software and understand the basic underpinnings of AI.”

FY20 NDAA Section 800

Congress, acting upon these recommendations, directed DoD to establish software acquisition pathways in the FY20 NDAA Section 800. It is among an array of recent software provisions for DoD to adopt Agile practices, modernize software training, and establish digital career fields. Section 800 directed DoD to:

  • Create software acquisition pathways for applications and embedded systems.
  • Programs using these pathways shall not be treated as an MDAP.
  • Programs using these pathways are not subject to JCIDS until the VCJCS, USD(A&S), and Services agree on a new approach to software requirements.
  • DoD shall streamline software requirements, budget, and acquisition processes.
  • Programs using these pathways must demonstrate viability and effectiveness of capabilities for operational use within one year after funds first obligated.
  • Congress further stressed that delivery of increments of useful software capability no less frequently than every six months is not only a best practice for software-intensive systems, but it has also been a standing government-wide requirement for years”

    Transitioning to the Software Acquisition Pathway

    Reference Source: DODI 5000.87, Section 3.1.d

    Existing acquisition programs may elect to update their acquisition strategy to transition to the software acquisition pathway or use it in addition to their current acquisition pathway. The PM and applicable stakeholders will identify, and the DA will approve, a transition approach to tailor processes, reviews, and documentation to effectively deliver software capabilities.


    Reference Source: OUSD(A&S) Guidance

    Software Acquisition Pathway Switching Costs

    Most DoD software acquisition programs were started under previous acquisition models (e.g., old DODI 5000.02 Model 3, Major Capability Acquisition, or Middle Tier of Acquisition). The SWP was designed to have low switching costs given the maximum use of tailoring of processes and reusing equivalent documents for modern software. The SWP is designed to be the ideal, default pathway for software development to balance speed with rigor. The PM and DA will consider many of the following elements in deciding when and if to transition to the SWP. While the middle two columns discuss the typical thought patterns on switching, the right most column outlines measures to reduce switching costs and make it more attractive to transition to the pathway specifically tailored for software.


    More Inclined to STAY with Current Pathway More Inclined to TRANSITION to Software Acquisition Pathway How Services and PEOs can Reduce the Switching Costs
    Value Delivered, Benefits Captured Program is delivering anticipated value efficiently and effectively. Sponsors and users are delighted with results. Program is failing to delivery anticipated value. Sponsors and users are not satisfied with results. Get familiar with the key elements of SWP, Agile, and DevSecOps; embrace culture.
    Documents Program strategy documents are approved and current. Concerned about time and energy to restaff docs for approval and add unique SWP docs.

    Program strategy documents do not reflect current environment.

    DA is PEO or below with limited coord required for new or updated docs.

    Delegate decision authorities.

    Enable transition to SWP yet allow time to update docs.

    Leverage portfolio strategies.

    Requirements Approved requirements documents cover current scope, fairly current, and flexible enough. Requirements are not expected to change. Process to update or staff new req doc is long, unknown, or painful. Doc is old, constrictive, and/or doesn’t reflect the current scope, priorities. Requirements and needs of customers change frequently. Flag-officer board for IT Box approvals isn’t timely/effective. Service has streamlined process to approve CNS. Tailor and streamline CNS content and approvals. Enable transition to SWP yet allow time to update docs.
    Waterfall vs Agile/ DevSecOps mindset Program doing waterfall and (while not ideal) not ready to switch to Agile. Program able to do Agile within current constraints. Current environment constrains my Agile/DSO objectives whereas the SWP offers greater speed, flexibility. Train leadership and workforce on Agile, DevSecOps. Leverage coaches to guide programs and execs.
    Contract Contract was recently awarded and/or contract enables Agile/DSO. Cancelling/revisiting contracts drive huge costs and/or risks. Contract is expiring and/or impedes Agile/DSO practices. Cancelling/revisiting generates lower costs and/or risk. Develop portfolio or Service contracts for SW dev services. Train workforce on effective Agile contracting.
    Contractor(s) Contractor(s) are generally good at Agile or DevSecOps practices. Contractors are flexible to meet the needs of Agile/DSO practices. Contractor(s) aren’t effective in Agile or DevSecOps. Contractors are not flexible to meet the needs of Agile, DevSecOps practices. Rate vendors and compile research of effective SW development vendors. Capture customer, team satisfaction ratings with vendors for future contracting purposes.
    Timing Program just got through a major Milestone decision, documents were approved, and contract awarded. It’s been a few years since program started development. Now is a good time to reconsider approach. Delegate decisions, maximize tailoring and streamlining.
    Break Point Program in the middle of development for a major set of capabilities, infrastructure, contracts, etc. There’s a logical breakpoint upcoming from a scope, functionality, contracts, user base, or time contraint (e.g., MTA program reaching 5-year point). Provide flexibility to scope new development, while completing current efforts.
    Delivery Cadence Low confidence the PMO or contractors can regularly deliver software or have the ability to scope an MVCR to deliver within a year of obligating funds. Program already delivering within an annual cadence or can scope an MVCR to deliver within a year. Aggressively lean functional processes to accelerate software deliveries. Scope smaller MVP, MVCR, releases.
    Service Processes (Req, Cost, T&E, ATO), Oversight Service HQs have not tailored or streamlined processes for SW and still view SW via waterfall/HW lens. Key leaders and HQ staffs unfamiliar with SWP, Agile, and DevSecOps. Service HQs are knowledgeable, have tailored, and streamlined processes for SW with delegated decision authorities. Educate, train, and incentivize functional leaders to shift to customer-centric processes that drive value, lean, and continuously improve processes.
    Degree of Hardware / Software Coupling Tight connections between HW / SW design and / or frequent needs to make tradeoffs across the HW / SW boundary make the overhead of synchronizing separate pathways overly complex. HW and SW are able to be de-coupled and the interfaces between the pathway can be managed effectively. Infuse modern design, architecture, digital engineering, and related practices.
    Insights from SWP Programs If many programs struggle to deliver in SWP with new docs, processes, and roles. If SWP programs operate with greater speed and flexibility to deliver software. Apply above recommendations and continuously improve.

    Defense Business System use of the Software Acquisition Pathway

    Reference Source: OUSD(A&S) Guidance

    Congress directed DoD to “ensure applicability [of the SWP] to defense business systems” in Section 835 of the FY21 National Defense Authorization Act

    This direction was driven by the recognition that commercial-off-the-shelf (COTS) products for DBS solutions are often software intensive and benefit from iteratively delivering capability using Agile and DevSecOps methods.  On the SWP, defense business systems can adopt and tailor critical Business Capability Acquisition Cycle (BCAC) processes while also providing flexibility for continuous delivery of capability.  This SWP hybrid approach can provide relief in multiple areas:

    • Provide greater flexibility and agility with appropriate rigor
    • Accelerate delivery of capability incrementally without delay
    • Reduce the burden of recurring formal ATP events and shift focus on user value
    • Eliminate BCAC decision points for Full Deployment and Capability Support that may be unattainable or unrealistic given that software is never done for DBS programs.

    Any Defense Business System using modern software development practices and adopting an iterative release approach with at least annual software deliveries can benefit from using the SWP.