The Air Force Digital Century Series: Beyond the Buzzwords
Available Downloads
THE ISSUE
The United States Air Force’s (USAF) plan to acquire next generation fighter aircraft hinges on three buzzwords: agile development, open architecture, and digital engineering. Although none of these concepts are new to the acquisition community, their successful implementation in a large program would be. To move beyond these buzzwords and overcome past barriers to their implementation, the USAF’s proposed Digital Century Series will need to strictly adhere to a rapid and repeatable schedule. While managing the Digital Century Series on such a schedule will likely have costs, the potential benefits are worth exploring.
INTRODUCTION
The new USAF strategy for acquiring next generation fighter aircraft departs radically from the approach used to field today’s F-35 and F-22. Change is certainly understandable, since both programs experienced substantial cost and schedule growth during development.1,2 This growth can be attributed, at least in part, to acquisition strategies that fielded multiple revolutionary capabilities simultaneously instead of in incremental blocks or on separate aircraft.3,4 Even post-development, today, the aircraft are costly to sustain and upgrade, and their high initial development costs represent only a fraction of their total life- cycle cost.5 With its proposed Digital Century Series, the USAF seeks to rewrite the F-22 and F-35’s history by drawing on lessons from the more distant past.
In contrast to today’s fighter aircraft, the original 1950s-era Century Series was characterized by rapid development, groundbreaking innovation, and sometimes by failure. The original Century Series produced at least 10 new designs that included the first supersonic fighter, the first tactical aircraft to carry nuclear weapons, and the first aircraft designed to truly integrate radar and weapons systems into the design concept.6,7 Despite this innovation, timelines to field new designs were rapid: prototypes sometimes flew within five years of development start,8 and over 5,000 aircraft were produced in one decade.9
The Century Series’ speed may have been enabled, at least in part, by a willingness to accept failure. At least four new designs were developed but never produced,10 and several designs that were produced suffered substantial combat and accidental losses.11 Yet despite these failures, the original Century Series demonstrated that—in the face of technical and requirements uncertainty—rapid parallel development projects offer flexibility and the confidence that at least some technology can be used on future systems.12
Today, the USAF characterizes the Digital Century Series in terms of a “holy trinity” of agile development, open architecture, and digital engineering.13 But as was discussed at the Air Force Association’s 2019 National Convention, the Digital Century Series is more than just a series of buzzwords. My understanding of the USAF’s plan to implement and integrate these buzzwords—as well as that plan’s potential—are described in more detail below.
Although this plan shows promise, the Digital Century Series will be challenged to meet its potential. Specifically, while none of the buzzwords are new to the Department of Defense (DOD), their successful execution together in a large program would be. More importantly, moving beyond those buzzwords will require more than just overcoming the historic barriers to their implementation. As envisioned by the USAF, it will also require integrating the buzzwords through an acquisition strategy that emphasizes strict adherence to program schedule. This strategy depends on rapid and predictable technology development, short design lives, and a willingness to retire systems from operations quickly and on schedule. This proposed focus on schedule— potentially at the expense of cost and performance—is what that truly distinguishes the Digital Century Series from the F-22 and F-35 that preceded it.
AGILE DEVELOPMENT
Agile development—a strategy characterized by rapid responsiveness to changing requirements and small, cross- functional development teams—is most frequently used for software.14 Institutionally, however, the DOD struggles with agile software for several reasons.15 First, the DOD’s requirements process is lengthy and typically occurs only once, at the beginning of a program. Second, agile teams break a system’s development into small chunks and prioritize the rapid delivery of some capability over the complete delivery of all capabilities. Third, the capabilities delivered in each agile “sprint” are often not predicted well in advance, making it hard for DOD budgeters to allocate and assess the effectiveness of their investments. Finally, agile development tolerates failure by allowing developers to correct and upgrade software in subsequent spirals. This, too, is at odds with a risk averse DOD acquisition culture.
That said, the USAF recently established multiple agile software programs,16 and both the DOD and Congress support more widespread use of agile development practices.17 But with the Digital Century Series, the USAF takes agile development a step further and suggests developing both software and hardware agilely.18 Agile hardware development will require an even more drastic departure from traditional DOD norms than software.
With agile software development, engineers build off an initial baseline code. That original code evolves during each sprint, as engineers apply bug fixes to correct deficiencies or upgrade capabilities to meet new requirements. With hardware, the concept of concurrency—when production begins before completing development and changes are phased into future production runs or retrofit—is analogous.19
But concurrency, at least as it was problematically applied in the F-22 and F-35 programs, seems to differ from the USAF’s vision for agile hardware development.20,21 With the Digital Century Series, the USAF appears poised to implement corrections and upgrades predominately through new production rather than through retrofits.22
With agile hardware development, it seems that engineers will build off an initial baseline design. As that design evolves during each sprint, engineers will produce new hardware to replace the old. Although both evolve similarly, agile hardware sprints may not be able to leverage past capabilities in the same way that software sprints do. Instead, engineers may leverage past designs by reproducing, rather than retrofitting them. Furthermore, agile hardware development may also have a higher cost of failure if new designs fail to transition into operations. In these cases, the USAF may choose to abandon new capabilities and continue producing replicas of older ones.
Although it may be possible to achieve the same benefits of agile development on hardware as in software—namely flexibility and speed—the process for hardware will look much different.
Given these potential costs, the USAF should consider mitigation opportunities that shift functionality from hardware to more easily upgradable software.23 The DOD and Congress should also recognize that although it may be possible to achieve the same benefits of agile development on hardware as in software—namely flexibility and speed—the process for hardware will look much different. Sometimes that process will involve a poor design that fails to transition into operations or a great design, which is hastened into retirement by the onset of a new sprint.
OPEN ARCHITECTURE
Like agile development, open architecture is also not new to the DOD; in fact, DOD 5000-series policies mentioned open architecture as early as 1996.24 More recently, in 2013, the DOD emphasized open architecture in Better Buying Power 2.0,25 and in 2015, Congress encouraged the DOD to adopt Modular Open Systems Approaches (MOSA) on all applicable programs.26 MOSA aims to develop modular systems with standardized interfaces in order to enable future upgrades. By sharing interface standards with a community of potential developers, MOSA “opens” a system up to competition; theoretically, that competition will reduce upgrade cost and incentivize innovation throughout the life of a program.27 Openness also theoretically reduces the time and cost to design, integrate, and test upgrades, since modules isolate changes within systems and common standards enable processes to be reused across them.28 Unfortunately, although exemplar cases exist in the private sector (e.g., smart phones), fewer success stories exist in the DOD.29
Several cultural and structural barriers hinder the use of MOSA within the DOD. First, to modularize and standardize systems, engineers often trade current performance to preserve the option for future upgrades and interoperability. This practice is at odds with the DOD’s preference for designing systems that are optimized to meet predetermined performance requirements. Second, to ensure that interfaces are indeed standardized, MOSA requires careful intellectual property (IP) management—an acknowledged DOD challenge.30,31 It may also require the DOD to take a more active role in defining and managing the subsystem and component interfaces of its systems—a responsibility that the DOD historically delegates to its contractors.
Defining and managing so many open interfaces will require more technical, acquisition, and IP personnel than has been typical for past programs that heavily relied on contractors.
Finally, projects that implement MOSA may struggle to incentivize contractors to develop open architectures in the first place. During operations and sustainment (O&S), the government often has few options to work with contractors other than those that built its original system. As a result, the government loses it bargaining power, and contractors lose the incentive to control costs.32 Open architectures, however, enable the government to compete contracts for system upgrades and, theoretically, to get a better deal. The trick to implementing MOSA is incentivizing contractors—which benefit from vendor lock-in during O&S—to design architectures that could potentially reduce their life-cycle profits.
With its plan to compete not only module contracts but potentially platform and system integration contracts as well, the Digital Century Series’ proposed open architecture will be even trickier.33 The DOD rarely implements this degree of architectural openness; therefore, the USAF will be challenged to align incentives between integrator, platform, and module contractors throughout the series life-cycle. It will also be challenged to ensure that all relevant interfaces remain truly open and standardized. To overcome these challenges, the USAF can borrow implementation strategies from other programs that have implemented MOSA; Navy submarines, for example, may be a useful source of lessons learned.34 Generally though, the USAF should also recognize that defining and managing so many open interfaces will require more technical, acquisition, and IP personnel than has been typical for past programs that heavily relied on contractors. The DOD and Congress, in turn, should ensure that the USAF allocates a sufficient number of government personnel to support the Digital Century Series’ program office.
DIGITAL ENGINEERING
Although digital engineering is the newest buzzword in the Digital Century Series’ “holy trinity,” it appears to derive from—and apply new technology to—concepts that are already well established within the DOD. Through digital engineering, the USAF plans to simulate and optimize the process of producing, upgrading, operating, and maintaining new systems.35 In this way, digital engineering applies modern modeling and simulation (M&S) capabilities to design systems for “-ilities”: characteristics like reliability, manufacturability, and upgradability that indirectly relate to system performance but that can significantly impact life- cycle cost.36
As described above, when the DOD develops systems, it typically prioritizes performance requirements—which provide immediate demonstrable benefit—over “-ilities” requirements, whose benefits are not realized until later in the life-cycle. For example, commonality was an “-ilities” requirement for the F-35.37 Commonality, the sharing of common parts across multiple variants, can create cost savings later in the life-cycle by enabling economies of scale and by allowing multiple systems to share O&S, testing, and training infrastructure.38 Despite the program’s mandate to create three aircraft that were 70-90 percent common, the F-35 achieved only 20-25 percent commonality.39,40 The DOD’s preference for prioritizing the services’ unique performance requirements over an “-ilities” requirement contributed to the common design’s divergence and ultimately to the program’s cost growth.41,42
Although the joint nature of the F-35 certainly exacerbated the DOD’s tendency to prioritize performance over “-ilities” requirements, the example still provides an important cautionary tale.43 When using digital engineering, the USAF should recognize that no amount of M&S will diminish its institutional tendency to prioritize performance over “-ilities” requirements. Instead, it should use its new M&S capabilities to more accurately assess trade-offs between performance and “-ilities” and to identify options where those trade-offs are more institutionally palatable. Finally, the USAF should also use digital engineering to explore life-cycle cost trade-offs, particularly between historic strategies that fielded large fleets of common aircraft and the Digital Century Series’ alternative plan to field smaller non-common fleets.
The USAF should also use digital engineering to explore life-cycle cost trade-offs, particularly between historic strategies that fielded large fleets of common aircraft and the Digital Century Series’ alternative plan to field smaller non-common fleets.
BEYOND THE BUZZWORDS, A STRICT ADHERENCE TO SCHEDULE
More significant than the DOD’s tendency to trade “-ilities” for performance is its propensity to sacrifice schedule for everything else. Schedule requirements, for example, are not documented as early or as thoroughly as requirements for performance or cost.44 DOD program oversight, which requires cost to be independently estimated and evaluated during each milestone review, focuses predominately on cost rather than on schedule.45 Congress does the same with its Nunn-McCurdy Act, which defines thresholds for cost growth, which, if exceeded by an acquisition program, trigger a detailed secretary of defense-level review to restructure, reform, or cancel the program.46 Taken together, these factors create a culture that focuses on performance and cost rather than on executing programs according to rapid, repeatable schedules.
To move beyond the Digital Century Series’ buzzwords, its program manager will need to do the opposite, since the program’s rapid and repeatable schedule is what creates the opportunity to finally overcome past barriers to implementation. The USAF envisions developing new designs every five years, making five years the length of the program’s agile development sprints. Open architecture will make it easier to incorporate capabilities that are developed during each sprint, and digital engineering will optimize the process of integrating, producing, and testing new designs. The USAF expects this process to be so efficient that one squadron worth of planes will be produced in a single year.47
By strictly adhering to this schedule, the USAF envisions that the Digital Century Series can shift contractor incentives to favor its acquisition strategy. In this vision, first, the program will reduce guaranteed O&S profits by shortening aircraft design life and by competitively awarding contracts for each new design. Under such circumstances, contractors may be less incentivized to develop the propriety “closed” designs that lock-in the DOD to the original manufacturer during O&S. Companies may even find that “open” designs enhance their ability to compete for future contracts. Second, the USAF plans to increase research and development (R&D) and procurement profit potential by enlarging the fraction of program budget that is allocated to these activities.48 This may incentivize contractors to prioritize innovation and efficiency during R&D and production over providing prolonged support during O&S. In this way, the USAF intends for the Digital Century Series’ acquisition strategy to fundamentally shift industrial base incentives away from sustaining old systems and toward developing and delivering new ones.
The USAF intends for the Digital Century Series’ acquisition strategy to fundamentally shift industrial base incentives away from sustaining old systems and toward developing and delivering new ones.
The Digital Century Series’ schedule is critical to making and maintaining this shift. Contractor incentives may align with the acquisition strategy only if the potential for a lucrative contract remains only a few years away. This exists in the USAF’s proposal, where integrator, platform, and module contractors compete for R&D funding every five years. Winners begin full-scale development and aim to transition new capabilities into production within five years. Losers are awarded some lower level of R&D funding, both to fuel innovation that supports future competition and to sustain the industrial base. After five years, only capabilities that are fully mature are transitioned into production, a strategy that rewards successful companies with production contracts and that prevents individual technologies from delaying the entire program’s schedule. As production begins on one variant, R&D begins on the next.
This shift is fragile since the natural state of the industrial base is one where companies profit significantly during O&S. To counter that status quo, the Digital Century Series will need to successfully implement agile development, open architecture, and digital engineering, as well as overcome past barriers to implementation by strictly adhering to a rapid and repeatable schedule. Maintaining that schedule, though, will be costly.
THE COST OF SPEED
As described above, there are opportunity costs when technology that is insufficiently mature is “left behind” when a system transitions, on schedule, into production. There are also R&D and production cost increases that, despite the USAF’s best efforts, may not be recouped through O&S cost savings. Furthermore, O&S itself may cost more, since small fleets cost more per aircraft than large ones.49 There may also be a cost to design quality when—as with the original Century Series—not every new design is worthy of production or operation. And finally, the Digital Century Series may also “cost” both the DOD and Congress by reducing their budget flexibility.
Budget cuts usually lengthen program schedules. Similarly, managing programs according to constant, predictable schedules—particularly in the face of technological uncertainty—requires budget stability. How much budget and stability are required to keep a program on schedule is still an open question. Pending an answer, the DOD and Congress should recognize that without some level funding stability, the Digital Century Series’ schedule may slip. Absent a strict adherence to schedule, contractor incentives may shift back toward the status quo, and the program may lose the momentum necessary to move beyond its buzzwords.
How much schedule speed, certainty, and repeatability are required to execute the Digital Century Series’ acquisition strategy also remains an open question. To further develop its plan, the USAF should explore how sensitive its strategy is to competition frequency, design life, production frequency, contract type, contractor incentives, and number of open interfaces per system. It should then assess feasibility relative to industrial base capacity and the USAF’s own acquisition and operational capabilities. Finally, it should assess the funding and stability required to maintain the strategy’s rapid and repeatable schedule. Although that schedule will likely be costly, the integration of agile development, open architecture, and digital engineering shows potential. In the aftermath of the F-35 and F-22, those potential benefits are—at the very least—worth exploring.
Morgan Dwyer is a fellow in the International Security Program and deputy director for policy analysis in the Defense-Industrial Initiatives Group at the Center for International and Strategic Studies (CSIS) in Washington, D.C.
This brief is made possible by general support to CSIS. No direct sponsorship contributed to this report. The brief is based on discussions at the Air Force Association’s 2019 National Convention. The concept and acquisition strategy described above are not attributed to the author, but commentary, analysis, and critique are.
CSIS Briefs are produced by the Center for Strategic and International Studies (CSIS), a private, tax-exempt institution focusing on international public policy issues. Its research is nonpartisan and nonproprietary. CSIS does not take specific policy positions. Accordingly, all views, positions, and conclusions expressed in this publication should be understood to be solely those of the author(s).
© 2019 by the Center for Strategic and International Studies. All rights reserved.
Please consult the PDF for references.