Air Force considering shaking up its software factories
The Air Force is looking at reorganizing its software factories, one of the leaders in the office that oversees them told FedScoop.
Among the military services, the Air Force has been particularly keen on software factories, which are tasked with quickly and securely developing and delivering new software for the Department of Defense.
The service currently has 16 of them — compared, for example, to the Army’s one — and Air Force leaders are looking at shaking up that enterprise, Maj. Christopher Olsen, military deputy in the office of the Air Force’s chief software officer, told FedScoop Thursday on the sidelines of the VMware Public Sector Innovation Summit, hosted by FedScoop.
“There’s a lot of different opposing views about how we should go about doing that,” he said.
U.S. military software factories, which are government-owned and operated, practice DevSecOps — an approach that combines software development, security and IT operations.
“In the software factory reference design for the DOD, we say it’s a one or more DevSecOps [with] continuous integration, continuous delivery pipelines, producing an application or set of microservices with an emphasis on automation. So automated tools, automated processes,” Olsen said during a panel at the summit.
One question that needs to be answered is how many software factories the Air Force should have.
“I don’t know which one’s the right number,” Olsen said. “There’s probably some mix of, you know, do you want to have a software factory per capability area or mission area? Or do you want to have … one software factory and it’s just got many different functional specialties? I don’t know what the right answer is. But that’s something we’re trying to figure out currently.”
For example, the Air Force could choose to have one for intelligence, surveillance and reconnaissance, another for command and control, and others to singularly focus on other key areas.
“Do you want to do like that?” Olsen said. Or “do you … just want to kind of let it be this organic, innovative ecosystem where when an organization feels like it needs a software factory, they can stand it up? Or do you want to consolidate? Those are the kind of tradeoff decisions that leadership has to make.”
Other key questions identified by Olsen include: What should the training pipeline look like? How should they be funded? And how should work be divvied up between software factories and traditional program offices?
He declined to provide a timeline for when these decisions will be made.
During the panel, Olsen noted another key issue facing the DOD: figuring out the best way to divvy up work between military software factories and the defense industrial base.
“We found in the chief software office that those factories are great at solving problems with software that are within a certain kind of criteria, a certain scale, certain size,” he said.
As an example, he pointed to the work that Kessel Run is doing producing software for air operations centers.
“That’s a niche area [for] specific missions, specific capability. And it’s a great area for a software factory to be in,” he said.
However, the Air Force will never have software factories producing all the software and doing all the software engineering for a major acquisition program like the F-35 joint strike fighter. That work is better suited for the defense industrial base, he asserted.
However, there may be some gray areas where it’s less clear cut, he suggested.
“I think that what the challenge the department is going to have going into the future is putting in place the institutional mechanisms to decide what work is appropriate for a software factory, and what work is appropriate for going through the traditional contracting process to be done at the defense industrial base” level, Olsen said.
