Top-Down IT Approach Too Slow To Meet Threats

Cyber warfare has arrived: the Defense Department is under attack, and national security is at stake. Yet in a field defined by rapid growth, DOD arms itself at the same pace with which it buys major weapons, an acquisition cycle of seven to 10 years. The “arsenal of democracy” has already provided the tools for hastening this process in the form of agile methods. The Pentagon has been reluctant to adopt different methods for software than it uses for other acquisitions. But unless it does so, it will lose its edge.

One need only consult the headlines to recognize that cyberattacks are a daily occurrence; attacks on prominent public and private institutions are so common that they barely register. But even if these headlines have lost their shock value, our networks remain vulnerable.

What is worse, far from being immune to cyberattacks, DOD faces greater threats because it is such an attractive target. Not only is it the world’s dominant military force, but it is probably more dependent on information technology than any other military. Fully 90 percent of its weapons systems’ functionality depends on software. This makes DOD a low cost/high reward target that is irresistible to adversaries.

In the 1990s, then-Defense secretary William Perry advocated use of commercial-off- the-shelf goods and services. His initiative extended to software. But COTS software is not the problem. The problem lies with the sort of software that isn’t available from commercial providers. Microsoft does not sell a commercial version of software designed for steering submarines, piloting drones or dropping bombs. For such unique software, the Pentagon must either write its own in house or contract out for such services. And in both cases the process takes far too long.

The reason that bespoke software acquisitions takes so long is that DOD relies on the waterfall method, long been discredited in the private sector. In a nutshell, this is a top-down approach that relies on establishing beforehand what the requirements are. But requirements are notoriously hard to pin down. Customers rarely know what they want up front and requirements change during development. Waterfall imposes the order that the Pentagon brass craves but does so at the expense of price, quality, and (most importantly to cyber defense) speed.

The solution is agile development. Agile doesn’t presume that it is possible to know what customers want beforehand. Instead, it utilizes an iterative process: Customers are given prototypes to tinker with, they provide feedback, programmers adjust the next version accordingly, and then the process starts anew. In this manner, agile eliminates waterfall’s documentation requirements. As waterfall critic Barry Boehm has written, “a prototype is worth 100,000 words.” Problems are identified and fixed early in the process, saving time and money. For 20 years, observers have recommended that Defense officials use iterative methods. The 2010 National Defense Authorization Act specifically mandated agile. Yet apart from using the word “agile” more often (to appease Congress?), little has changed. Waterfall prevails.

That is not because the Defense Department is too big to be nimble. In fact, the U.S. government was a pioneer in iterative methods starting in the 1950s. This included the Army’s artillery command-and-control command system, the Navy’s Trident submarine, the LAMPS helicopter-ship system, and the Air Force’s air defense system. Nor was DOD alone. NASA also used iterative methods to acquire software for Project Mercury, which was the first manned spaceflight.

The problem lies not with laws, but with DOD culture. Although mandated only five years ago, agile has been permissible for two decades. The department is not agile because it has chosen not to be. That is in part because senior procurement officials are more comfortable with waterfall, in part because the department is hierarchical and senior leaders prefer the sense of control waterfall confers, and in part because of ignorance. Mary Ann Lapham of the Software Engineering Institute observes there is still widespread confusion among acquisition professionals about whether agile is legally permissible.

Congress is not blameless. While agile eliminates documentation in favor of prototypes, onerous reporting requirements mean DOD will never be as agile as the private sector. But the Pentagon cultural inertia is still more to blame than is Congress. Because the problem is mainly cultural, tweaking regulations is not the solution. Agile reforms will not work until the culture changes. The front line must know what their options are, understand what agile is, and be committed to applying it. Better laws or regulations, no matter how well-worded, cannot do that.

One final caveat. There is a need for timelier solutions because an acquisition cycle that keeps pace with technology is essential to cyber defense. But danger lurks in the opposite direction. Speed is not everything. Tension may arise between agility and cybersecurity. Sometimes secure systems come at the expense of speed, cost, or quality; a system that is late, costly, or ineffective may be preferable to one that is unsecure. Harnessing agile’s advantages while also recognizing and compensating for its disadvantages will not be easy.

Three things are certain: Speedier acquisitions may not be not sufficient, but such speed is necessary for cybersecurity; agile is faster and cheaper and delivers better quality than waterfall; and doing and being agile will require substantial cultural changes within the Defense Department.