There is a new defense reform panacea in town: modular, open architecture, easily upgradeable systems. House Chairman of the Armed Services Committee (HASC) Thornberry has adopted this approach to defense acquisitions, adding language to HASC’s version of the 2017 NDAA to require it for every Major Defense Acquisition Program (MDAP).
The desire for greater modularity is a product of the belief that technology proliferation is increasingly putting pressure on the the Department of Defense’s slow acquisition process. However, it is not always true that the ability to quickly upgrade programs is always tied to modular and open architectures. In some cases, both for exquisite and expensive systems, and for cheap, mass-produced system, other options may be more suitable. While modularity can be useful, mandating its use could cause delays, cost overruns, and capability gaps.
For the danger inherent to modular systems, look no further than some previous acquisition programs. The success of the modularity structure for the Littoral Combat Ship (LCS) is decidedly mixed. One of the most important modules, the anti-submarine package, has been plagued with weight and capability problems. In a recent letter of the Chief of Naval Operations, both the chairman and ranking member of the Senate Armed Services Committee blasted the LCS program for long delays to the needed anti-submarine and mine-clearing modules. That these modules and their capabilities were part of the justification of the LCS in the first place makes their failure even more concerning. In fact, the Navy recently canceled the mine-clearing module.
The Distributed Common Ground System was also intended to leverage open architecture and modularity to provide for “rapid integration of new data sources and formats.” Critics of the system have highlighted user frustration and frequent workstation failures in the field. Commanders in the field have even requested off-the-shelf products that are easier to use and more reliable.
Focus on the flexibility to be all things to all missions —general purpose platforms adapted to multiple needs rather than specialized platforms—was the goal behind both the Future Combat System and the F-35 Joint Strike Fighter. The eight types of manned Future Combat System platforms were to “share a common chassis, engine, and other components.” The common design would “reduce the logistics burden” and “lessen the amount of refueling required on the battlefield.” Former Secretary of Defense Robert Gates cancelled the program in 2009, after the Army spent billions on it.
Similar logic was behind the Joint Strike Fighter, with hopes that a common basis for the platform would yield cost efficiencies across the services. Because of the different needs and missions of the services, the final F-35 variants only share 20 percent of their parts, and are being produced well behind schedule and over cost. While neither of those systems were strictly speaking ‘modular,’ they both demonstrate how changes to operational needs can damage the effectiveness of a common foundation.
This is not to say that there are no benefits to using modularity. The B-52 remains a workhorse 60-plus years after the platform was first introduced, due in large part to its adaptability. But the stratofortress is essentially a giant box—allowing easy swap-in-and-out access—and its mission is relatively straightforward. As the LCS, Future Combat System, and F-35 have demonstrated, more complex missions and capabilities are not so easily developed. As complexity increases, modularity may not always be the best option.
For some high-end platforms, modularity may both lengthen development and ignore the realities of how technological change may affect upgrades. Interoperability is significantly harder in open architecture systems, and the DOD will need rigorous requirements and interface standards to make sure that new technologies will work with the old foundation. Because main contractors will have to ensure that any new modules, even those developed by other companies, will be compatible with all other parts and modules, contract price bids may increase to offset the associated costs and risks.
Being too open is also problematic. New technology may be developed in ways that prevent easily replaceable modules. For example, computer development may shift more towards chips specifically designed for a single purpose. Depending on how these operate, upgrading a system may rest on complete restructuring. Sometimes, the best approach may be to build tightly integrated systems quickly and then be able to produce a new version at pace with technical changes.
On the low-end side, modularity may get in the way of mass-produced smaller platforms. In the future, small airborne drones or underwater swarming vehicles may be produced in enough numbers to hit proposed MDAP modularity requirements, but these systems may not always need modularity. Drones that can serve as decoys only need to be produced in sufficient numbers. Changes in technology can be updated at the production line, rather than in post-production. As with exquisite platforms that may need more than skin-deep swaps to properly integrate new technologies, these swarming systems may be hindered by modularity rather than helped.
In fact, mandating modularity may create incentives for the services to pursue single platforms to perform multiple missions. This could introduce risk of single-fault failures, as flaws in a single system could then a wider range of missions. For example, the Littoral Combat Ship’s woes have damaged the U.S. Navy’s ability to undertake close-shore patrols, conduct anti-submarine warfare, and mine-sweep—rather than hindering just one of those missions.
Some of the most important upgrades to a system will be its software, not hardware. These changes can benefit from an initial awareness of upgradeability and development. The hardware side is much more complicated. Agility in progress should certainly be encouraged, but mandates from only one direction should be avoided.