Defense Innovation Board Chairman Eric Schmidt speaks to reporters on the Board’s final report of the year-long Software Acquisition and Practices analysis at the Pentagon, May 3, 2019. DOD photo by Army Sgt. Amber I. Smith.
The Defense Innovation Board on Friday published its extensive look at the flaws in the Pentagon’s software development processes, and recommended steps to move it away from a 1990s-era view that connects its acquisition to that of hardware.
The Congressionally mandated report, “Software is Never Done,” included 10 main recommendations the board says are key to improving how software is bought and developed to ensure it is effective when fielded.
“DOD still treats software like hardware, and often misunderstands the relationship between speed and security,” the report states. “As a result, a large amount of DOD’s software takes too long, costs too much, and is too brittle to be competitive in the long run. If DOD does not take steps to modernize its software acquisition and development practices, we will no longer have the best military in the world, no matter how much we invest or how talented and dedicated our armed forces may be.”
The key recommendations are:
- Establish new acquisition pathways for software that prioritize integration and delivery in a secure manner, with continuous oversight from automatic analytics.
- Create a new appropriation category for software delivery, which allows it to be funded as a single budget item.
- Establish and maintain digital infrastructure in each service or agency to enable rapid deployment of software.
- Create, implement, support, and use fully automatable approaches to testing and evaluation.
- Create a mechanism for authorization to operate reciprocity within and between programs, services, and agencies to enable more sharing.
- Create software development units in each service, which consist of both military and civilian personnel.
- Expand the use of training programs for hands-on insight into modern software development.
- Require access to source code, software frameworks, and development toolchains for military-specific code.
- Make security a first-order consideration for software-intensive systems.
- Move away from rigid lists of requirements for software programs to a list of desired features and required interfaces to avoid requirements creep, overly ambitious requirements, and program delays.
The board found, during its study, that three themes emerged inside the DOD’s software ecosystem that need to be addressed: speed and time are the most important metrics, software is made by people and for people, and software is different than hardware.
Speaking with reporters during a Friday briefing, DIB Chairman Eric Schmidt said DOD is still approaching software the same way it did in the 1990s, which he called a “huge shortcoming.” While “it worked well back then, it is not appropriate now,” he said. The report lays out how the department should operate today, and emphasizes this new approach needs to be adopted quickly. “We need to address this now,” he said.
Some recommendations have already started to be implemented. The Pentagon’s acquisition chief Ellen Lord said Friday the department is working with Congress on pilot projects involving the new acquisition category. For the fiscal 2020 budget, the department wants pilot software projects written into the proposal with one budget line as opposed to being broken up between research and development and procurement. These will not include additional funding, but instead the same amount of money authorized in a different way to give “administrative flexibility,” she said.
There are bright spots inside the department, including the Air Force’s Kessel Run project. This effort “does not look like any other program office the Air Force has ever seen. That is its great strength. That is its great peril. And that is why it is the future, “ the report states.
Specifically, Kessel Run has a unique organization and culture. It is in a high-tech office in Cambridge, Mass., instead of on a military base. It also works closely with a small business instead of a major defense contractor, and focuses on creating an open and collaborative culture. This has helped the group develop and implement software for Air Force units across the world quickly.
The Board also investigated some of the military’s most problematic software programs. One main example is the F-35’s Autonomic Logistics Information System (ALIS)—servers with convoluted software that gathers and processes flight information for maintenance. It is such a pain for USAF maintainers that Air Force Secretary Heather Wilson in February joked that no airman would name their child Alice after working with the system.
While this system isn’t necessary the military’s largest problem for software, it does embody how a “lot of requirements changing overtime, as well as moving implementation,” can create a problematic weapons system.
“We can learn a lot of lessons from ALIS,” Lord said. “… Things can be improved and we will improve them. We are committed to making ALIS a premiere system.”
Schmidt said the system shows how software was seen inside the military when the F-35 was conceived in 2001, and hasn’t changed enough. The recommendations in the report propose a “material change in the way software like ALIS is done.
Additionally, the F-35 program has touted the complexity of the aircraft’s systems by bragging that it has about 10 million lines of code. DIB member Michael McQuade said Friday this is the wrong way to look at a program. “Never use lines of code to manage a program, in anyway shape, or form,” he said Friday, adding that it encourages paying a contractor by lines of code, which could result extraneous code included in the product. Instead, the military needs to judge the programs on speed and cycle time, he said.