Tech Views - COTR Warriors: Open Technologies and the Business of War

By J.C. Herz and John Scott*

One of the most widespread military clichés is that amateurs talk strategy while professionals talk logistics. In an information age war against elusive, rapidly evolving adversaries, strategic advantage hinges on a military’s ability to quickly adapt, innovate, and leverage both data and expertise.

Amateurs talk technology. Professionals talk acquisitions. While the essays in this issue of the DACS STN explore aspects of open technology development and open source software from technological, business, and policy perspectives, it is important to understand the strategic context for the military’s shift to open technologies.

Without a sense of the strategic context, discussions about technology development tend to devolve, either into religious wars between rival schools of engineering methodology or turf battles about whose all-singing, all-dancing, “network-centric” ox is being gored. Most of these conflicts about how and what to build are enmeshed in an industrial age acquisition system well suited to the Cold War. This system is set up to build tanks, aircraft carriers and missiles – massive amounts of hardware that take a long time to develop and manufacture – to counter a slow, bureaucratically hidebound adversary that’s trying to do the same thing in the same way. In this strategic context, agility is not that important. What’s important is scale and the threat of overwhelming force, and the current acquisition system delivers in that context.

The context has changed, radically. Not only have the nature and tactics of our adversaries changed (suicide attacks, Improvised Explosive Devices (IEDs), loosely coupled non-state actors, etc.), but the technological state of play in the private sector (where our adversaries source their technologies) has completely transformed in ways that leave military program managers at a loss. The global technology bazaar is driven by highly competitive, accelerated innovation, cheap off-the-shelf hardware and instantaneous communication. While the U.S. government wades through protracted acquisition cycles with large defense contractors, our enemies are shoplifting at Radio Shack.

In this context, where missions depend on perishable tactical intelligence and the disruption of networks (human and technological), adaptability becomes far more important than in the past, not as a good in and of itself, but as a necessary condition for on-the-ground success. Access to real-time data, regardless of the application or device used to generate that data, becomes a requirement. Information flow across services and agencies (for instance, between the National Security Agency (NSA ), a Navy Unmanned Air Vehicle (UAV) operator, and an Army unit), makes non-interoperable systems and proprietary formats a show-stopper. “If only that remote, under-resourced unit had a copy of our company’s software, they’d be able to display the location of the target” is not an acceptable concept of operations.

The rapid adaptation and evolution of enemy tactics means that when a new capability becomes available to the military, it should be possible to plug in that capability without a massive integration effort. Being able to shrink and accelerate innovation cycles and leverage technical expertise across the enterprise becomes a strategic advantage on this kind of battlefield. These big contextual shifts, rather than philosophical leanings or new technologies per se, tilt the game in favor of open systems.

Because terms are malleable, it is important to define “open technology,” in a strategic context, as a set of business processes that drive the development of capabilities. While engineering principles are important, ultimately it is business process that determines deliverables. What we get is a result of how we buy things, whether it’s collectibles on eBay or fighter planes.

In the software domain, the ability to rapidly modify existing systems in response to unanticipated threats and opportunities depends on how those systems are acquired, and how (and by whom) their development is managed. Do developers of new capabilities have to use non-proprietary standards, formats and interfaces so that data can be exported and used by other applications? Are technical architectures required to be modular enough to improve or replace components without the exit costs of vendor lock-in? Can code developed on the government dime be leveraged across programs? These are not technology issues, per se. These are business issues, and they drive competitive advantage.

In the defense sphere, this competitive advantage plays out on the battlefield. In the private sector, it plays out in the marketplace, where open source technologies are increasingly seen as a competitive edge. Corporations running on open source infrastructure range from technology giants like Google, Amazon and IBM to financial services firms like Merrill Lynch and Credit Suisse,¹ the Chicago Mercantile Exchange,² and the ultimate brick-and-mortar behemoth, Wal-Mart.³

These are not undercapitalized start-ups with little to lose – they are global businesses with billions of dollars at stake. Competitively, it makes sense for them to adopt open source infrastructure and to leverage internally developed software across the enterprise. It costs money to reinvent the wheel. More importantly, it costs time, and that’s time a competitor might use to outpace you in the marketplace.

The private sector gravitation to open technologies, and open source software in particular, is a market response to the increased agility these solutions enable, as well as cost savings. Being able to treat open source and proprietary code as modular components that can be improved or replaced within an open architecture mitigates the risk of having to junk an entire system, at exorbitant cost, when next-generation capabilities come along. These same business processes mitigate the risk of “predicting wrong” in the course of a long-term strategic cycle.

