BLUF: You Do Not Lose Readiness on the Battlefield. You Lose It in the Contract and in the Architecture Diagram.
If you want operational readiness inside the next 2–5 years, stop treating architecture and data rights as back-office IT hygiene. Treat them as combat multipliers. Every time you approve a closed, OEM-controlled architecture without enforceable interface controls and sustainment-enabling data rights, you are making a future-readiness decision. You are deciding who controls your repair timelines. You are deciding who sets your upgrade schedule. You are deciding whether competition is real or theoretical.
When sustainment depends on one vendor’s proprietary access, readiness becomes a subscription service. Parts arrive when the OEM prioritizes them. Upgrades happen when the OEM allows them. Integration occurs on the OEM’s terms.
That is not stewardship.
That is dependency.
And dependency in a contested environment is vulnerability.
The uncomfortable truth is this: vendor lock is not a contracting inconvenience. It is a warfighting constraint. When maintainers cannibalize systems to keep others operational, when software refreshes stall because interfaces are closed, and when upgrades require re-buying entire stacks, the architecture has already failed the mission.
The good news is that we are not guessing at the solution.
DoW has already codified the blueprint. The Modular Open Systems Approach is not a theory. It is a statutory directive to design systems with modularity, competition, incremental upgrade paths, and lifecycle evolution built in from the start. MOSA makes architecture a strategic asset instead of a sustainment liability.
Federal civilian agencies carry a parallel mandate. Enterprise architecture is not an annual compliance exercise. It is a discipline of baseline-to-target transition that forces leaders to confront how systems will evolve, interoperate, modernize, and ultimately retire. It demands that upgrades and replacements be planned, not improvised in a crisis.
So the direction is clear across defense and civilian portfolios:
Know what you own.
Know what you can replace.
Know who controls your interfaces.
Know whether you can compete sustainment.
Know whether your data rights enable independence or enforce reliance.
In 2026, architecture is not a diagram. It is a decision authority over your future options.
If you postpone governance until after deployment, you will govern by slowing delivery. If you embed governance into modular design, interface control, and enforceable data rights, you can move faster without surrendering accountability.
The agencies that will out-iterate peer competitors are not the ones that buy the most technology. They are the ones that control their integration layer, their lifecycle pathways, and their sustainment leverage.
You cannot outpace a near-peer adversary with a sustainment model optimized for industrial-age procurement. You cannot deliver 2–5 year capability increments if every refresh requires renegotiating proprietary boundaries.
If you want on-demand readiness, you must architect for it.
OEM-integrated.
Government-governed.
Modular by design.
Rights-aware by contract.
Anything less is not modernization.
It is a managed delay.
Table of contents
If you want to be ready in the next 2–5 years, treat architecture and data rights as operational requirements, not IT hygiene.
- Closed, OEM-controlled architectures create “vendor lock,” which can drive maintenance delays, parts shortages, and higher sustainment costs.
- DoW already has a mandate-level blueprint for avoiding that trap: Modular Open Systems Approach (MOSA), a combined technical and business strategy built for incremental upgrades, competition, and lifecycle evolution.
- Federal agencies also have a governance mandate to build and maintain an enterprise architecture (baseline → target → transition plan) that bakes in upgrades, replacements, and disposition decisions across the system lifecycle.
Chapter 1 — Readiness is bleeding through the seams of “OEM lock”
Every senior leader in defense and the federal government knows the tension: move fast vs. prove compliance. The problem is that many programs accidentally choose a third option: move slowly and still fail readiness.
Here’s the uncomfortable truth: architecture and data rights decisions often surface later as readiness failures. Not hypothetically, operationally.
The GAO documented how “vendor lock” emerges when programs lack sufficient technical data and rights. When that happens, programs must rely on OEMs or primes through sole-source sustainment arrangements, and officials reported the predictable results: maintenance delays, inability to obtain spare parts, and increased sustainment costs.
GAO’s examples cut to the bone: when maintainers can’t get data rights for specific components, only one vendor can make the part, repairs happen on the OEM’s schedule, and maintainers may resort to cannibalizing grounded equipment to keep other assets operational.
That is not just a contracting inconvenience. It is a warfighting constraint.
Decision-maker takeaway:
If your sustainment timeline depends on a single OEM’s availability and proprietary gatekeeping, your “readiness plan” is not a plan; it’s a hope.
Chapter 2 — What “OEM architecture” should mean in 2026
Leaders often say “OEM architecture” when they mean one of two very different things:
Meaning A (the dangerous one): OEM-owned architecture
- The OEM controls interfaces, integration logic, tooling, and sustainment data.
- You can’t swap components without OEM permission.
- You can’t compete with upgrades because competitors can’t integrate.
- You can’t organically sustain because you don’t have what you need.
This is how you buy today’s capability at the price of tomorrow’s paralysis.
Meaning B (the operational one): OEM-integrated, government-governed architecture
This is the model you actually need:
- OEMs can still deliver best-in-class components, but
- the government controls the interfaces, the integration rules, and the lifecycle pathway, so
- you can upgrade, replace, and compete without re-buying the entire system.
This is not anti-OEM. It is pro-readiness.
MOSA is the clearest DoW expression of “Meaning B.”
DoW’s MOSA guidebook defines MOSA as an acquisition and design approach with technical and business architecture that uses widely supported standards where suitable and enables severable components to be added/removed/replaced over the lifecycle, explicitly to drive efficiency, competition, and innovation.
This matters because MOSA is not a vibe. It is anchored in statute: 10 U.S.C. § 4401 requires major defense acquisition programs after specific milestones to use MOSA “to the maximum extent practicable,” with the explicit goals of incremental development, competition, innovation, and interoperability.
Federal agencies already have the parallel mandate: Enterprise Architecture
OMB Circular A‑130 requires agencies to develop an enterprise architecture with a baseline, a target, and a transition plan and to incorporate plans for significant upgrades, replacements, and disposition when systems no longer support mission needs.
So whether you sit in a military department or a civilian federal agency, the direction is consistent:
- Know what you have (baseline).
- Know what you need (target).
- Know how you’ll get there (transition).
- Build the governance and contracts that keep you free to execute.
Decision-maker takeaway:
In 2026, “architecture” is not a diagram. It is a decision authority over your future options.
Chapter 3 — The payoff: speed and stewardship without breaking the law
Decision makers don’t adopt architecture initiatives because they love architecture. They adopt them because they want outcomes:
Outcome 1: Readiness you can actually control
When you own the interfaces and the minimum sustainment-enabling data rights, you can:
- reduce single-vendor repair bottlenecks,
- compete sustainment where it makes sense,
- and avoid the downstream “surprises” GAO keeps documenting.
Put plainly: you stop renting readiness from the OEM.
Outcome 2: Modernization that fits the 2–5 year window
MOSA’s core promise is incremental evolution: swap a module, refresh software, replace a component, without redesigning the world.
That is exactly how you stop talking about “2035 perfection” and start delivering in “next budget cycle reality.”
Outcome 3: Integration that scales beyond one program
Modern missions are system-of-systems missions. Integration fails when:
- every OEM uses proprietary interfaces,
- every program reinvents data models,
- and governance arrives after deployment.
MOSA pushes you toward modular system interfaces, standards where suitable, and interface definitions that enable interconnection without proprietary choke points.
Outcome 4: Accountability that moves left (into design), not right (into paperwork)
Here’s the thought experiment senior leaders should sit with:
If you postpone governance until after you deploy, you will “govern” by slowing delivery.
If you embed governance in architecture and interfaces, you can deliver faster and stay accountable.
A‑130 explicitly pushes agencies away from compliance-as-a-checklist and toward continuous, risk-based management across the system life cycle.
Decision-maker takeaway:
Open, modular, governable architecture is how you raise velocity without abandoning stewardship.
Chapter 4 — The decision-maker playbook
What to decide, what to demand, and what to measure
If you want your organization to move from “talking architecture” to “fielding capability,” make five decisions explicit and non-negotiable.
1) Decide what must remain modular and why
Action: Require every major system to identify:
- what the “platform” is,
- what the major components are,
- and which interfaces must remain stable to enable replacement.
Why: If everything is “modular,” nothing is. If nothing is modular, you are trapped.
2) Demand interface clarity, not interface mythology
Action: Require interface specifications that are testable and usable, not vague promises. In MOSA terms, programs identify and define interfaces as a core implementation activity.
Plain language standard:
If another qualified vendor cannot build to your interface definition without the OEM present, you do not have an open interface. You have a dependency.
3) Treat data rights as a readiness requirement
Action: Require an IP/data-rights strategy that supports sustainment, competition, and upgrade pathways before you sign the deal.
GAO’s message is blunt: options get limited once a system enters sustainment, and workarounds (reverse engineering, additive manufacturing, deferred ordering provisions) are usually less effective than contracting for the right data rights early.
4) Write MOSA expectations into solicitations and evaluations
Don’t just say “use MOSA.” Make offerors prove it.
Action: Use solicitation language that forces clarity on:
- how MOSA will be used,
- how interfaces will be differentiated and managed,
- how IP/technical data/license rights will support MOSA,
- how open consensus-based standards will reduce future licensing lock,
- and how the approach supports lifecycle goals.
This is where architecture stops being aspirational and becomes enforceable.
5) Govern integration like a product, not a meeting
Action: Stand up an integration authority that controls:
- interface change control,
- system-level configuration management,
- and integration test entry/exit criteria.
Why: If you don’t govern integration, vendors will. And vendors will optimize for their scope, not your enterprise readiness.
A simple 90-day start plan for senior leaders
Days 1–30: Establish the “rules of the road.”
- Name an executive owner for architecture decision authority.
- Publish a minimum set of required modular interfaces (your “must-stay-open list”).
- Require a data-rights readiness brief for every major program in-source selection or sustainment recompete.
Days 31–60: Convert intent into enforceable acquisition language
- Insert MOSA and data-rights criteria into Section L/M equivalents (requirements + evaluation).
- Require deliverables for interface definitions, integration artifacts, and lifecycle plans.
Days 61–90: Make it measurable
Track three board-level metrics:
- Time-to-integrate a new module (calendar days, not slideware).
- Percent of critical components with competitive sustainment paths (yes/no by component).
- Interface volatility (how often interfaces change and why—innovation vs. rework).
Summary: The Future of Readiness Will Be Determined Long Before the System Fails
You will not lose readiness because a platform suddenly breaks.
You will lose readiness because, years earlier, someone approved an architecture that could not evolve, could not compete, and could not be sustained without permission.
The central issue is not innovation versus compliance. It is control versus dependency.
Closed architectures feel efficient at the award. They look integrated. They promise performance. But over time, they accumulate gravity. Interfaces harden. Data rights narrow. Sustainment becomes a sole-source. Modernization becomes a negotiation instead of an engineering decision.
That is how capability slows while budgets rise.
Peer competitors iterate faster because they accept modular change as normal. They design for replacement. They plan for evolution. They tolerate incremental risk in exchange for tempo.
If federal and defense agencies continue to treat architecture and data rights as secondary considerations, they will field advanced systems that cannot adapt at operational speed. They will comply with the process, but lose optionality.
MOSA provides a path out of that trap. Enterprise architecture governance reinforces it. Both demand that leaders think in lifecycle terms, not in terms of acquisition milestones. Both force clarity about interfaces, integration authority, and sustainment leverage. Both shift accountability left, into design and contracting, rather than right, into crisis response and oversight remediation.
The shift required is not technical. It is executive.
Senior leaders must decide that:
Architecture defines freedom of maneuver.
Interfaces define competitive power.
Data rights define sustainment independence.
Integration authority defines enterprise control.
When you embed those truths into solicitations, evaluation criteria, lifecycle plans, and performance metrics, modernization accelerates rather than stalls. Oversight strengthens instead of suffocating. Stewardship improves without sacrificing speed.
The agencies that will dominate the next decade are not those that buy the most advanced systems. They are the ones that can replace components without having to replace programs. The ones that can compete sustainment without rewriting contracts. The ones that can upgrade software without disassembling the enterprise.
Readiness in the next 2–5 years will not be achieved by urgency alone.
It will be achieved by design.
OEM-integrated.
Government-governed.
Modular by design.
Rights-aware by contract.
Anything less is not modernization.
It is a managed delay.
Take Control of Your Architecture Before It Controls You
If your program depends on proprietary boundaries, unclear data rights, or undefined integration authority, now is the time to act.
Our federal team works with defense and civilian agencies to design modular, governable, rights-aware architectures that accelerate modernization without sacrificing accountability.
If you are planning a new acquisition, facing a sustainment bottleneck, or preparing for a major refresh, let’s have a focused conversation.
Engage our federal team today and turn architecture into a readiness advantage.
References
- Office of Management and Budget. (2016, July 28). Circular No. A‑130: Managing information as a strategic resource.
- Office of the Under Secretary of Defense for Research and Engineering, Office of Systems Engineering and Architecture. (2025, February). Implementing a modular open systems approach in Department of Defense programs (MOSA Implementation Guidebook).
- U.S. Government Accountability Office. (2025, September 29). Weapon system sustainment: DoW can improve planning and management of data rights (GAO‑25‑107468; reissued with revisions).
- 10 U.S.C. § 4401. Requirement for modular open system approach in major defense acquisition programs; definitions.
- Acquisition.gov. (2025, July 11). Modular Open Systems Approach (MOSA) (10 U.S. Code § 4401): Sample Section L/M language (AFARS).