3. Three-Step Software Solutions Analysis
Agencies must obtain sufficient rights to custom-developed code to fulfill both the Government-wide reuse objectives and the open source release objectives outlined in this policy’s pilot program.
In meeting their software needs, agencies must conduct the three-step analysis outlined below. This analysis is intended to leverage existing solutions—consistent with principles of category management21 and shared services22—and suitable commercial solutions, while mitigating duplicative spending on custom-developed software solutions. These steps are consistent with the Office of Management and Budget’s (OMB) long-standing policy on investments in major information systems.23 Moreover, consistent with OMB’s memorandum on Technology Neutrality,24 agencies must consider open source, mixed source, and proprietary software solutions equally and on a level playing field, and free of preconceived preferences based on how the technology is developed, licensed, or distributed.
Step 1 (Conduct Strategic Analysis and Analyze Alternatives): Each agency must conduct research and analysis prior to initiating any technology acquisition or custom code development. The strategic analysis should consider not only agency mission and operational needs, but also external public initiatives and interagency initiatives such as Cross-Agency Priority Goals. Having conducted the strategic analysis, agencies shall then conduct an alternatives analysis, evaluating whether to use an existing Federal software solution or to acquire or develop a new software solution. The alternatives analysis shall give preference to the use of an existing Federal software solution.25
Step 2 (Consider Existing Commercial Solutions): If an agency’s alternatives analysis concludes that existing Federal software solutions cannot efficiently and effectively meet the needs of the agency, the agency must explore whether its requirements can be satisfied with an appropriate commercially-available solution.26
Step 3 (Consider Custom Development): If an agency’s alternatives analysis concludes that an existing Federal software solution or commercial solution cannot adequately satisfy its needs, the agency may consider procuring custom-developed code in whole or in conjunction with existing Federal or commercial code. When commissioning new custom-developed software, agencies must consider the value of publishing custom code as OSS and negotiate data rights reflective of its value-consideration. Agencies must also obtain sufficient rights to fulfill this policy’s objectives related to Government-wide code reuse and the open source pilot program.
Agencies must also consider several factors throughout each stage of the three-step analysis:
- Hybrid Solutions: Solutions containing a mixture of existing Federal, commercial, and/or custom-developed solutions should be considered throughout each step of the analysis.
- Modular Architecture: Agencies should consider modular approaches to solution architecture. As discussed in the Digital Government Strategy, modularity can reduce overall risk and cost while increasing interoperability and technical flexibility.
- Cloud Computing: Consistent with OMB strategy, agencies are encouraged to evaluate safe and secure cloud computing options throughout each step of the analysis.27
- Open Standards: Regardless of the specific solution selected, all software procurements and Government software development projects should consider utilizing open standards whenever practicable in order to increase the interoperability of all Government software solutions. Open standards enable software to be used by anyone at any time, and can spur innovation and growth regardless of the technology used for implementation—be it proprietary, mixed source, or OSS in nature.
- Targeted Considerations: Agencies must select a software solution that best meets the operational and mission needs of the agency, taking into consideration factors such as performance, total life-cycle cost of ownership, security and privacy protections, interoperability, ability to share or reuse, resources required to later switch vendors, and availability of quality support. These considerations should be taken into account during all three steps of the analysis.
- 21 See Transforming the Marketplace: Simplifying Federal Procurement to Improve Performance, Drive Innovation, and Increase Savings, Office of Mgmt. & Budget, Exec. Office of the President, December 4, 2014. https://www.whitehouse.gov/sites/default/files/omb/procurement/memo/simplifying-federal-procurement-to-improve-performance-drive-innovation-increase-savings.pdf. ↩
- 22 M-16-11: Improving Administrative Functions Through Shared Services, Office of Mgmt. & Budget, Exec. Office of the President, May 4, 2016. https://www.whitehouse.gov/sites/default/files/omb/memoranda/2016/m-16-11.pdf. ↩
- 23 See OMB Circular No. A-11, Appendix J – Principles of Budgeting for Capital Asset Acquisitions, Office of Mgmt. & Budget, Exec. Office of the President, July 1, 2016. https://www.whitehouse.gov/sites/default/files/omb/assets/a11_current_year/app_j.pdf. ↩
- 24 Technology Neutrality, Office of Mgmt. & Budget, Exec. Office of the President, January 7, 2011. https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/memotociostechnologyneutrality.pdf. ↩
- 25 Existing Federal software solutions are those for which appropriate rights are already held by the Government, which may include commercial or custom-developed software solutions. ↩
- 26 Preference must first be given to procurement of existing commercial solutions through best-in-class vehicles identified by category management policies. ↩
- 27 Federal Cloud Computing Strategy, Office of Mgmt. & Budget, Exec. Office of the President, February 8, 2011. https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/federal-cloud-computing-strategy.pdf. ↩