Mitigating these kinds of risks is equally (if not more) important in the national security sphere, where long-term acquisition cycles only increase the costs of obsolescence and lock-in. So it’s not surprising to see program managers and acquisition executives gravitating towards open technologies for the same reasons as their private sector counterparts.

For instance, Naval Air System Command uses open source server software to publish Web sites for the Aviation Data Management and Control System (ADMACS) program for aircraft carriers. “We are planning our applications for the next generation of aircraft carriers, which won’t come out until 2015,” explained Tim Woolverton, an ADMACS program manager, “Suppose a commercial vendor goes out of business. We would have to redesign our software to go with some other application. By going with an open-source product, we believed it would be less expensive to make adjustments in the future.”

Significantly, this migration is happening in every aspect of the “ABC” acronym coined by DISA’s General Croom to describe the priority list for how that agency will acquire technologies and capabilities in the future. As summarized by retired Vice Adm. Herbert A. Browne:

The “A” on that list stands for adopt. The general maintains that his agency will do what it can to take advantage of past investments by adopting both what is in the marketplace and what is in the U.S. Defense Department inventory. This approach is at the heart of providing network connectivity to the warfighter.

The “B” is for buy. If the agency cannot adopt something already on the shelf, then it will go to the marketplace and buy what is needed. While this lacks the economic savings of using what is at hand, it nonetheless takes advantage of the efficiency in commercial developments.

If neither A nor B can help DISA carry out its mission, then the agency will employ its “C”—create. Only if all other avenues fail to produce the needed goods or services will the agency generate its own customized solution.⁴

In terms of the “A,” DOD is a large-scale adopter of mature open source technologies (e.g. Linux, Apache, Open SSL (Secure Socket Layer)), which have run the NSA security gauntlet for use on military networks. As Brigadier General Nick Justice, the Deputy Program Officer for the Army’s Program Executive Office, Command, Control and Communications Tactical (PEO C3T) observed at a recent conference, “Open source software is part of the integrated network fabric which connects and enables our command and control system to work effectively, as people’s lives depend on it. When we rolled into Baghdad, we did it using open source.It may come as a surprise to many of you, but the U.S. Army is the single largest install base for Red Hat Linux. I’m their largest customer.”⁵

With respect to the “buy,” open technologies, including open source COTS, are increasingly evaluated on the same footing as conventional proprietary products. “We are not mandating that it’s either ‘open’ or ‘“proprietary’ solutions,” says Chuck Reichers, the Principal Deputy Assistant Secretary of the Air Force for Acquisition and Management.

“We want to pay for unique intellectual property when it’s best of breed, but not succumb to code and vendor-specific lock-in situations. Acquisition of proprietary solutions needs to be a conscience choice, not an assumption. The default should be ‘open technology development,’ where standards and interfaces are open and accessible and best of breed software is utilized, all coupled with the Air Force exercising data rights. Further, we need to move toward an increased competitive, collaborative and interoperable environment across the Services and industry for technology development. This strategy will help to minimize redundant development efforts and enable more agile development and deployment of systems.”⁶

Lastly, when it comes to the “C” of technology development, the Services are running an increasing number of software repositories where government-procured code is accessible to multiple programs, multiple vendors, and end-user communities of interest. The most systematic implementation of this development model is the Navy’s SHARE (Software, Hardware Asset Reuse Enterprise) repository, established in 2006.

Notably, SHARE software assets include code developed by large defense contractors like General Dynamics and Raytheon, which has delivered a complete set of specifications, design documents, source code and user guides for the DDG-1000 Total Ship Computing Environment Infrastructure (TSCEI) with unlimited data rights.⁷ SHARE’s licensing agreement, whereby companies gain access to the repository, ensures that any improvements created on top of SHARE intellectual property flow back to the Navy with government purpose rights.

“The big open architecture policy and the movement the Navy has been [doing]...at first, a couple of years ago, people were skeptical about it,” said James Shannon, program manager for future combat systems open architecture, in a Defense Daily interview.⁸ “But the fact that today we are putting systems that were solely owned or thought to be solely owned by other companies and the fact we have shared them with other companies, I will tell you OA (open architecture) has arrived. We are definitely working to change our Navy business model and we are seeing industry change their business models as a result. They are supporting us in the direction we are going. We take that as a positive sign, and the scope of it is going to get larger. But we think the plans we have in place should be able to handle that larger scope.”

