(posted on medium.com, March 12, 2015)
The US Military is a software based fighting force. If software doesn’t work, or is out-of-date or is hacked; planes don’t fly or get refueled, paychecks don’t get cut, weapons don’t get delivered, travel orders get delayed, networks don’t work, maps don’t get shipped and email goes down — leading to less than desirable battlefield outcomes.
Software source code is central to how the U.S. Military fights wars and projects power. Software and source code is not treated as a thing of value in the military: further the management, governance, maintenance and operational reuse of software is an after thought.
The context has changed, radically. Not only has the nature and tactics of our adversaries changed (cyber hacks, suicide attacks, 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), speed and adaptability becomes far more important than in the past, not as a good in and of itself, but as a necessary condition for success. Access to real-time data (and software code), regardless of the application or device used to generate that data, becomes a requirement. Information flow across services and agencies makes (for instance) 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.
Without a sense of the strategic context, discussions about technology acquisitions and development tend to devolve, either into religious wars between rival schools of engineering methodology or turf battles about which processes, rules and regulations should or could be followed. Most of these conflicts about how and what to build are enmeshed in an industrial age acquisition system matured during the Cold War and NASAs race to the moon.
This system was 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. But it made sense: developing military hardware is all about optimizing a design to be cheap to manufacture at a high rate, just like GM, Ford and Toyota do, but software is a different beast. In software: software is never complete, it is always being updated, costs are spread more evenly out in it lifecycle versus hardware systems.
I’m most worried about software since that evolves more rapidly than hardware. The government still uses a hardware-based model to buy software-based systems. Which is the wrong method for software because in hardware systems the design and costs are front-loaded and the design is optimized for large builds, where as software costs are exposed over its entire lifecycle.
The rapid adaptation and evolution of enemy tactics means that when a new capability becomes available to the military, it must be possible to plug in that capability without a massive and expensive and slow 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.[1]
In the software domain, the ability to rapidly modify existing systems in response to unanticipated threats and opportunities depends on access to that systems development supply chain. 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 military advantage. The key part to making any of this possible is access: access to the intellectual property (IP) investments made by the military on behalf of the American taxpayer.
Large companies have know software is a competitive advantage and have taken steps to actively manage its creation, use and dissemination. Companies like General Electric, Amazon, Microsoft, Facebook and Google have released software as open source to ensure they commoditize technologies and markets faster to ensure they always have vendor options and are never locked in or out of opportunities.
This is why intellectually property governance becomes so important, by allowing one military contractor to in effect own the monopoly on that taxpayer funded piece of software, the military is making a big bet that, that one contractor is the best to manage that software line. This limits competition, slows tech progress and drives costs up both total and increases the cost of technical debt. (Technical debt is how much time and effort it takes to change a systems design).
The government (and taxpayer) funds a massive amount of software IP development, which doesn’t effectively get reused. The military needs executive strategic direction describing why intellectual property is important to the Nations defense and more importantly defining how it should be managed to maximize its return on investment for the military. There are a number of tactical methods (e.g., various field manuals and acronyms: Intellectual Property: Navigating Through Commercial Waters, MOSA, FAR, DFAR, etc.), but there is nothing that lays of the strategic imperative for why software IP is a strategic asset to be actively managed.
Organizing Principles
We must rebuild the government and military acquisitions process around how modern software is built. This kills two typical development problems: hardware platforms and software since hardware is the same process, just slower.
Initial design principles:
1. Code is maneuver. Software needs to be treated as something that has as much value as the Soldier, Sailor, Marine and Airman. Their lives depend on how software is build developed, deployed and ultimately updated.
2. Continuous & Speed. Software is never done, it always needs evolving, its use is accelerating and its update cycle is accelerating at the same time. Automation must be pushed as an imperative to ensure maximum speed advantage of technology deployment and supply chain replenishment.
This is important because all successful companies have very clear lines, limits and directions around how company-to-contractor funded IP should be treated.
Too often in the military, taxpayer funded IP around software is treated as something not of value (if it was it would be better controlled).
Note: Jim Stogdill coined the phrase “Code is Maneuver”http://limnthis.typepad.com/limn_this/2007/09/in-cyberwar-cod.html
[1] Ref: The DoD SoftwareTech News June 2007, Vol. 10 # 2, COTR Warriors: Open Technologies and the Business of War