MOSA infrastructure: more relevant than ever for the DoW?

The Modular Open Systems Approach has been law since 2019. A wave of 2025–26 memos, and a battlefield that now reinvents itself every few months, have made it urgent. We sat down with two people who've lived the problem — Nolan Schultz, a Spectro Cloud account exec and Army Special Forces vet, and Colton Shaw, a principal architect with six years in public sector and defense — to cut through the policy noise and talk about what it means on the ground.

Picture the kit you fielded last year: the drone, the sensor, the comms stack, the AI model running on it. There's a decent chance some of it is already obsolete, and a better chance the mission it was built for has moved on. Colton Shaw sees it constantly. "By the time it's designed, the mission need has changed, or someone's already solved it a different way, and then we have to rethink from the beginning."

That's the problem the Modular Open Systems Approach was written to solve. After years of being treated as a box to tick, it's having its moment. Partly because the Department of War keeps saying so in memo after memo, and partly because conflicts like Ukraine have shown everyone what happens when warfare starts iterating at the speed of software.

The law, the memos, and the gap

If you work in defense acquisition you know the definition, so we'll keep it short. MOSA, codified at 10 U.S.C. § 4401, requires major programs to be designed "to the maximum extent practicable" around modular components and open, consensus-based interfaces, so pieces can be swapped, upgraded, and re-competed across a system's life. 

It started in the world of weapons systems. Nolan Schultz reaches for the analogy any soldier will recognize: "It's the MOLLE load-carrying system. You've got weavable components, and you can change portions of your kit around. It's the same approach to software-defined systems: swappable, composable, flexible, so you can meet the mission whether it's strategic, operational, or tactical."

The memos have piled up, and they've raised the stakes. The November 2025 Warfighting Acquisition System memo made maximizing MOSA one of its five pillars. Two months later, the January 2026 AI-first memos went further, committing the Department to enforce modular open architectures so components can be replaced at commercial speed without leaning on the prime contractor for every change.

The Department also has a habit of not following its own policy. A January 2025 GAO review found that of 20 weapons programs it examined, only 14 had implemented MOSA to any real extent, and some had skipped the cost-benefit analysis entirely. The latest reforms even let acquisition executives waive MOSA for new programs. So "MOSA's time is now" is as much a challenge to the building as a description of it.

AI is what makes modularity non-negotiable

Ask why now, and the one-word answer is AI. The memos are downstream of the real driver, which is pace: the technology underneath moves faster than any procurement cycle can track. "Look at AI six months ago: it's different than six months before that, and six months from now it'll be entirely new," Colton told us. "We've got CPU inferencing models coming. If we're designing around the hardware we have today, we're not keeping up with the pace."

Build a system that can only run the model it shipped with and you've built something with a twelve-month shelf life. Make the model, the inferencing layer, even the hardware accelerator into swappable components, and you've bought yourself years.

Open matters as much as modular

Most of the conversation around MOSA is about the "modular" part. The "open" part gets less airtime, but it matters just as much. The temptation for a defense prime is obvious: keep the system proprietary, and promise to push AI updates to keep the customer current. Nolan's view is that openness is key to flexibility: the ability to use the best component for the job, wherever it comes from. "Our open source community is very powerful. There's a lot of talent and IP there, and the DoW and the IC are big open source users. It's baked into major programs."

What MOSA enables is a best-of-breed mentality. "Take open source capability, bring it into a stack, harden it, and now you've got mission capability." The question stops being build-versus-buy and becomes who owns the SLA, the engineering, and the response times.

Colton picks up the technical thread. "Companies have realized certain code bases really specialize: a performant Postgres plugin, a performant file store. Why rebuild that? Pull it into your platform, it's maintained and updated, and you specialize on your one component." 

That trend towards component reuse, multiplied across an industry, is why defense software is moving the same way commercial software did. "We're seeing the move to containers, to Kubernetes, to a smaller form-factor way of shipping software." It's the Unix philosophy in camouflage: each component does one thing well, and you assemble a scalpel rather than a Swiss Army knife. In Kubernetes terms that's your CNI, your CSI, your load balancer, your observability, each a best-of-breed choice. The only new wrinkle is that the stack now runs on a drone instead of a cloud instance. The Department's own Cloud Security Playbook says the same: a microservices-and-containers architecture meets MOSA requirements, and it points to the CNCF Kubernetes reference design.

Modularity has to survive the battlefield

