Understanding the Essence of MOSA Beyond Standards

There is an old poem that reads, ‘Water, Water Everywhere; but nary a drop to drink.’ This reflection of a sailor lamenting being surrounded by sea water yet still thirsty perfectly encapsulates the experiences I encounter with professionals when discussing MOSA. The common response often revolves around “Standards,” but we must clarify this misconception from the outset: Standards do not equate to MOSA.

If vendor lock is like the saltwater landscape of the sailor, then our systems are not all built incorrectly- we have always used standards. Sea water contains H2O, but good drinking water requires more than just the distillation of raw materials. So we say “just use BETTER standards!” This is like distilled water, free of the salt – as if, like removing the salt from the water we could simply apply a standard and remove vendor lock from contracts. But reality in contracting is more complex (and besides, distilled water is very unsatisfying). An Acquisition Strategy is the whole meal, for which the standards (water in our analogy) is only one part, and other elements includes contract approach, testing plan, system architecture, and more.

This analogy is helpful for understanding the relationship between standards and MOSA. While standards are an essential part of MOSA, they do not encompass its entirety. To truly grasp MOSA, one must look beyond mere compliance and acknowledge the richness that comes from the collaborative integration of various elements. Only then can we appreciate the full potential and utility of MOSA in our professional landscapes.

If Not Standards, Then What Is MOSA

Let’s take an actual tour of Title 10 and the Tri-Services Memo to gather what a balanced diet of MOSA looks like. Key to the whole history of MOSA was the transition from purely “Open Systems Architecture (OSA)” terminology to the use of the term “Approach” in the legal definition. It is a strategy, a codification of a series of comander’s intent and warfighting acquisition common sense (e.g. have freedom of action later in the program lifecycle) for which standards are an enabling element.

Title 10 MOSA Chapter 327, Subchapter I lays out an orderly approach and top level guidance. I always encourage people to just follow the link and read it. It is broken into 3 parts:

• Section §4401 has the definitions, especially the core of what “approach” means and what the rationale should be for a program to establish modularity decisions
• Section §4402 lays out the design requirements on programs, particularly that the focus is about the program lifecycle, not at all about the standards used to achieve that approach.
• Section §4403 lays out the support for interfaces, which empowers the government work with standards agencies to ensure that the points of seperation in the system have open definitions.

Very importantly, it is immediately followed by Subchapter II, which lays out the authorities for rapid prototyping! When you take it in parts, it is pretty clear that the ability to use the budget that is already planned for the program to seperate out and independently prototype, design, and procure modules apart from the platform or whole system is the actual “satisfying meal” of MOSA. When I organized the first MOSA Summit in 2023, the analogy I used was Thanksgiving dinner – standards may be in the center of the table, but we need the whole meal brought in by different parties to compelte the dinner.

This is where we need to shift to the “5 Pillars” in the MOSA Tri-Services Memo, and in particular the one that necessitates the building up of our MOSA Network. These are:

• (1) employing a modular design, (echos back to §4401)
• (2) designating modular interfaces, (echos back to §4402)
• (3) leveraging consensus-based open standards, (echos back to both §4401 and also §4403)
• (4) establishing enabling environments, (pulls some more on §4402 and §4403, espeically in the AoA and RFP sentiment and the requirement on the Service Secretaries to coordinate)
• (5) certifying conformance (squarely in the §4403 sentance “ensure” repeated 4 times as requirements on the Service Secretaries)

When you spell it out that way, you can see the MOSA is leveraging the standards and working with the standards bodies (as well as other industry consortia, more about that later in another article on Prototyping in Subchapter II). To get the full approach, however, you need to realize that this is bigger than any one module, any one standard, and even any one weapon systems. MOSA is a requirement upon the WHOLE OF THE DEPARTMENT OF DEFENSE by Congress to approach acquisition in a modular fashion. Now that’s refreshing!

Cataloging the Standards

Being in the MOSA ecosystem is kind of like being a New Yorker. I grew up just outside of NYC and we never refered to people from “The City” as New Yorkers. You are from Queens, Brooklyn, the Bronx, or any of a number of villages and not just “the City”. However, when spoken about in the national sense (think “Live from New York, it’s Saturday Night!”) there is a clear unity. That’s the way the standards ecosystem comes together around the “big picture” of MOSA. Perhaps our new MOSA network logo needs to reflect a Big Apple or sorts? I envision it showing that multiple subcommunities are needed to make MOSA work on the whole. How’s this for an AI-start?

Anyway, there are subsets, appropriate for different problem sets at key interface boundaries. This is the first part of a series that will dig into those standards and show people how they fit into an overall approach.

I welcome any feedback (and co-authors, if anyone is interested) in helping me write more about this! Check back soon for more!