When the world's at stake,
go beyond the headlines.

The Department of the Air Force chief information officer announced a new policy change by sharing a post from a contractor, with the tag, “Strategic shift, operational clarity.”

It is neither.

The Fiscal Year 2018 National Defense Authorization Act directed the secretary of defense to task the Defense Innovation Board “to undertake a study on streamlining software development and acquisition regulations.”

The subsequent Software Acquisition and Practices Study was a fulcrum moment for the defense industrial base. Delivered in May 2019, the report made the case that “software is different than hardware (and not all software is the same).” It reoriented the department around “prioritizing speed as the critical metric…and purchasing existing commercial software whenever possible.” It was taken as a clarion call to change the acquisition enterprise to more closely resemble the ways of building, buying, and consuming modern software.

And from the earliest days, the Department of the Air Force has led the charge.

Air Force digital leaders were the first to issue continuous authorizations to operate, the first to stand up a software factory that put active duty servicemembers alongside industry developers to create software (Kessel Run, also known as Air Force Life Cycle Management Center Detachment 12), and the first to create department-wide shared cloud environments. Along the way, the Air Force threw open its front doors, pioneering the use of the Small Business Innovation Research Open Topics and Direct-to-Phase-II awards, allowing industry partners and new startups with commercially viable products and demonstrated end-user interest to kick off pilots that could eventually transition to scaled deployments and even programs of record.

Recent guidance from the Air Force Director of Administration and Management Nancy Andrews and Acting Deputy Chief Information Officer Keith Hardiman threatens the Air Force’s position as the vanguard of the military’s software ecosystem.

A memo, posted by a contractor on LinkedIn and re-shared by the official chief innovation officer account, is particularly concerning. While the new guidance attempts to regulate how the government will acquire software-as-a-service offerings, it may inadvertently — and severely — kneecap the burgeoning defense software industry.

Let’s start with the positive.

The memo defines software-as-a-service models as an application provided via a cloud interface. Therefore, costs are a function of consumption. Theoretically, this aligns payment with value — a long-desired recognition advocated by modern software startups. If a product is terrible and the government does not use it, it should not pay. When the product becomes indispensable, the company should reap the reward. Of course, there is a challenge, which is that the government does not want to be locked into only one platform. So, it should be able to take the underlying data assets it feeds into or generates within a platform and bring them elsewhere.

So, what’s the problem?

First, it’s simply an unnecessary and duplicative policy. Thanks to the Office of Federal Procurement Policy and the Federal Acquisition Regulatory Council’s “Revolutionary Federal Acquisition Regulation Overhaul,” Part 16 already promotes more innovative and flexible contract types, including consumption-based pricing models. Requiring this model for software-as-a-service just creates definitional challenges that will have companies and the government arguing over whether a product is “software-as-a-service” or just plain “software.”

In attempting to address these concerns by regulating the acquisition of software-as-a-service offerings, the Air Force chief innovation officer makes three crucial mistakes: overly restricting procurement vehicles and centralizing control, overreaching on data requirements, and hampering experimentation and adaptation.

Let’s start with the Air Force’s attempts to streamline procurement. This is likely a well-intentioned effort to address a management issue: The government does not want to procure duplicate technology across the enterprise. So, the memo mandates “independent contracting actions for [Software-as-a-Service] to prevent fragmented procurement via [Contract Line Item Number / Other Direct Cost].” This means that you cannot shoehorn a software-as-a-service subscription into a broader contract or an existing agreement. It requires its own action. This can be seen as a good governance tactic, but as anyone who has worked with a contracting office can report, that is sure to add time and cost money.

The kicker, however, is the very next line. The guidance requires that the Air Force use only the enterprise service catalog, the Air Force-wide digital repository of pre-vetted and approved options, to purchase software-as-a-service. So now, a new software product must be contracted independently (read: cannot be contracted through a channel partner with any kind of integration or testing services attached), but at the same time must already be on the enterprise service catalog.

For a new company that is certainly not in that catalog, the memo creates an opaque process to be added. If a company wants to gain an exception, they can do so through one official only: via direct approval from the Air Force chief information officer.

This centralized control may appear to make sense in a Department of Government Efficiency world where cost controls are tight, but in reality, it is just an onerous bottleneck that will further stunt the transition of current pilots and harm the rapid adoption of new software that can actually reduce cost, waste, and time. Bottlenecks take time and cost money.

Next, the memo tries to address the perceived data accessibility problem with companies such as Palantir. This stems from a belief that government data provided or enriched within a platform somehow becomes less accessible or less fully owned, resulting in vendor lock. It stipulates that the contract should include “the ability to download, migrate, and access said data in a usable format, at no additional cost.”