For all the validity of the CNCF ecosystem, a lot of cloud-native thinking falls over when applied to warfighting conditions. In a data center you're in a comfortable chair, in a carpeted room, with a stable connection. The tactical edge is none of those things. Assets are disconnected for hours or months, exposed to tampering, and operating under electronic warfare and cyber pressure. Nolan is blunt about the stakes: you can flash drones from a config file passed hand to hand and get away with it at small scale, but "if you don't have security control at scale, you're opening yourself up to a vulnerability from EW or cyber attack."

There's also the pilot-to-production trap, which hits as hard in defense as in any enterprise. Open source on a 20- or 30-person team is a joy: free, adaptable, easy. Scale it to a system of systems and, as Nolan puts it, "that's where true open source tends to falter," because the security implications and the support burden grow with the footprint, and "the support and DIY is the why" when units are undermanned and over-tasked.

The modularity that matters most sits below the application layer, where almost everything is proprietary anyway. It lives at the IT infrastructure level, and it has to be usable by someone who isn't a Kubernetes engineer. Colton describes what good looks like from a real deployment. During an exercise in Australia, his team didn't have time to debug a failing system. "They needed something up and running. The ability to rip out one piece of software, guide someone through it over a webcam, drop in another that's tested enough to get them to the mission outcome: that's the goal. Keep the mission moving, solve it properly on the back end later." You only get that if you designed for it. Build a system to do one thing and hot-swapping is impossible. Design around the outcome, with the pieces as components, and swapping a module (including an AI model on a flash drive) becomes a two-step job.

Where Spectro Cloud fits

Modularity across the infrastructure stack has been core to our philosophy here at Spectro Cloud since day one. Palette manages the full infrastructure stack (operating system, Kubernetes distribution, networking, storage, security, and much more) as declarative, swappable layers, from the data center to the cloud to the tactical edge, and on devices as small as an NVIDIA Jetson module or SNUC box. We don't ship a fixed stack. You bring your own and change it: swap the CNI, the OS, the inferencing layer, the model itself, without re-platforming or re-certifying the whole system.

We’re also comfortable in the defense world: we offer FIPS 140-3 validated cryptography and operate disconnected-first: clusters enforce their state locally and keep running when cut off, then resync when the link returns, with no operator SSH-ing into an austere site to patch it. The platform has been assessed at Technology Readiness Level 9, and has all of the CNCF conformance certs. None of it locks you to a single vendor, which is the entire point of MOSA.

The five-year view

We asked both our speakers to look five years out. Colton's answer was about discipline more than prediction. "The mission need I have today, I've got to solve. But how do I solve the one I can't see yet? Keep your options open when you're purchasing and designing, so you can swap a component without deprecating everything and starting a whole new procurement cycle."

Nolan named the underlying force: velocity. "A hundred years ago the tank arrived, and by the next war the horse was obsolete. Now it's faster. A multi-million-dollar tank can be taken out by a 500-dollar drone and a shaped charge. War is becoming software-defined, so I have to plan under the assumption that what I build today is irrelevant in a year. I don't have time for a three-to-five-year program of record." Ten years ago, he points out, he was fielded equipment that was already obsolete on arrival, when he could buy better off the local economy. Now the cycle applies to whole systems, in months.

Drones are the clearest illustration, and both expect the cat-and-mouse to continue. Ukraine built an entire drone-warfare ecosystem in the time a traditional program would still be writing requirements. Effective counter-drone capability is coming, and a counter to that after it. As Nolan put it: "Warfare is software. Everything that touches the battlefield has software in it now." And code iterates faster than hardware ships.

What to do on Monday

If you own a program, the advice from Colton and Nolan is concrete and a little confrontational.

Design for the future you can't see. Don't solve only for today's mission need; the unit you can't yet specify is the one your architecture has to leave room for.

Interrogate your vendors. Ask: "What does your software not do that the alternative does?" Every vendor will tell you how good their product is, so ask the gap question and hold them to the answer. Second, the one Colton calls the single most important thing to ask a vendor: "How do I break up with you?" If the honest answer is "you can't," that's your lock-in, and your risk.

Insist on openness at the infrastructure level. The test is simple: can you replace a component (an AI model, a distribution, a vendor) and keep the data and base infrastructure you've already built and certified? A proprietary stack with an update roadmap doesn't pass it. Pass the test and you've future-proofed; fail it and you've signed up for the next forklift.

MOSA's time is now

The battlefield stopped waiting for procurement to catch up. The systems that stay relevant will be the ones designed to change, whatever the Pentagon calls the policy that year.

If you're working on this, a few places to go next: our take on why unified computing is the key to the tactical edge, how Palette delivers mission-ready Kubernetes at the tactical edge, and sovereign compute for defense and government. 

Or book 30 minutes with our public sector team and bring your hardest "how do I break up with you" question.

‍