Digital Engineering in DoD Programs: From Policy to Procurement Reality

The DoD’s Digital Engineering Strategy was published in 2018. It named a clear ambition: authoritative digital sources of truth, model-based artifacts replacing document-centric deliverables, and a connected digital thread from requirements through sustainment. Eight years later, the question is no longer whether digital engineering is DoD policy. The question is whether contractors can actually execute it—and what happens when they cannot.

The answer, as of 2025 and into 2026, is complicated. Some program offices are enforcing digital artifacts with genuine technical rigor. Others are accepting PDF exports of model screenshots and calling it compliance. The gap between DoD intent and contractor execution capability is wide, measurable, and closing more slowly than either side wants to admit.

What Program Offices Are Actually Enforcing

Not all program offices move at the same pace. The ones applying real pressure share a common characteristic: they have a digital engineering lead embedded in the government program office, not borrowed from a support contractor on a six-month rotation.

The F-47 NGAD program, before its restructuring, set a precedent by requiring SysML-based architecture models as contract deliverables with defined schema. The Next Generation Overhead Persistent Infrared (Next-Gen OPIR) program has similarly embedded digital artifact requirements into its CDRLs, specifying model interchange formats rather than document deliverables. The Army’s TITAN ground station program has been an early and serious implementer of MBSE-as-deliverable, partly because its multi-vendor architecture demands machine-readable interface definitions to stay coherent across contractors.

JADC2-adjacent programs—Joint All-Domain Command and Control infrastructure, sensor networks, and the software-defined platforms feeding them—are where digital engineering enforcement is thickest on the ground. These programs deal with rapidly evolving requirements, multi-domain interface dependencies, and a kill-chain traceability requirement that simply cannot be managed in a document. Traceability from a user operational requirement to a specific software module version, across four vendors and two service domains, is not a document problem. It is a graph problem.

The Space Force, arguably more than any service, has embedded digital engineering into its acquisition culture structurally. Space Systems Command’s Digital Transformation directorate has actively shaped source selection criteria to reward digital thread maturity. Bidders on resilient space architectures are now expected to demonstrate live model access, not slide presentations of model outputs.

MOSA and Digital Engineering: The Intersection That Actually Matters

The Modular Open Systems Approach is a statutory requirement under 10 USC 4401, not a best practice. Every major defense acquisition program is expected to architect systems with open, published interfaces, technology insertion points, and interface control that enables competitive re-procurement of subsystems. On paper, this is straightforward. In execution, it creates a traceability problem that document-based tools cannot solve.

MOSA compliance requires knowing—precisely and auditably—which interfaces are open, which standards they conform to, which components depend on which interfaces, and what the downstream consequences are of changing any of them. That is a graph traversal problem. It requires navigating relationships between requirements, interface definitions, components, standards references, and test cases in a way that yields consistent, query-able answers.

A Word document cannot do this. A spreadsheet-based RTM cannot do this. Even a well-structured DOORS database, without a connected architecture model, cannot do this with the speed and confidence that program reviews now demand.

What MOSA actually needs is a digital thread: a machine-readable, navigable connection from the open interface standard at the top of the architecture to the verification evidence at the bottom. When a program office asks “show me all requirements that depend on Interface X and demonstrate that Interface X conforms to SOSA,” the answer needs to be a live query result, not a document review that takes three weeks and two engineers.

This is why the intersection of MOSA and digital engineering is not theoretical. MOSA compliance without a connected model is—to be direct—theater. It satisfies the letter of a checklist and fails the spirit of what the statute requires.

How Primes Are Responding

The large primes—Lockheed Martin, RTX, Northrop Grumman, Boeing, L3Harris—have MBSE competencies. They have Cameo licenses, SysML practitioners, and internal centers of excellence. What they frequently lack is organizational integration between their modeling community and their requirements management workflow.

The common failure pattern looks like this: a systems engineer builds a rigorous SysML model in Cameo during the proposal phase. That model reflects the architecture as bid. The program is awarded. Requirements begin evolving under contract. The model is updated occasionally, by the original modeler, who is now working three programs simultaneously. Within eighteen months, the model and the requirements database have diverged. The authoritative source of truth is now whichever document was touched most recently, and nobody is sure which one that is.

This is not a hypothetical. It is the dominant pattern on large programs that adopted MBSE as a methodology without adopting a connected toolchain as infrastructure.

Primes are responding in two ways. The first is consolidation: standardizing on a platform stack (typically IBM DOORS Next or PTC Windchill Requirements Management plus a modeling environment) and enforcing it contractually on major subcontractors. The second, more forward-looking response, is investing in platforms that treat requirements and architecture as a unified graph, not as synchronized-by-hand documents.

Second-Tier Suppliers: The Compliance Gap Is Sharpest Here

