Agile, Open and Digital – Necessary, but not sufficient for Transformation

TLDR: Just being Agile, Open and Digital won’t lead to transformation. 

1. We lack a unifying architecture based in Digital and Model-based Systems Engineering.
2. Software Factories won’t deliver until that architecture describes interchangeable parts, measurable specifications and rigid quality definitions.
3. The stakes of failure in cyber-physical systems require a different risk calculus than most FAANG-style companies.
4. And we will have to go slow, for a while, before we can go fast.

There is no shortage of effort being expended today on DoD transformation—from DevSecOps and Agile software development to a focus on operational experimentation and pilots, sometimes with commercial hardware and software. A lot of organizations and people are expending a lot of resources to that end. I worry, however, that, as one of my previous commanders used to say, “there’s a lot of thrust here, with no vector.” That, without a unifying architecture and a framework for development, all this effort may result in very little.

It’s impossible to overstate the scope of transformation that we’ve seen in the past few years, as, as Marc Andreesen predicted, software “ate the world.” While we used to marvel at hardware lifecycles, driven by Moore’s Law, of 18-24 months, we’ve since grown accustomed to transformational technologies growing from nothing to an entire market category in months. Remember that Uber was only founded in 2009 and didn’t just disrupt the taxi and personal transportation markets, it literally created the gig economy. TikTok is less than 6 years old, but is redefining the market for creators, driving viral trends, and overturning advertising paradigms – and was the most popular web site of 2021, surpassing Google.

It's no surprise that the Department of Defense has seen this tectonic shift and hopes to harness some of its underpinnings to help move the department forward and to, depending upon whom you ask, either stave off or close the technology gap to our near-peer competitors. “If everything we do is driven by software,” goes a well-intentioned and oft-repeated argument, “won’t we benefit by adopting many of the same processes the private sector is using?”

Which leads us to the title of this article – Agile, Open and Digital, which the Air Force has designated as the Digital Century Series’ defining tenets—are in fact necessary characteristics of the technologies which will lead to effective transformation, but they are not sufficient. 

We have countless organizations deploying “Software Factories,” pointing to the Agile software development and open source tools being used in this digital (software) engineering activity. Clearly, this must be, or at least lead to, the digital transformation we seek—we’re coding faster, executing in sprints, closing user stories and, if the press releases are to be believed, delivering MVPs to exercises and operational users. We’re delivering fast and iterating; unfortunately, it’s often unclear toward what we are iterating. 

And “move fast and break things” isn’t a great motto when the “things” are $100M fighters or $1.5B global ISR systems. The stakes are a good deal higher than my Uber arriving late or TikTok failing to show me the most relevant new dance fad. Just because we can deploy software quickly doesn’t mean it will prove to be airworthy, for instance, or be robust in operational conditions. And, while cybersecurity isn’t the focus of this discussion, data stolen from our national security systems via the same vulnerabilities and exploits that plague the private sector exacts an even higher price than stolen identities.

The primary lack of sufficiency stems from an absent organizing framework, and a prerequisite to such an organizing framework is a better set of analogies. Software “factories” are not the answer.

Factories, after all, are just places where manufacturing takes place at scale. The fact that something is a “factory” doesn’t tell you anything about the processes or tools being used within. While we imagine clean rooms, robots and quality control, factories are just as likely to be dirty, crowded places without formal processes and with highly varying degrees of quality. 

A more apt analogy—and more in line with our imagination—is an assembly line, where semi-skilled workers, using specified process, assemble standardized, interchangeable parts into a quality-controlled whole. 

This isn’t just a verbiage problem, our analogies and mental images impact what we build, what we expect and what gets delivered. When there isn’t a standard toward which our software factories are delivering, how do we measure and ensure quality? How can we even define quality or compare it between projects? Without a framework for interchangeability, how will we ever get code reuse or evolve past every single software package existing as a bespoke, artisan-crafted one-off with the fragility and supportability issues which we currently experience? As a practical note—how will we be able to transition a software program between contractors when only those involved in the development can begin to support it? And, back to where we started, what isn’t a software program at this point?

We had factories long before Henry Ford improved the assembly line. It was the assembly line, though, that allowed, even required, much more standardization in inputs and outputs from each step. Instead of a small group of experienced craftspeople hand-building one car at a time, a larger number of lower-skilled workers could be trained to perform subdivided (and, admittedly, more repetitive) work. The standardization of inputs eventually meant that multiple suppliers could provide parts, material and sub-assemblies and that many of those parts could be used in more than one part of the car or even on different cars.

None of this came without significant planning—first there had to be a framework for an assembly line and an architecture for the cars to be produced. In this case, the architecture for a car was in place and reasonably mature, but only after two decades of refinement. The new assembly line framework dictated subdividing work, determining what could and should be specified and standardized, designing part and assembly flow, even identifying that the speed of the assembly line can be varied. Specifying and populating such a framework takes significant work and, importantly, time. 

Designing and building assembly lines is hard—but it’s what makes building cars easy (and fast).

In software systems and cyber-mechanical systems, we lack both the (general) architecture for solutions and the framework for delivering at scale. If we ever hope to be able to go fast, we must first take our time. 

These changes aren’t easy, nor will they be able to happen quickly if we don’t commit to the hard work of design, of digital engineering, of building frameworks and models, and of tooling and re-tooling with an agreed goal in mind. There is some good news on this front; in fact, we’re even starting to see terms like MOSA, WOSA, DE and MBSE show up in requests for proposal and requirements documents. Much more effort, though, is being spent on bespoke, artisan development efforts with no clear end-state in mind. If we are to succeed in our transformation journey, we're going to need to put a lot more focus into the vector, maybe at the expense of some thrust.

We must be agile in process and in mindset. We must be open in architecture and in standards. We must be digital and model-based in engineering. 

Those remain necessary for transformation. 

However, they are not sufficient.