Typically, a small percentage of the overall profit on a major defense system comes from software development. At the same time, the future upgrade and maintenance contracts for a software-intensive system can provide an open-ended source of future revenue. This is analogous to losing money on each laser printer sold but making big profits on the toner cartridges. This gives contractors a strong incentive to erect barriers to sustainment competition that all too often also function as barriers to efficient upgrades and modernization.
The DoD would prefer that all software be modular, reusable, and open to enhancement by third-party vendors. It is very difficult to write a contract that incentivizes (or requires) the prime contractor to make that happen. Modular design makes it easy for competitors to break the prime’s monopoly on sustainment; reusable code makes it possible for competitors to benefit from the prime’s work and potentially to gain access to their proprietary technologies.
The services are sometimes complicit here—for example, by waiving statutory requirements for modular open systems architecture (MOSA) on the grounds that requiring MOSA would delay initial fielding and cost too much. Even if this were true, it is a false economy—the delays and costs of fielding subsequent upgraded capabilities often outweigh the original savings. As an example, the AWACS Block 40/45 upgrade program, intended to migrate the hardware and software architectures and applications on the E-3 AWACS aircraft from legacy proprietary systems to new open architecture hardware and software, has now been struggling for nearly 20 years to match the existing operational capabilities of the legacy Block 30/35 aircraft.
Admittedly, it is hard to write requirements for modularity, openness, and data rights that are verifiable at the time of system delivery and that actually make it likely that future upgrades will be easier and cheaper. This is similar to the problem of writing software quality requirements that are enforceable.
That was from David Tate and John Bailey’s paper for the 2020 Naval Postgraduate School symposium, “Factors Limiting the Speed of Software Acquisition.” Read the whole thing. I think that last part is an interesting thought. Writing requirements for modular open systems and the data rights meaning knowing in advance many details about technologies and objectives — predetermination.
Having perused some of the materials from the sensor open systems architecture (SOSA) consortium, there’s a lot going on and it’s still in flux. It seems like a top-down effort to enforce standards. Rather than opening up participation for competitors, the incumbent contractors which are leading the efforts will be best positioned to work within the architecture. Industry Working Group leaders include GE, Raytheon, Northrop, L3, Harris, Lockheed, and KeyW. Their standards may then boomerang back in contracts.
But that’s how platforms with standard interfaces work, right? Apple iOS and Android have their own global standards for mobile that developers conform to. That seems more efficient when there’s a huge consumer base running interchangeable hardware (smart phones). But when you have a wide variety of sensors and external interfaces, you may not get the same benefit of scaling through a global standard.
In effect, the SOSA working groups are defining the architecture of the next generation of sensors as a kind of pre-planning study. It can be an enormous effort to reach a “global” standard. The problem with global standards is that the take a lot of effort to reach a consensus, and then they become fairly rigid.
This was also interesting:
It is important to note that the majority of software development effort (and cost)—often as much as 80% of total effort—occurs after the system has initially been fielded.
Leave a Reply