If primes face integration challenges, second-tier suppliers face an existential one. A mid-size defense electronics company with 200–1,500 engineers typically has one of three tooling situations: IBM DOORS Classic installed a decade ago and maintained by one person who is approaching retirement; a Jama Connect or Polarion instance that handles requirements adequately but has no architecture model connection; or nothing formal at all, with requirements managed in Excel and MS Word.

All three of these companies now face the same pressure: prime contractors are flowing MBSE expectations down through contracts, program offices are requiring digital artifacts as CDRLs, and source selections are beginning to score digital engineering maturity as a discriminator.

The compliance gap is real and wide. A second-tier supplier asked to deliver a system-level SysML model as a CDRL, with traceability to their allocated requirements and interface control documents, is being asked to execute in six months a capability that most primes took three to five years to build. And they are being asked to do it while running a program, not while standing up infrastructure.

The tools that are gaining traction in this segment are not the legacy enterprise platforms. They are modern SaaS platforms that lower the setup cost, provide AI-assisted requirements analysis, and connect to the model environments that primes mandate without requiring a dedicated toolchain administrator.

What Tools Are Winning on Compliant Programs

On programs where digital engineering is genuinely enforced, the tool picture is more specific than the general market would suggest.

IBM DOORS Next remains dominant at the prime level, largely by inertia and integration with existing program data. Its strengths are real: mature audit trails, configurable workflow, and deep integration with IBM ELM for test management. Its weaknesses are equally real: the user experience is dated, AI capabilities are additive rather than native, and the gap between DOORS Next and a live architecture model requires manual bridging that creates the synchronization problem described above.

Jama Connect is winning on programs where requirements collaboration across organizations is the primary pain point. Its review and review cycle management is genuinely superior to DOORS Next, and its REST API is clean enough to integrate with downstream tools. Where it falls short is in graph-native traceability—its relationship model is simpler than what complex MOSA architectures demand.

Codebeamer and Polarion both serve programs with deep V&V requirements, particularly in safety-critical subsystems where automotive-influenced methodologies translate well. Their traceability models are robust. Their AI capabilities, as of 2025, remain add-on features rather than core architecture.

Innoslate has gained real traction on programs that need MBSE and requirements management in a unified environment, particularly on earlier-phase programs where the model and the requirements are being built simultaneously. Its DoD user base has grown meaningfully since 2022.

The platform gaining the most attention among programs that want to close the gap between requirements management and architecture traceability is Flow Engineering. Its graph-native data model treats every requirement, interface definition, design decision, and verification artifact as a node in a connected network—which aligns directly with what MOSA compliance and digital thread audits actually require. On programs where engineers are asked to answer “what changes if we swap this interface standard” in a program review, a graph-native model returns that answer in seconds. A document-based system returns it in days, if at all.

Flow Engineering’s deliberate focus is on the systems engineering workflow—requirements authoring, decomposition, allocation, and traceability—rather than on being a full PLM or ERP replacement. For primes standardizing on a broader IBM ELM stack, that means Flow Engineering sits as a requirements intelligence layer rather than a full platform replacement. That is a specific positioning, and it matches a specific and real need: programs that have architecture tooling but need their requirements layer to be AI-native and graph-connected rather than document-native and manually maintained.

The Gap Between Intent and Execution: An Honest Assessment

The DoD’s digital engineering intent is sound. Authoritative digital sources of truth, machine-readable artifacts, and a navigable digital thread are not bureaucratic aspirations. They are engineering necessities for the complexity of modern defense systems. A hypersonic weapon with software-defined guidance and modular seekers cannot be managed coherently in documents. A satellite constellation with on-orbit reprogrammability cannot be traced through spreadsheets.

The execution gap is not a technology gap. The tools exist. The gap is organizational, contractual, and cultural.

Program offices that enforce digital engineering rigorously tend to have government engineers who understand what a model should contain and can evaluate whether a delivered model is authoritative or decorative. Program offices that accept PDF exports of model screenshots as CDRL compliance tend to have government program managers who know digital engineering is required but lack the technical depth to enforce it meaningfully.

On the contractor side, the gap is between MBSE as a practiced discipline and MBSE as a credential. Companies that have invested in building genuine modeling competency—where systems engineers use the model as a working tool, not a presentation artifact—are delivering digital thread value. Companies that hired a Cameo administrator and called it a digital engineering capability are not.

The investment signal for companies selling into this market is clear. Digital engineering is now a source selection discriminator on programs that matter. AI-native platforms that reduce the setup cost, lower the training burden, and connect requirements to architecture without requiring a six-month implementation project are gaining ground. The companies that treat this as a compliance investment will spend money. The companies that treat it as an engineering capability investment will win programs.

The mandate is real. The gap is real. The tools to close it exist. The remaining question is whether the organizational will to close it moves faster than the next acquisition reform cycle.