The Role of Digital Engineering in Accelerating Defense Acquisition
The U.S. Department of Defense released its Digital Engineering Strategy in 2018. The document was unusually specific for DoD policy: it named five concrete pillars, called out the dependency on authoritative digital sources of truth, and acknowledged directly that current acquisition processes were designed around document exchange rather than model exchange. Program managers were told, in effect, that the way defense programs had been run for sixty years was the problem, and that digital engineering was the solution.
That was eight years ago. The question for 2026 is not whether digital engineering is a good idea. It is whether the programs that matter — the ones with decade-long schedules, multi-billion-dollar overruns, and national security implications — have actually changed how they operate. The answer is partial, uneven, and worth examining in detail.
What the Digital Engineering Strategy Actually Says
Before assessing implementation, the strategy’s five pillars deserve a precise summary, because loose paraphrasing has allowed a lot of non-compliance to present itself as alignment.
Pillar 1: Formalize digital engineering as a discipline. This means integrating DE practices into DoD policy, acquisition frameworks, and workforce development — not treating it as a program-by-program experiment.
Pillar 2: Provide access to a robust digital engineering ecosystem. Standards, reference architectures, interoperability frameworks. The goal is an ecosystem in which models from different contractors and government agencies can be integrated without bespoke translation layers.
Pillar 3: Invest in digital engineering infrastructure. Shared environments, government-accessible model repositories, secure collaboration platforms.
Pillar 4: Establish a digital engineering workforce. Training, certification, hiring. The document acknowledges explicitly that tool adoption without human capability is theater.
Pillar 5: Integrate digital engineering across the acquisition lifecycle. Requirements, design, test, sustainment — the model as the authoritative artifact at every phase transition, not a documentation artifact produced after the real engineering has happened.
The strategy’s underlying premise is that these pillars are interdependent. Infrastructure without workforce is wasted. Workforce without ecosystem interoperability creates isolated capability islands. Formalized policy without enforcement against Pillar 5 produces exactly the checkbox compliance problem the strategy was meant to prevent.
Where Progress Has Been Measurable
Three programs illustrate what genuine digital engineering adoption produces when it’s enforced as a contract requirement rather than encouraged as a best practice.
Next Generation Air Dominance (NGAD). The program used Model-Based Systems Engineering (MBSE) from concept definition, with the government holding model access rights as a contract term. Early integration of SysML-based architecture models allowed requirements decomposition to propagate automatically to subsystem contractors, reducing the interpretation lag that historically added months to interface control document cycles. While NGAD’s schedule details are classified, program office statements have indicated that the digital thread connecting requirements to design artifacts shortened preliminary design review preparation by a meaningful margin compared to comparable fifth-generation program baselines.
F-35 Block 4 Modernization. The F-35 program office retrofitted digital engineering practices onto a program that did not start with them — a harder problem than greenfield adoption. The specific success here was in software-hardware interface management. By establishing an authoritative digital model of avionics interfaces and enforcing model-based change control, the program reduced interface defects discovered late in integration. Lockheed Martin’s public reporting credits the shift from document-driven to model-driven interface management with measurable reductions in late-stage rework cycles.
Joint All-Domain Command and Control (JADC2). The JADC2 architecture effort is inherently a digital engineering problem: it requires integrating systems developed by different contractors across different military branches against a common architecture. JADC2 has made the most visible progress on Pillar 2 — ecosystem interoperability — specifically through the adoption of the Universal Nodal Framework and investments in architecture model exchange standards. The challenge of cross-domain model integration has made JADC2 the program where data rights barriers are most visibly consequential, discussed below.
The Persistent Barriers
Legacy Contractor Tooling
The major defense primes — Lockheed, Boeing, Raytheon, Northrop — each have internal MBSE toolchains that are deeply embedded in their engineering workflows, integrated with their configuration management systems, and supported by internal workforce training programs built over years. The tools are not identical. Cameo (now Magic Systems of Engineer), DOORS and DOORS Next, Rhapsody, Capella — these tools produce models in formats that are not natively interoperable. SysML v2 was supposed to address this at the language layer, and its formal release in 2024 has begun to influence procurement language, but toolchain migration at prime contractor scale is measured in years, not quarters.
The practical result: when a program requires MBSE, each contractor delivers a model, and the government program office — or a systems integrator — must manually reconcile models built in different tools against different internal conventions. This is not what the Digital Engineering Strategy envisioned. It is, however, what most programs experience.
The response from DoD has been to invest in model exchange infrastructure — the Digital Engineering Authoritative Source of Truth (DEAST) initiatives and the Platform One ecosystem. These investments are real but slow. Tool standardization by government mandate has been tried and resisted by industry on competitive grounds. The most promising near-term path is contract language that specifies model exchange formats (SysML v2, AP233) and government data access rights, rather than tool standardization.
Data Rights
This is the barrier that program managers consistently identify as harder to solve than tooling. Defense contractors treat their systems models as proprietary intellectual property. A model contains not just architecture documentation but embedded engineering knowledge — tradespace decisions, design alternatives considered and rejected, internal interface conventions — that represents years of investment. Contractors are unwilling to deliver unlimited-rights models to the government, and in many cases unwilling to deliver them to other contractors on the same program.
The result is that the digital thread — the connected chain from validated requirements through design to test results — breaks at contractor boundaries. Government program offices receive document exports of models, not models. Those exports cannot be queried, cannot propagate changes, and cannot serve as authoritative sources of truth for downstream work.
DFARS clause evolution has been the primary policy lever here, with updated guidance on technical data rights in digital formats. Progress is real but contested. Prime contractors have challenged data rights interpretations, and the legal landscape remains unsettled enough that program managers frequently accept document delivery rather than litigate model delivery rights on every contract action.
Cross-Boundary Integration
Even where tooling compatibility improves and data rights are resolved, integrating digital artifacts across contractor boundaries introduces an architectural problem: whose model is authoritative when two contractors’ models conflict?
This is not a hypothetical. In multi-contractor programs, subsystem interface definitions exist in multiple models maintained by different organizations. When an interface changes, the change must propagate across model boundaries. Without an enforced, government-controlled integration model that subsystem models must conform to, this propagation happens through email, meeting notes, and document revision cycles — the same process the Digital Engineering Strategy was meant to replace.
The programs that have managed this successfully share a common pattern: a government-held, contractor-accessible integration model that acts as the authoritative interface register, with contract language requiring subsystem models to demonstrate conformance to that integration model at each review milestone.
Checkbox Compliance: What It Looks Like and Why It’s Hard to Audit
The DoD’s MIL-HDBK-520 and associated MBSE guidance have created a de facto compliance language. Program proposals describe model-based requirements management, digital threads, and authoritative sources of truth. Contract deliverables include “MBSE model” as a line item. Government technical representatives sign off on delivery.
What gets delivered, in checkbox compliance programs, is typically one of three things:
- A Cameo or Rhapsody model that documents requirements as they existed at contract award, maintained by one engineer, never queried by anyone outside the systems engineering team.
- A SysML block diagram that represents the architecture at one point in time, not connected to the requirements baseline, the test results, or the change control system.
- An RTM exported to Excel from a requirements tool, with “generated from model” in the header.
None of these constitute a digital thread. None of them allow change impact to propagate. None of them enable the program office to ask “what requirements does this subsystem satisfy, and what is the current test evidence for each?” and get a live answer.
The difficulty in auditing this from the program office is real. Government technical representatives are not always trained to distinguish a live, queryable model from a document that looks like one. Audit criteria in existing DI-IPSC data item descriptions were written for document deliverables and don’t map cleanly to model evaluation.
The signal that separates meaningful adoption from compliance theater is behavioral: are decisions being made from the model, or is the model being updated to reflect decisions already made by other means? When a requirement changes, does the impact analysis come from the model, or from a senior engineer’s memory? When a test fails, does the traceability to affected requirements update automatically, or does someone manually update a spreadsheet?
What Meaningful Adoption Looks Like in Practice
Programs that have moved past compliance theater share several operational characteristics.
Requirements are authored in the model, not imported into it. When requirements originate in a structured, graph-based requirements tool that connects directly to the architecture model, the model is the authoritative source from day one. Retrofitting a model onto a Word document baseline produces a model that is always chasing the real engineering.
Change impact is computational, not manual. When a requirement changes, the tool generates — automatically — a list of design elements, test cases, and verification methods linked to that requirement. Engineers validate the impact list; they don’t construct it.
The traceability matrix is live. An RTM that requires manual update is a documentation artifact. An RTM that reflects the current state of model links, generated on demand, is an engineering tool. The distinction matters in program reviews: if the program office asks for traceability coverage on a subsystem and the answer takes two weeks to produce, the traceability is not live.
Modern tools have made this architecture more accessible. Tools like Flow Engineering, built specifically for hardware and systems engineering with a graph-based requirements model and AI-assisted traceability, demonstrate what it means to have requirements, design elements, and verification evidence connected in a structure that can be queried, not just read. The distinction between tools designed natively for connected traceability and tools that added traceability features to a document management foundation is operationally significant — it determines whether change propagation is automatic or manual, and whether the model can be interrogated or only reported on.
An Honest Assessment
The DoD’s Digital Engineering Strategy was well-conceived. Its five pillars correctly identified the interdependencies that make partial adoption fail. The programs that have enforced its requirements as contract terms — rather than encouraging adoption as a best practice — have demonstrated measurable schedule and integration benefits.
The barriers are real and not easily dismissed. Data rights conflicts are genuinely hard legal and policy problems, not just contractor obstruction. Legacy toolchain investment is real, and SysML v2 adoption at scale will take years. The workforce shortage in MBSE-trained systems engineers is not a problem that training programs solve in one budget cycle.
What the strategy has not produced, eight years in, is a reliable method for distinguishing programs that are doing digital engineering from programs that are describing digital engineering. Until government technical representatives have evaluation criteria calibrated to live models rather than document deliverables, and until contract language specifies model access rights and exchange formats rather than MBSE mentions, checkbox compliance will remain the path of least resistance for contractors.
The programs where digital engineering has demonstrably accelerated acquisition share one characteristic above all others: the government enforced model access and integration requirements as hard contract terms, not soft expectations. That is a program management decision, not a technology decision. The technology to do this right exists. The acquisition discipline to require it consistently does not yet.