Here is Jason Weiss, the DoD’s first Chief Software Officer, talking with Jared Serbu on the On DoD podcast. Weiss recently left his post after 14 months on the job to go back to the private sector. This is an all too common experience — outside leader comes in, finds out he/she can’t make a difference, and goes back to greener pastures in short order despite wanting to contribute to the nation’s security. Besides lacking much authority outside of the CIO’s office, here are some of the acquisition challenges Weiss faced:
When we talk about modernization, we’re not just talking about technical debt we collected over the last year. We’re talking about ecosystems which, by law because of the colors of money problem – they can use dollars for software sustainment only. When have dollars that by law can be only used for sustainment, that means you can’t even apply a design pattern to modernize part of that application using that color of money. The problems are quite complex. Because they are statutory, as we like to say, a directive never trumps a statute, so your hands are often tied and you have to get creative.
… When we look at the historical scaffolding around how DoD buys systems, it was by and large hardware centric. With aircraft carriers, satellites – the ideals is you only build a keel once on a ship. When we look at software the ramifications of “that algorithm isn’t exactly what I need,” that can be fixed in a two week sprint and a pivot. I think that is fundamental to eliminating color of money issue. And that was codified by the Software is Never Done study from the Defense Innovation Board. That title alone says it, software never goes into sustainment.
When we look at the opportunities out there to demonstrate progress, we have trouble reducing things to bite sized tasks. We want a set of requirements, and say that all of these requirements must be present. We are not capable as an organization to prioritize and recognize that just because something was deprioritized as a requirement doesn’t mean it isn’t important, it just means the warfighter says “I need this first and foremost, then I need this.” Often we have feedback coming into DoD CIO that programs and oversight of programs struggle with this concept. They say it all has to be present or we can’t proceed…
The quality in the software factories I have been exposed to is very high. At this point we’re at 30 software factories that have a name assigned to them, and growing. I can’t speak about all of them, but the ones I speak with regularly, they put out some amazing code that will rival anyone out there. Second, the industrial base plays a key role. It isn’t just government coders writing government code… It has yet to be determined how the primes fit into the software factory ecosystem.
There was a very thought provoking experiment – hack-a-thon – that took place in Nellis Air Force Base that highlighted the problem. If you look at an aircraft, I believe I got the numbers right, 95% of the aircraft is unclassified, 5% is at secret level, but they’re all special access programs. The idea of someone that has a ticket to access the F-35 data, F-22 data, F-18 data, and submarine data, in order to merge those together and do something useful with it – it is not possible today. We don’t have anybody with all of those tickets. That means we are at a disadvantage promoting the software that comes from these factories, use it everywhere, feed those requirements back into the factory if you need a pivot, new API, new way to look at the data. Those lines of communications don’t exist because of the way we silo our programs at the DoD and that’s problematic. It’s not always the quality of the data, but access to the programs that’s a bigger challenge.
Leave a Reply