<!-- argument-hint: [MOSA pillar, interface lifecycle step, statute/DFARS, assessment tool, acquisition pathway, data rights, DMSMS, roadmap, chapter number] -->
DoD MOSA — Implementing a Modular Open Systems Approach in DoD Programs
Source: OUSD(R&E), Implementing a MOSA in DoD Programs (Feb 2025, DOPSR 25-T-1210) — US Government work, public domain | Chapters: 7
When to use
Use this skill when a U.S. defense program must adopt, plan, write into contract, assess, or sustain a Modular Open Systems Approach: framing MOSA against the statute and DFARS, working the five pillars and the interface lifecycle, making the technical decisions (WBS taxonomy, standards profiling, software/cybersecurity), levying MOSA requirements across the AAF pathways, and tying it all to data rights, assessment metrics, and roadmaps. This is the DoD acquisition-policy companion to the SE-process packs (dau-se-guidebook, nasa-npr-7123) and the SE canon (sebok).
Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.
How to Use This Skill
- Without arguments — load the core frameworks below: the statutory chain, the five OUSD(R&E) pillars, the interface lifecycle, and how MOSA is assessed and contracted.
- With a topic — ask about a pillar (e.g. "certify conformance"), an interface-lifecycle step, a statute or DFARS clause, an assessment tool (PART, OAAT, KOSS, SEAM, MAUT), an acquisition pathway, data rights, DMSMS, or roadmaps.
- With a chapter —
ch01 (statute/policy), ch02 (pillars/benefits), ch03 (program-management/interface lifecycle), ch04 (technical considerations), ch05 (assessment/technology change/roadmaps), ch06 (acquisition pathways), ch07 (implementation appendices/tools/contracting).
Supporting files: glossary.md, patterns.md, cheatsheet.md.
One discipline, two architectures. MOSA is a technical architecture (modular components behind open interfaces) and a business architecture (contracting, IP, data rights). A clean interface the Government cannot legally exploit is not, in MOSA terms, a success.
Core Frameworks & Mental Models
What MOSA is — and why it is mandatory
A Modular Open Systems Approach (MOSA) is a combined acquisition and design approach that pairs a technical architecture with a business architecture, both oriented around system interfaces that conform to widely supported, consensus-based standards. The structural payoff is severability: components can be added, removed, or swapped incrementally across the life cycle, opening the system to efficiency, competition, and innovation. MOSA is no longer discretionary — recent law compels it.
The statutory → regulatory → contract chain
Authority cascades, and a break anywhere (especially insufficient data rights) defeats the whole:
- Statute — 10 U.S.C. 4401–4403 (4401 = mandate + definitions for MDAPs; 4402 = capabilities development and weapon-system design; 4403 = interface availability/support). The FY2017 NDAA introduced major system component and major system interface and required MOSA for MDAPs at Milestone A/B after Jan 1 2019; the FY2021 NDAA Section 804 added modular system interface, emphasized interface data and repositories, and expanded the mandate to all programs to the maximum extent practicable.
- Regulation — the DFARS (Part 207.106, 227.7203-2; clauses 252.227-7013/-7015/-7018; rulemaking case 2021-D005) and the data-rights framework of DFARS 252.227.
- Contract — the RFP, Acquisition Strategy, SEP, and CDD turn the mandate into a binding obligation on industry.
The five OUSD(R&E) pillars
The current authority's organizing framework (it supersedes the 2013 OSA guidebook), read as a progression where each pillar depends on the earlier ones:
- Establish an Enabling Environment — set requirements, business practices, strategy, and T&E methods before design hardens.
- Employ a Modular Design — identify each component's functionality before the RFP, so business and technical objectives drive the partitioning.
- Designate Modular Interfaces — decouple the interface from the implementation so a component and its interface can follow separate life cycles.
- Leverage Consensus-Based Open Standards — standardize interfaces with open, consensus-developed standards; manage Government-owned interface repositories.
- Certify Conformance — verify and validate that the implementation actually conforms to the selected open standards. Without this, the other four are claims, not facts.
The interface lifecycle (Figure 3-1)
A maintained, living framework: plan → modularize → identify interfaces → define interfaces → standardize interfaces. Plan measurable objectives and governance; decompose capability into self-contained functional modules; locate the boundaries where modules exchange data, signals, or commands; turn them into explicit protocols and data formats on open standards; lock the specifications to consistent open standards. It is a pipeline, not a menu — skip define or standardize and the modules aren't actually swappable.
Technical levers (§3.2)
- WBS as MOSA taxonomy (MIL-STD-881F, MIL-STD-196G naming) — align the Work Breakdown Structure to MOSA principles (modularity, openness, scalability, flexibility, reusability), then call out modules, interfaces, and test needs (Table 3-1).
- Standards selection and profiling — favor consensus-based standards (10 U.S.C. 4401), search ASSIST/MOSS, and write a profile to pin a standard's optional variability so implementations actually interoperate.
- Software — design API-first with hardware-grade modular rigor; declare data rights at the right abstraction (DoDI 5000.87); for cybersecurity, prefer a DevSecOps + MBSE + consensus-standard (FACE/OMS) path over a single proprietary transport service.
- COTS — run a business case analysis first; a design change to a COTS baseline can trigger costly regression testing or recertification, erasing the benefit.
Assessment, technology change, and roadmaps
- Five benefit classes anchor metrics: Interoperability, Technology Refresh, Enhanced Competition, Innovation, Cost Avoidance/Savings — reduced to the necessary few per use case and maturity. Use pass/fail for a proposed architecture, metrics-based assessment (Appendix A) when supporting mechanisms exist.
- DMSMS (obsolescence) is mitigated by multi-vendor sourcing through open interfaces and by involving DMSMS practitioners early; coordinate with USD(A&S).
- Two roadmaps, one clock — a product roadmap (what value, when) plus a technology roadmap (what must be ready, when) isolate volatile technology behind stable interfaces.
Contracting and the implementation toolkit (Appendices)
- Assessment tools chosen by stakeholder and level: PART (Army), OAAT/OAAM (Navy, business + technical axes 0–4), KOSS (NAVAIR, lock-prone subsystems), SEAM (Air Force). MAUT scores trade-offs against life-cycle cost.
- Enforceability rides on deliverable data — CDRLs backed by DIDs (OSMP, SEMP, DSM) traced to WBS/GRA node levels; the DSM is constrained so it cannot alter Government-designated interfaces. Front-load: evaluate a draft OSMP before award. Non-FAR vehicles (OTAs) carry no DFARS data rights automatically while the MOSA mandate still applies.
- Desired modularity is a deliberate cost-benefit point on a spectrum, and Conway's Law warns that the architecture inherits the organization's communication seams.
Chapter Index
| # | Section | Key content |
|---|
| ch01 | Introduction & Policy | MOSA definition; statutory chain (10 U.S.C. 4401–4403, FY2017/FY2021 NDAA); DFARS policy and clauses; data rights; terminology discipline |
| ch02 | Pillars & Benefits | The five OUSD(R&E) pillars; primary benefits; secondary benefits; tri-Service memorandum; supersedes 2013 OSA |
| ch03 | Program Management & Interface Lifecycle | Cost-benefit gate; plan→modularize→identify→define→standardize; JCIDS integration; mandatory + supporting documents; ICD/IRS |
| ch04 | Technical Considerations | WBS/MIL-STD-881F taxonomy; requirements; standards selection and profiling; API-first software; cybersecurity; COTS |
| ch05 | Assessment, Technology Change & Roadmaps | Five benefit classes; pass/fail vs. metrics; DMSMS; product + technology roadmaps; Appendix A methodology |
| ch06 | Acquisition Pathways & Conclusion | AAF and the six pathways; MCA prescriptiveness; EMD/P&D RFPs; MOSWG/TSWG governance |
| ch07 | Implementation Appendices | Assessment tools (PART/OAAT/KOSS/SEAM); GRA; contracting, CDRLs/DIDs; pillar actions; MAUT; workforce/DAU CLE 019 |
Topic Index
- 10 U.S.C. 4401–4403 / statute → ch01, ch06
- AAF (Adaptive Acquisition Framework) → ch06
- Acquisition pathways (six) → ch06
- Acquisition Strategy → ch03, ch06
- API-first / software design → ch04
- ASSIST / MOSS database → ch04
- Assessment metrics / benefit classes → ch05
- Assessment tools (PART, OAAT, KOSS, SEAM) → ch07
- Benefits of MOSA → ch02
- Business case analysis (COTS) → ch04, ch07
- Conformance certification → ch02, ch07
- Contracting / CDRLs / DIDs → ch07
- Conway's Law → ch07
- COTS → ch04, ch07
- Cost-benefit analysis → ch03
- Cybersecurity (software / hardware) → ch04
- Data rights → ch01, ch07
- Desired modularity → ch07
- DFARS → ch01
- DMSMS / obsolescence → ch05
- Government Reference Architecture (GRA) → ch07
- Interface lifecycle (plan/modularize/identify/define/standardize) → ch03
- JCIDS → ch03
- MAUT → ch07
- MIL-STD-881F / WBS taxonomy → ch04
- MOSWG / TSWG governance → ch06
- NDAA (FY2017 / FY2021 Section 804) → ch01
- Pillars (five OUSD(R&E)) → ch02, ch07
- Profile (standards variability) → ch04
- Roadmaps (product / technology) → ch05
- SEP (Systems Engineering Plan) → ch03
- Standards (consensus-based open) → ch04, ch02
- Technology refresh / insertion → ch05
- WBS → ch04
Supporting Files
- glossary.md — key MOSA terms (statutory, pillar, interface, assessment, contracting), alphabetical, with chapter references
- patterns.md — reusable patterns (cost-benefit gate, interface-lifecycle pipeline, WBS taxonomy, build-in-not-bolt-on, IP-rights targeting, contractual enforceability, metrics + roadmaps) with When/How/Trade-offs
- cheatsheet.md — quick decision rules, the five pillars, benefit classes, the statute→regulation→contract chain, MOSA across the six pathways, mandatory vs. supporting documents, tells & smells
Scope & Limits
Covers: the Modular Open Systems Approach as U.S. DoD weapon-system acquisition and design policy per the OUSD(R&E) Implementing a MOSA in DoD Programs guidebook (Feb 2025) — the statutory and DFARS basis, the five pillars, the interface lifecycle, the technical levers (WBS taxonomy, standards profiling, software/cybersecurity, COTS), MOSA assessment metrics and service tools, technology-change/DMSMS management and roadmaps, MOSA across the AAF pathways, and the contracting/IP/data-rights mechanics and workforce considerations in the appendices.
Does not cover / thin on: the engineering of any specific interface standard — it names FACE, OMS, DISR, FIPS 140-2, etc. without reproducing or detailing them; the underlying systems-engineering processes that MOSA requirements ride on (use dau-se-guidebook / nasa-npr-7123) and general SE theory or open-architecture concepts beyond DoD policy (use sebok / se-standards-signpost); non-DoD or commercial open-systems practice; and the full text of the cited statutes, DFARS clauses, and 5000-series instructions (named, not reproduced). Terminology note: legacy terms such as key interface lack a current statutory definition and the appendices carry an older legacy five-pillar set alongside the current OUSD(R&E) pillars — anchor any non-statutory term to the statute.
Jurisdiction & source: U.S. Government public-domain work (Distribution A); guidance is mandatory for the DoD programs it governs and is current as of the February 2025 guidebook (DOPSR case 25-T-1210). Tracks an evolving statutory/regulatory landscape (e.g. renumbering of 10 U.S.C. 2320→3771, 2446a→4401; DFARS case 2021-D005 still finalizing) — verify citations against the current instruments.