ALIS box

PENTAGON: Congress has to change the law so the Pentagon can fix its broken process for acquiring software, Ellen Lord said today. It would allow her to launch multiple pilot projects next year. One of those pilots would be used to overhaul the F-35 fighter’s notoriously troubled maintenance system, ALIS.

Ellen Lord

The pilots won’t need additional funding, Lord said. What’s necessary, she said, is a legislative change so each project’s funding can be treated as a single line item, to be used however its managers think best, instead of appropriating one pot of money to be used only for development, another for operations, and a third for sustainment.

“We are asking to have the authority to do some pilots in ’20,” Lord said, “[with] just one line of software development, so we can move back and forth among those stages” — which is how Silicon Valley does it.

Colors of Money

Many of the 26 recommendations in the Defense Innovation Advisory Board’s new study on software acquisition can be enacted under existing law, Lord and board members said, and the Defense Department is already implementing some of those. A full implementation plan will go to Congress in 60 days, Lord promised, addressing everything from talent management to intellectual property rights.

But in at least one crucial area, said the board’s chairman, former Google chairman Eric Schmidt, “it was necessary to have legislative changes as well.”

Eric Schmidt

That’s because current rules enforce a strict separation between “colors of money,” Lord explained: development of new technology, operations using that tech, and sustainment of it once fielded. (She’s simplifying: In fact, there are many more categories than three). Each activity requires its own congressionally-approved line item in the budget, and it’s illegal to use money appropriated for one purpose for another.

That strict separation worked well enough for industrial age weapons programs, which proceeded step by careful step. You have to design a tank before you can build it. It’s disruptive to change that design once you’ve started mass production, and the gas bill to drive it around is clearly separate from what you pay for spare parts or upgrades like a new machinegun. Even on hardware, however, the military is increasingly trying to get feedback from potential users from the start and to upgrade the equipment repeatedly throughout its service life. This new approach to hardware already has required reforms within the Defense Department, most dramatically in the Army.

But without Congress’s help, the Pentagon can’t reform the acquisition system enough to buy software properly. Instead of rigid separating activities in a linear process, the tech industry today develops software in ever-widening spirals that blur the lines between development, operations and sustainment. In fact, the innovation board entitled its study, Software Is Never Done.

In the modern model of Agile Development and DevOps (developmental operations), companies develop a “minimum viable product,” get user feedback, improve it, sell it, and often operate it as a service for their customers, from whom they get more feedback, which helps them fix bugs, patch vulnerabilities, and add new features — over and over and over, not just repeating the steps but overlapping them. So when a user reports a glitch, or a hacker breaks in, and your engineers quickly code a fix that your systems administrators upload within hours, is that development, operations, or sustainment? The answer is “yes.”

“In software, you have a normal process of iteration… it’s more an art than a science… and that process is not available” to the Defense Department, Schmidt said. That means the US military lags, not only behind the private sector, but behind adversaries like Russia and China who have no such scruples about legislative oversight and accountability.

The Pentagon’s current system, Schmidt and his fellow board members said, leads to worst-practice techniques like paying for code by the line — as if software were a physical resource to be stacked in piles like cordwood, the higher the better. (The F-35, famously, has over eight million lines). Instead, the Pentagon needs to follow private-sector best practice by rewarding contractors for how quickly they implement fixes and new features the users want.

F-35 with open weapons bay

Fixing The F-35?

“Software is different from hardware (and not all software is the same),” the report warns. That means the Pentagon needs not only a separate process for acquiring software differently from hardware, but also needs the flexibility to acquire different kinds of software different. Even on a single program like the F-35 Joint Strike Fighter, for example, the code actually embedded in the aircraft, controlling highly classified sensors and weapons, requires a different approach from the mission and threat profiles, which require a different approach from the maintenance and spare parts database.

The F-35’s maintenance and spares software — Lockheed Martin‘s Autonomic Logistics Information System (ALIS) — has been an unshakeable albatross around the program’s neck for years. Rather than simplifying ground crews’ jobs, Air Force Secretary Heather Wilson has said, ALIS requires them to spend an extra 10 to 15 hours a week finding ways to work around it. The Air Force has unleashed its elite Kessel Run team of in-house coders to fix Lockheed Martin’s mess, but that’s a stopgap.

In the longer run, Lord — who oversees all defense acquisition, not just the Air Force — wants to make the F-35, and particularly ALIS, the subject of one of her first software acquisition pilots next year. While the main application of ALIS is for sustainment, Lord said today, “it has tentacles back into development and operations,” making it a good candidate for the new approach.