MOSA is Being Weaponized. Is the Industry Ready?

The Department of War is no longer treating MOSA as guidance. It is turning it into an enforcement mechanism for competition. 

Earlier this year, Breaking Defense published an article highlighting how multi-sourcing, MOSA, and producibility are evidence of just how clear the U.S. Department of War (DoW) is on its position. MOSA is increasingly being used to break the single-vendor control that has crept into major programs over time. Cleaner architectures may be a result, but preserving competition and supplier choice is the larger acquisition objective. 

And the message is becoming pretty clear: MOSA is increasingly about creating real competition, giving programs more supplier flexibility and making it easier to modernize systems over time.

Why MOSA Matters

The problem the DoW is trying to solve is structural. Programs that begin open, often evolve into closed ecosystems, with a prime contractor controlling the interfaces, integration, and upgrade paths. That leads to slower delivery, fragile supply chains, and limited negotiating leverage. 

The response is to design systems that can support multiple suppliers at the module level, with the ability to swap components without re-architecting the system.

Truly the ‘M’ in MOSA is doing a lot of the heavy lifting. Open Systems Approaches are necessary, but to achieve what? To achieve MODULARITY!

That is where the combination of multi-sourcing, MOSA, and producibility comes together. Multi-sourcing ensures at least two viable vendors. MOSA breaks systems into modules that can be competed. Producibility ensures those modules can actually be built and fielded at scale by more than one supplier. 

This is less about having the perfect architecture and more about preserving competition, maintaining program control, and making sure the system can evolve over time.

MOSA Is Becoming More Than a Compliance Exercise

When the DoW article states that the department “has a chance to implement new standards for industry, and shouldn’t be shy about driving forward,” it is signaling a shift in posture.

The DoW intends to mandate openness through acquisition policy, not rely on voluntary alignment. That direction is consistent with recent guidance from the DoW, which emphasizes multi-vendor strategies, open interfaces, and government control of key technical data.

This creates a clear tension with how MOSA is often implemented today. Many systems expose interfaces but retain tight control over integration, data models, and upgrade paths. They are open at the edges but closed at the core. That approach meets the letter of MOSA but not the intent. Under the emerging acquisition model, that will not hold.

True replaceability requires more than interface compliance. It requires stable data contracts, decoupled communication patterns, and the ability to integrate third-party components without forcing changes across the rest of the system. Without that, swapping a module triggers a cascade of changes across the system, which defeats the purpose of multi-sourcing.

That creates a pretty simple test for MOSA:

Can you replace a module from one supplier with a module from another without having to redesign the rest of the system?

If every substitution creates another major integration effort, the architecture may be open in theory, but it isn’t really modular in practice.

Making MOSA Work in Practice

Getting to that level of replaceability requires more than open interfaces. Applications and components also need a way to exchange data without becoming tightly dependent on one another. That is where a data-centric architecture becomes important – and it’s where RTI Connext delivers value.

The reason? Connext does not seek to re-invent the wheel by defining the modules – that would add unnecessary complexity. Instead, Connext works to enable and accelerate how those modules communicate, evolve, and get replaced. 

In practical terms, this means a new vendor can introduce a replacement module that speaks the same data model and participates in the same data flows, without requiring changes across the rest of the system. Discovery, quality of service, and data distribution are handled by the infrastructure rather than custom integration code. The system becomes tolerant to change because the dependencies are managed at the data layer, not hard-coded between components.

And ultimately, that ability to tolerate change is what makes modularity useful over the life of the program.

The Difference Between MOSA on Paper and MOSA in Practice

Most implementations stop at defining interfaces. The harder question is what happens when the architecture actually has to change. Can teams add a new capability, replace a supplier or scale the system without redoing the integration every time?

The challenge is making MOSA achievable in real system architectures, where components can actually be replaced, upgraded, and completed without triggering another major integration effort. 

That is the real test of MOSA: Can a program replace a module from one vendor with another without breaking the rest of the system?

A data-centric architecture helps make that possible by giving programs the flexibility to preserve competition and modernize over time – and that is where Connext can play an important role.

MOSA Summit: September 22-24, 2026

Planning to attend the MOSA Industry and Government Summit & Expo in National Harbor, Maryland? On 9/22 at 1:30 pm ET, RTI will present a panel discussion entitled MOSA in Practice: Integrating Digital Engineering and Defense Systems. I’ll be there with industry experts from other important firms to explore such topics as:

• The role of digital engineering in supporting MOSA implementation

• Integrating models and simulations with operational systems

• How data interoperability and architectural governance influence long-term sustainability

• How MOSA principles translate from policy into real system architectures

I look forward to seeing you in person as we dive into the technical and organizational challenges that must be addressed to achieve interoperability across today’s complex defense ecosystems.

About the author:

Rob Proctor is a Staff Field Application Engineer for Real-Time Innovations. He has over 28 years of experience in A&D Embedded Software as a Software Engineer and Field Applications Engineer. Prior to his time as a Field Application Engineer, he developed and implemented real time embedded software at major Aerospace and Defense Corporations. His roles have included developing software and system designs, mission-management and display processing systems. Rob received his BS from Embry-Riddle Aeronautical University in Aerospace Studies and his MS from the University of South Florida in Engineering Management.