Limited functionality available
Military technology still in use long after it was first invented presents four main challenges for organizations looking to maintain their military advantage.
The V-22 Osprey is an extraordinary military aircraft—an operational tilt-rotor craft that can take off, land, and hover like a helicopter, but can fly like a plane. That enables it to take off from an aircraft carrier at sea, fly to a mission site in the mountains, and land without an airstrip, vital for the past decades of military operations. Without the V-22, a critical rescue operation could take more than twice as long—which is disastrous when every second counts. While tilt-rotors were first conceptualized before World War II, it was not until a failed rescue mission in 1980 that the Department of Defense (DoD) saw the clear utility of such a craft. An experimental program in 1981 eventually led to today’s V-22, an aircraft with complex technical challenges that has nonetheless found its way onto US aircraft carriers and bases around the world.1 Still in production today, the V-22 is projected to be in use at least until the 2060s—a full 80 years after the program began.2
Read other content from the Defense innovation series:
Explore the Government and public services collection
Subscribe to receive government and public services content
That lifespan presents a number of challenges. The aircraft will need its supply base to endure for longer than most companies on the S&P 500 exist—let alone the many small businesses that form aerospace and defense supply chains. It will need to be upgraded as technology develops—to put it in context, the precursor V-22 program began the same year IBM coined the term “personal computer.”3 It will need to be sustained as the use case changes—for example, the original plans for the craft estimated it would fly more than it hovers, but operators frequently found utility in hovering for long periods, causing a different set of maintenance needs and replacement parts than expected.4
And, perhaps most importantly, the V-22 will need to remain militarily dominant for the duration of its service life, as suppliers, technologies, use cases, adversaries, and operational concepts change. That is a tall order. The V-22 was designed at the dawn of the personal computer but needs to function well into the age of quantum computing. As technology diffuses faster and faster, keeping an aircraft at the capability frontier means changes to how militaries conceptualize, design, develop, and sustain their platforms. It means tackling four core challenges for military platforms: cost, use cases, mission needs, and technology changes.
The V-22 is not unique in these needs. It is one of dozens of core military platforms that operate on nearly century-long design and service life cycles. The Nimitz-class aircraft carrier, for example, was first designed in the 1950s, while the last ship in the class to commission, the USS George HW Bush, will likely sail until 2060. The B-52 strategic bomber, first flown in 1952, is still in use today.5 Over the course of these extraordinary life cycles, nearly every program executive officer (PEO)—the offices that manage the development and acquisition of military platforms—will likely run into four challenges in keeping the platforms operating at peak capability.
First, the PEO will face a cost challenge. Cost growth is notoriously frequent in defense programs. Though the reasons for cost growth vary, many of them come down to two factors: errors and decisions to change program specifications.6 According to one RAND study, DoD changes to requirements, schedule, and quantity account for more than half of all cost growth.7 But over the course of a platform’s long development and production cycle, some decisions to change requirements can be necessary if systems are to keep up.
Sometimes, the second challenge arises: The very use case of the platform can change. For example, the V-22 and the Littoral Combat Ship have both seen planners and operators use the platforms differently than originally conceived.8 And differences in use case add up. A V-22 that hovers 80 percent of the time, instead of 20 percent, will have a substantially different set of maintenance requirements because different parts will heat faster and longer than others, leading to patterns of wear and tear unexpected in the planning stage. Maintaining and replacing those parts might seem simple, but it requires changes that extend all the way down the supply chain and could lead to different demands on personnel and different patterns of deployment.
Third, changes in use cases can lead to new mission needs. For the V-22, a changing use case—more hovering than expected—can also mean more surface-to-air threats in combat. The increase in threat to the aircraft means that it may need better sensors to understand the threat and better armaments to counter it. At the extreme, it could require a different radar system and a suite of enhanced combat capabilities. But when the DoD requires changes to a platform, it often finds that it lacks the technical data to determine the work and the human capital to do it. It often has no option but to award a modification contract to its original supplier, possibly at a price higher than otherwise achievable in a competitive bidding process. And when the changes to use case mean different patterns of maintenance and operations support, it can lead to further cost growth in those areas as well. Seeing the pattern, suppliers may find incentive to underbid their platforms and make their profits on long-term lock-in. By some estimates, the department spends billions on single-sourced contracts—the motivation for which was a lack of access to the necessary intellectual property.9
Finally, the technology itself is changing at an ever-increasing rate. Over the multidecade life cycle of today’s major military platforms, numerous components, subsystems, and even classes of subsystems will become obsolete. In many cases, new technologies can provide substantial improvements in reliability and/or maintainability, reducing the maintenance costs and improving system availability. In other cases, new technologies can provide new or enhanced mission capabilities which, in turn, can drive new use cases or mission needs. The changing supplier landscape can also drive technology changes. Certain types of parts may no longer be produced and/or supported while, in some cases, original suppliers may go out of business. The computers powering the V-22’s mission systems in 2004, for example, were far less capable than personal computers today. That change in computing power extends beyond just the mission system—because of the increases in computing power available to industry, sensors have become more capable and their data more interpretable. That granularity has, in turn, enabled new ways to combine sensor data with targeting systems. Very quickly, the ramifications of technology change can add up.
The problem is not that changes occur—responses to changes show that the platform is being tested, refined, and optimized. The problem is assuming changes will not occur and designing the process to reflect that.
More data often seems like the simple solution. With more data, the government can experiment, adjust to changing circumstances, and even try new contractors. If a PEO could merely obtain appropriate rights to all the relevant technical data, then the DoD could meet all of the aforementioned challenges. But of course, it’s not so simple. To begin with, even if defense managers today suddenly had access to the reams of technical data that suppliers produce, they likely could not make use of most of it. Second, wherever they could make use of that data, the government would now bear more risk as it took on the complicated process of systems integration. To take on ownership of all the technical data for a system would require wholesale changes in not just how PEOs are organized and operate but also in the very relationship of the government to its major defense contractors.
So short of those tectonic changes, what can be done? How can a PEO craft a more strategic approach to long-term dominance?
The answer isn’t about defining one single answer—it’s about defining a process. Each program should establish a systems governance architecture that entails three steps to enabling genuine competition, shortening product development timelines, and getting what it wants from systems development:
It all starts with data. It is vital to get the necessary data to own the technical baseline. This does not mean owning all technical data, but rather defining exactly what data is needed by what stakeholders and then designing processes that both protect the designer’s intellectual property and make data available for needed analysis.
With technical data available, the challenge then becomes how to make use of that data. To improve performance today and maintain a cutting edge over decades, PEOs should use model-based engineering: the use of digital representations of systems and subsystems in an interactive, whole-of-platform model. For example, full digital twins of Formula One race cars are used to log every mile and test every part and possible configuration, often relying on the model to drive not just engineering decisions but also using digital-twin cars running along to-the-pebble digital twins of race tracks to come up with race strategy.10 Sometimes called the “single source of truth,” a model-based approach enables a holistic path to defining requirements, architectures, and interfaces, to manage systems engineering aspects of a project from birth through the integration and test phases. Doing that requires one to maintain a consistent model of a system throughout its life cycle—one master model that connects the platform’s physical and electrical dynamics to the systems and subsystems it houses—as opposed to having multiple scattered databases and artifacts that capture different aspects of a system’s design. This approach can be brought to mission systems, platforms, software, IT, and the integration of all these systems, and even to performance enhancement once systems have been developed.
There’s just one problem—who is able to own the technical baseline, execute a model-based engineering strategy, and maintain it for decades? Today, different suppliers supply the various components of a system, and a lead integrator combines the parts into one system. The lead integrator assumes the risk of innovation in bringing all those components together. But its reward for that risk is the detailed architectural knowledge of the system that almost makes the integrator the best source for future modifications. So if the government would like more choice in future system upgrades, it needs to rebalance how risk and reward for innovation are spread across the roles in acquisition.
One potential solution is creating the entirely new role of an independent system integrator, a trusted partner for managing and interpreting technical data. An independent system integrator can play multiple roles critical to ensuring long-term competition and flexibility, including:
By holding and processing data consistently, regardless of which contractor is executing the design, development, or modifications, the independent integrator is incentivized to accurately identify trade-offs in design, one of the core challenges in modifying platforms. The greater separation of roles may also allow the DoD to find new sources for new technologies and upgrades, important for both tapping into the boom in commercial innovation and in containing costs via greater competition. With commercial research and development spending nearly triple the amount spent by government, tapping into new sources of technology outside of government will be key to the continued dominance of military systems.11 Ultimately, the likely outcome for the PEO would be more information, and more information leads to more bargaining power and a greater ability to make informed decisions about an uncertain future.
How can the military ensure long-term technological dominance? It is not about having an answer today. The key is actually to expect that all of the conditions, demands, and cases faced by a system will change over time.
By institutionalizing flexibility, the department can achieve better planning up front, from informed capability trades—understanding how design choices will impact capabilities—to improved project feasibility assessment and shortened development timelines. Then it can upgrade faster, improve capabilities, and allow incremental and operational product improvement. Finally, it can increase government bargaining power, break vendor lock-in, and gain access to new sources of new technology.
To start, acquisition leaders should apply the same principles to their own processes:
PEOs are tasked with the near impossible—to design today for the technology of the future, for a fight against a future enemy. By admitting what we don’t know today, and designing processes to account for that, the military can build better platforms for the future fight.