The Department of War has never fielded new capabilities faster. Autonomous systems and commercial tools are arriving at an unprecedented pace, but almost none of them can talk to each other without a small army of engineers building custom bridges and integrations between them. More systems aren't adding up to more combat power, and that demands a new way to think about MOSA and connectivity between platforms.

Acquisition speed aside, the bottleneck to widespread tech adoption is integration, and not innovation.

‍

The problem with “Open" as we know it

Fifteen years ago, the Modular Open System Architecture (MOSA) standard set out to fix this by pushing for modular, competitive, interoperable systems, which made sense for the time. However, MOSA was designed before AI became central to military capability, and now MOSA's flexibility, which used to be a strength, has become a loophole. Under current practice, a system can technically qualify as "MOSA compliant" simply by having an API, regardless of whether that API is accurate, complete, or kept up to date or if it locks in the Government to an ecosystem from a single vendor. APIs have to connect to something, that something is often a proprietary layer or application. Openness on paper doesn't mean openness in practice.

‍

three hidden costs of the old integration model

Looking at how defense systems actually get connected, the same three problems keep showing up.

The first is agreement. Before two systems can communicate and share information, a common format has to exist between the systems. Developing that common format becomes a tax every new system pays just to join the fight. It doesn't fall evenly, either. A tool that's easy to integrate often gets adopted ahead of one that's genuinely more capable, simply because it's less painful to plug in. The force ends up optimizing for ease of connection instead of operational value.  

The second is persistence, and it's the one that costs the most over time. Mission data usually lives inside whatever application created it. So, when the application is replaced, retired, or goes offline, its data goes with it. This results in the need to keep rebuilding the same understanding from scratch, instead of building institutional knowledge.

The third is ownership, and it's the sneakiest because it doesn't look like a problem at first. Whoever manages the most integrations quietly becomes the gatekeeper of the whole ecosystem, even when the government technically owns the data. Owning data on paper means nothing if reaching it requires access to a vendor's pipes or their proprietary architecture and software applications. Access without control isn't ownership. It's a longer leash that just feels better during contracting.

While none of these three is fatal alone, when stacked together, they put a hard ceiling on how fast new capability can reach the field.

‍

the evolution of mosa — are we doing it wrong?

MOSA exists to make systems easier and more affordable to upgrade, bring in new capabilities, and keep the government from being permanently tied to one supplier, while also giving programs the room to define the standards and interfaces that meet their particular requirements. And that makes sense within a program, but bring several programs together, and the seams are still there. Each can be “open” on its own terms while the combined environment remains expensive to enter, difficult to change, and even harder to leave.

If the goal is to make capabilities easier to introduce, replace, and improve, those benefits have to hold across whichever data environment will ultimately be shared. A new capability has to get at the information it needs. It has to contribute without forcing everyone else to reorganize around it. And it has to be able to leave without taking the mission’s accumulated data—or everyone else’s ability to use it—with it.

And maybe that is where we need to alter our approach, so instead of defining what an open architecture should look like, perhaps we need to instead work backwards, and target below the application layer. Beginning with first defining what must remain true of the shared mission data environment itself, and establishing what the architecture has to deliver, and ensuring the factors that actually determine ease of interoperability are met—regardless of the architecture itself.  

‍

a new architectural primitive

If we’re going to work backward from what the shared environment must deliver, maybe we need to go as far as defining a new architectural primitive. Something concrete that programs can build toward, and that the mission owner can actually evaluate. Because, if we’re honest with ourselves, “shared data environment” leaves just as much room for interpretation as “open” unless we define what qualifies.

There’s an idea worth borrowing from here. Existing data commons initiatives seek to make data easier for a community to share, access, and use. We can build on that ambition while defining what it needs to mean for a mission environment that spans programs, applications, and providers in support of the DoW.

Perhaps we call it a Mission Data Commons: a persistent, distributed mission data environment that remains under the mission owner’s control as applications, networks, and vendors change. One where changing a capability doesn’t mean making everyone else start over, or when replacement applications can easily make sense of the information already there, and contribute information others can use, all while ensuring the required security and authorization boundaries hold.  

‍

what actually makes something a “mission data commons"

If that is the bar, then we also need to define the characteristics that must hold below the application layer, within the shared data environment itself, and that endure as applications and vendors change. They also need to be testable; otherwise, we’ve just given the same ambiguity a new name.

A Mission Data Commons must demonstrate seven defining characteristics:

• Persistent. Mission data remains available beyond the life or availability of the application that produced it.

• Distributed. Participating nodes can retain data and continue operating without depending on one central system remaining reachable.

• Source-native. Data can enter and persist in its source representation without first being forced into a common model.

• Authority-aware. The environment preserves where information came from and the rules governing who can change it.  

• Continuously reconciling. When disconnected participants reconnect, the environment reconciles their changes according to defined authority and conflict rules.

• Destination-routed. Information moves toward its intended, authorized recipients as participants and network conditions change.

• Mission-owned. The mission owner retains practical control over the data and the ability to operate, extend, or transition the environment.

Each characteristic needs a practical test. Together, those tests establish what survives change, what the mission owner controls, and how capabilities join, contribute, and leave—regardless of which applications or vendors are involved. That’s the point of starting at the data layer: define what the shared environment must deliver, then judge the architecture by whether it delivers those outcomes and preserves them as its components change.

Every one of these comes down to the same test: does the environment still work after the original application, vendor, or connection is gone? If the answer is “yes” across the board, it's genuinely persistent, distributed, and mission-owned. If it’s a “no” on even one, it's just another integration layer borrowing the language of openness without earning it.

‍

why this matters now

The speed at which we see change in defense tech isn't slowing down, and neither is the number of vendors trying to plug into military networks. More vendors should mean more options. But if every new capability adds another dependency on the company stitching it all together, we’re growing the ecosystem around the integrator. The mission is just paying for it.  

The next evolution of MOSA—whether we call it MOSA 2.0 or not—should ultimately change the questions we need to ask. Beyond whether systems can connect, what does it cost the next capability to join, operate, and evolve within the environment? Defining a Mission Data Commons as a new architectural primitive offers one possible way forward: establish what we need from the shared environment and what must remain true as applications and vendors change. Different architectures will undoubtedly get us there, but each should have the shared objective of delivering those outcomes, and an environment that endures beyond its individual participants. That is the real freedom I believe that MOSA was trying to deliver—and what I firmly believe we need to define else we keep buying our way back to the same problem—and call it modernization.

‍

To read more and stay up to date with the latest from Forterra, visit forterra.com/news.