Software tooling: The next technology high ground for interservice rivalry

… the U.S. Army Communications-Electronics Command Software Engineering Center is taking on the challenge with an ambitious initiative known as the Software Engineering Environment, or SE2.

 

…Today more than 50 programs and systems have migrated to the SE2, including the family of software-defined radios known as the Joint Tactical Terminal and a number of SEC business applications…

 

By the end of fiscal year 2020, the SE2 aims to create a “DevSecOps” environment across the SEC, or one in which software updates are continuously integrated and delivered with security at the forefront. A key security advantage is that because needed tools are inside the SE2, when developers fully use the environment their code never needs to transit network connections.

That was from CECOM public affairs, “SE2: Engineering an Army software revolution.” Here’s more on benefits to JTRS terminals: “The procedure reduced repair times from 120 days to one day and avoided $45,000 in costs per unit.”

While the Air Force has had the best publicity for its DevSecOps pipeline efforts, the Army and Navy have followed suit. Here’s a recent article on the Navy’s DevSecOps initiative under the Naval Information Warfare Center:

Modeled after the U.S. Air Force’s “Kessel Run,” the newly accredited Operational Application and Service Innovation Site (OASIS) enables NIWC Atlantic’s Expeditionary Warfare (ExW) Department to provide “DevSecOps” — development, security and operations — to the U.S. Marine Corps for the first time…

 

“Software factories are popping up all over U.S. military organizations, but OASIS is unique,” said Jeff Hays, a NIWC Atlantic enterprise engineering team lead. “By not focusing on a single pipeline, or single platform, OASIS is giving technology professionals the power of the latest mainstream tools, coupled with the power of choice.”

We’re still in the early days of software tooling. The Army and Navy are not simply duplicating the Air Force’s efforts. As Hays suggests, they are taking somewhat different approaches. Diversity in the early stages of such efforts is crucial for generating information about what is successful or not.

Luckily, these enterprise tools are not managed like a major defense acquisition program. If that were the case, then certainly there would be a great deal of OSD-level involvement demanding a single joint solution, along with decade-long technical/cost plans. An underfunded incremental strategy outside of usual acquisition processes is precisely what these efforts need to succeed.

At any rate, software tooling doesn’t fit into the acquisition world. It’s not a program output, but rather an enabling input to a myriad of software development efforts. The program-centric acquisition/budget process puts the focus on particular systems that create stovepipes. It is not well suited to cross-cutting efforts that support increased productivity and takes a portfolio view.

In terms of importance, I would compare the surge in software tooling efforts to something like missile race in the 1950s. As Marc Andreessen’s theory goes, “software is eating the world,” and the corollary is that software-native firms will outperform in hardware over legacy hardware-firms. Elon Musk’s SpaceX and Tesla is demonstrating this today. I think more big examples are on their way. And as software becomes intimately intertwined with hardware, agile/devops/modular practices will become increasingly important.

In the 1950s, all three services competed in developing ballistic missiles. Indeed, their concurrent and competing efforts actually supported one another. For example, the Army solved the reentry problem through repeated testing, one shape and material after another in the blast of a jet engine. The Air Force simply would not have taken such an approach, and their initial “blunt nose” design would have simply failed if they didn’t copy the Army’s results.

President Eisenhower lamented the duplication and overlap on ballistic missile development, but understood it was the fastest way to achieve stunning technical successes. Hopefully, as staff people and oversight agencies start to realize the magnitude of the impact these nascent software tooling efforts will bring, they don’t clamp down and force standard waterfall processes which will surely stifle progress — if not kill it all together.