The challenge here is the definition of “usable format.” Millions of comma-separated value (or CSV) files are technically usable, but not practically so. Picture a company’s spending data: It comes into a platform like Brex, Ramp, or Quickbooks as a bunch of disparate data points, from corporate credit cards, bank transfers, and wires. When it’s on the platform, it’s easy to organize, easily manipulated, and easily understood. The day you delete your account, you still have all those credit card transactions and bank transfers, but it becomes a whole lot less usable. The lack of clarity around this definition helps no one and will create delays and frustration down the line without solving the fundamental problem. Allowing the government to continue to use all new information in the same context in which it’s generated (the platform), even after ceasing to pay, would be a kill-shot to a company. The task of defining where data ends and the platform begins now goes to the lawyers. Lawyers take time and cost money.

Next, the memo requires that companies build near-real-time tracking directly into the platform. That adds a front-end requirement to a back-end requirement, which simply takes more time. Rather than a report sent 24 to 48 hours after, this requires the information to be available directly in the app interface. That means for every new feature, it needs to be integrated into the tracking dashboard. That takes time and costs money.

Finally, and perhaps most problematic of all, is the restriction on customization and development. “To protect the security and integrity of our [software-as-a-service] platforms,” the memo reads, “the [Department of the Air Force] prohibits custom code development and modification to extend functionality beyond the platform’s original design. This includes using Application Programming Interface (API) or other mechanisms to add features not initially intended.”

At the very core of the Software Acquisition and Practices study was a software development ethos: Software is never done. It is always a work in progress, continuously updated, and improved. Stopping development, or preventing the extension of application programming interfaces, is perhaps the most short-sighted decision of all. Embedded development teams and forward-deployed engineers have made government software-as-a-service more powerful, and their users more efficient and therefore, more lethal. Restricting teams’ and developers’ collective ability to spot problems, rapidly push updates, and stitch together systems does not make us safer. It falls back into the trap of security theater that slowed software delivery and modification for years under an arcane risk mitigation framework-based compliance, rather than today’s modern continuous monitoring practices.

Why does this matter?

The future fight is not one of exquisitely-engineered hardware systems out-foxing each other in the air or in the trenches. From Eastern Europe to the Middle East, we see adversaries adapting day by day and week by week, not month by month or year by year. Anything that slows our own country’s ability to keep pace with our current adversaries (let alone future ones) is a detriment to American readiness and security. At the same time, reductions in force mean that we will be fighting these battles with fewer contracting officers, not more. This means that the importance of living software — that can continue to change and improve each day — is paramount. The thought of needing more contracting actions to achieve the same effect should horrify every single American. As Alexis Bonnell reminds us, “The danger of ‘it’s just [a form]’ is that it shows our lack of respect for our people, their purpose, their passion, and their time.”

What is to be done?

First off, making consumption-based pricing an option for software-as-a-service is absolutely the right idea. Thankfully, this is already done. But it should not be the sole path to acquiring subscription-based software. Some software licenses are valuable — especially when they do not expire (a la Microsoft Office). And early-stage software pilots have not identified, nor proven out, their unit of consumption or unit of value. Requiring such a thing would forestall innovation. Instead, equip contracting officers and program officers with these tools and train them on the conditions under which each should be employed.

Second, the responsibility for de-duplication of software rests with the requirements owner and the program manager, who should ensure they’re not a) generating a duplicative requirement, and b) acquiring something the government already owns. AI-enabled tooling makes this easier than ever. Equipping them to make that determination, rather than shackling them to a small subset of contracting vehicles, is the way to unlock rapid value for the warfighter. We may reasonably infer that this guidance attempts to increase enterprise visibility for existing software-as-a-service products by prescribing how contracts should be structured. However, mandating contract formats in this way risks creating many of the challenges already identified, rather than resolving them.

Finally, the prohibition on development has got to go. Written approval from the contracting officer’s representative before charging for more features is reasonable and a fair enough substitute.

I truly believe that the Air Force aspires to deliver value for the Department of Defense through modern software acquisition. While well-intentioned, this guidance puts that at risk. The Air Force adding yet another layer of mandatory contracts only adds more complexity and red tape to federal policy — policy that is already encouraging contracts aligned with federal category management practices. This exemplifies the ongoing prioritization of rigid processes over meaningful outcomes. Warfighters, industry, and taxpayers would benefit from an immediate rollback.

Noah Sheinbaum is the founder of a research and advisory company, Frontdoor Defense, as well as media production company STEAM Studio. He chronicles the journeys and lessons of companies that move from prototype to production in the federal market in his podcast, Crossing the Valley.

Image: Senior Airman Elizabeth Figueroa via DVIDS.