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 notably 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 request 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 wont 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,

Air Force Memo Stifles Innovation and Adds Costs

A recent Department of the Air Force memo regarding software-as-a-service (SaaS) platforms introduces requirements that will likely increase costs and hinder innovation. While intended to enhance security, the memo’s stipulations create significant hurdles for companies working with the Air Force.

The first, and perhaps most impactful, requirement concerns data ownership. The memo dictates that companies must provide the Air Force with a clear delineation of where their data ends and the platform begins. This isn’t a simple task. Determining this boundary requires extensive legal review. Agreeing to pay for that legal work 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.

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…