These shifts, born of necessity, are driven by market forces and the relentlessness of a competitive private sector marketplace for technologies that originated in the military but have long since evolved beyond the military’s ability to control. Decades ago, the Defense Department exerted enormous leverage as the primary customer for strategic capabilities (e.g. networking, computing, distributed software systems, wireless and satellite communications), and drove innovation in those domains by virtue of its market power. Today, market power belongs to a global customer base. Networks of software developers programming for open platforms, using open standards, are driving innovation.

Regaining a strategic advantage in this context cannot be accomplished by using the same programmatic mechanisms to buy new and shinier technology, because today’s gee-whiz technology will be a legacy system tomorrow. If the business process doesn’t allow systems to evolve, without lock-in or legal friction, we’re back to pushing a now-obsolete rock up the hill. Meanwhile, our adversaries are tinkering with the next generation of off-the-shelf capabilities.

On a policy level, there is an acknowledgement of this dynamic. Hence the many pronouncements about service oriented architectures and systems of systems, and the vogue for web 2.0 buzzwords in vendor proposals. But the challenge is not to shift the vocabulary – if it were, then widespread use of the words “network centric” and “transformation” and “disruptive” in the acquisition process would have already solved the underlying problems, instead of replicating the status quo with new lingo. Rather, the challenge is to change the way business is done in the trenches of program management and contracting, so that the defaults are open standards, open interfaces, and open data formats.

This is not sexy stuff – it doesn’t make for swooping computer-animated videos filled with sci-fi armaments and booming test explosions. Nor does it lie in the heroic realm of special forces operators and mad scientists. On the contrary, these are shifts in the fine print, lodged in paperwork of eye-glazing length and complexity, shuttled between administrative boiler rooms and corporate cubicle farms. But these changes will make a decisive difference in the technologies we take to war, and the ways we can turn new capabilities to our advantage.

About the Authors

J.C. Herz is a technologist with a background in biological systems and computer game design. Her specialty is massively multiplayer systems that leverage social network effects, whether on the web, mobile devices, or more exotic high-end or grubby low-end hardware.

She currently serves as a White House Special Consultant to the Office of the Secretary of Defense (Networks and Information Integration). Defense projects range from aerospace systems to a computer-game derived interface for next generation unmanned air systems. She supports the CIO of the National Center for Counter-Terrorism in the deployment of next-generation collaborative tools and interfaces for information sharing and knowledge creation in the intelligence community.

J.C. serves on the Federal Advisory Committee for the National Science Foundation’s education directorate. In that capacity, and as a government special consultant to National Science Foundation / Education and Human Resources Division, she is helping NSF harness emerging technologies to drive United States competitiveness in math and science. J.C. was a member of the National Research Council’s committee on IT and Creative Practice, and is currently a Fellow of Columbia University’s American Assembly, where she is on the leadership team of the Assembly’s Next Generation Project. In 2002, she was designated a Global Leader for Tomorrow by the World Economic Forum. She is a member of the Global Business Network.

John Scott is a senior executive at Radiant Blue Technologies and leads the Defense Department’s Open Technology Development (OTD) initiative, sponsored by the Office of Secretary of Defense Advanced Systems & Concepts. OTD lays the groundwork for streamlined adoption of open source methodologies within DoD, which includes both the adoption of private sector open source software and the formation of internal communities of interest around DoD systems, including classified systems. The impact of these shifts in policy and business process include not only increased agility for the U.S. military, but also an enhanced ability to securely share capabilities with allies and bring both data and technology to bear in disaster response and humanitarian assistance operations.

In tandem with his work for OSD, John serves as the chairman of the National Defense Industrial Association’s (NDIA) Command, Control, Communications and Computers (C4) division. He also serves as chairman of the Association for Enterprise Architects’ Open Source Software Working Group. John holds a M.S. in Systems Engineering from Virginia Polytechnic and State University as well as a B.S. in Mechanical Engineering from Lehigh University.

Author Contact Information

J. C. Herz: jnhq@yahoo.com

John Scott: jscott@radiantblue.com or johnmscott@mindspring.com

*Supported by the Office Secretary of Defense, Advanced Systems & Concepts. AS&C’s Open Technology Development Roadmap is online: www.acq.osd.mil/jctd/articles/OTDRoadmapFinal.pdf