WASHINGTON — Software is just as important for space as satellites and rockets, but the process to develop and deploy it needs to become more agile, one of the Air Force’s top acquisition officials said Friday.
“We are very much enamoured with our system engineering processes in the Department,” said Gen. Ellen Pawlikowski, the leader of Air Force Material Command, which oversees technology and weapons research and development, testing, and deployment.
Speaking at an event hosted by the Air Force Association’s Mitchell Institute for Aerospace Studies, the general said that the current software architecture for space systems — and many terrestrial systems as well — depends on a long, arduous process of checks, testing, and reviews, which bogs down the system and leads to delays and cost overruns.
There’s several ways to make the process quicker, including being willing to take risks, said Pawlikowski, who led the Air Force Space and Missile Systems Center from 2011 to 2014.
“We have a zero risk tolerance culture, and in the space business that is true in spades,” the general said. “Now don’t get me wrong. I, like all the other SMC commanders between me and 1999, did not want to be the first SMC commander to certify a launch that failed, so I bowed to the mission assurance gods three times a day and made sure that we were ready to go.”
“However,” she continued. “That risk aversion has caused us to layer checks on top of checks and slowed down our processes to the extent where there’s no way we can speed up. We have to be able to temper our appetite for risk mitigation if we’re going to be able to do this.”
Another big step the military could take is being willing to part with antiquated software systems and replace it with something new, Pawlikowski said.
“We hold onto stuff for too long and then we end up having to try to figure out how to connect a dinosaur to a jet airplane and we slow everything else down,” she said. “You end up with your system being totally bogged down because every time you made a change there were 50 different stovepipe priority software pieces that had to be addressed…Sometimes it’s better to throw the old stuff away. Sorry, but in my opinion that’s what we’ve got to do.”
Finally, the service needs to make sure that the airmen and civilians using the software for missions can test it out and offer feedback while it’s in development, rather than just being forced to use whatever is produced from the acquisition process. Likewise, the coders and builders of the software programs need to stay involved after its deployment, to rapidly answer questions, make changes, and help operators learn how to use it.
“In the space business, some of you will remember way back when it was engineers that were sitting at those command and control terminals and writing code,” Pawlikowski said, noting that now the software developers and software users are two separate groups of people.
“We have to get those barriers out of there, we’ve got to do it,” she said. “We have to empower at the right level, and that has to be at the level of the person who’s going to use the software.”
The general said the Air Force is currently trying to implement some of these ideas for the OCX program — Raytheon’s long-delayed ground control segment for the next generation of Global Positioning System satellites.
Pawlikowski said she’s been pleased by the progress made on OCX. Defense Department digital experts and Raytheon programmers are working more closely than ever, and are rapidly testing and changing parts of code as they go along, rather than waiting for a single big review of the entire program to correct issues.
It’s a mindset that Pawlikowski said she would like to see implemented across the rest of the DoD’s software efforts, noting that the barriers to agile software development are “frankly 90 percent cultural.”
