The Digital Engineering Transformation in the U.S. Navy: Progress, Gaps, and What Industry Needs to Know

When the Department of Defense released its Digital Engineering Strategy in 2018, the U.S. Air Force was the visible early mover. F-35 production lessons, the rapid development of the B-21, and the Next Generation Air Dominance program all became reference cases for what digital engineering could do when a program office committed to it. The Navy watched, drafted its own strategy, and began rolling out digital engineering mandates across shipbuilding and aviation programs starting around 2021.

Five years into serious Navy DE implementation, the picture is complicated. Genuine progress exists in specific programs. Equally genuine stagnation exists in others. And a large tier of suppliers — the companies that actually manufacture the systems, subsystems, and components that go into ships and aircraft — are caught between contractual obligations they can’t fully meet and toolchain investments they can’t fully justify.

This article is an operational assessment for engineers and engineering managers working in or supplying to Navy programs. It is not a policy brief.

The Policy Foundation and Where It Has Traction

The Navy’s digital engineering strategy follows the core DoD framework: authoritative digital representations, connected data environments, model-based approaches across the lifecycle. The Navy added its own emphasis on the digital thread — the idea that requirements, design data, test results, and as-built configurations should be connected and traceable through a single logical chain rather than distributed across incompatible document repositories.

Where this has taken hold most visibly is in the submarine enterprise. The Virginia-class program and, more recently, the work being stood up for the SSN(X) successor program have both incorporated MBSE practices with more seriousness than most surface ship programs. The reasons are structural, not cultural. Submarine programs have longer development cycles, smaller numbers of platforms, higher unit costs, and extremely tight integration between hull, mechanical, and electrical systems. The pressure to find defects early — before steel is cut — is enormous, because the cost of finding them late is catastrophic.

The Columbia-class ballistic missile submarine program has similarly pushed digital engineering further than observers might expect given its legacy roots. The program office made an explicit decision early in the development phase to pursue model-based systems engineering for its most integration-intensive subsystems, particularly in the strategic weapons system interfaces and ship control domains. That decision is now paying dividends in configuration management, though full digital thread connectivity remains a work in progress.

Surface combatant programs present a more mixed picture. The DDG(X) next-generation destroyer program has digital engineering baked into its acquisition strategy from the outset — this is genuinely new, not retrofitted. DDG 51 Flight III, by contrast, involves a ship design that predates digital engineering by decades, and DE implementation there is primarily about managing engineering changes and modifications rather than building from a clean digital baseline.

The amphibious and logistics fleet tells the most uncomfortable story. LHA and LPD programs have made progress in pockets — particularly in systems like combat management and network architecture — but the integration of DE practices across the full hull, mechanical, and electrical scope has been slow. These programs have more distributed supplier bases, older design baselines, and program offices with less DE investment than the submarine enterprise.

What’s Actually Driving Progress When It Happens

The honest answer is contract language and program office funding. Cultural buy-in helps. Tool availability matters. But the programs that have moved fastest on digital engineering are the ones where DE requirements appeared in the RFP with specific deliverables, acceptance criteria, and — most importantly — where non-compliance carried consequence.

At the prime contractor level, General Dynamics Electric Boat and Huntington Ingalls Industries have both made substantial investments in digital engineering infrastructure. These are not optional commitments for shipbuilding primes of that scale; they are prerequisites for winning and retaining major naval contracts. Both have implemented MBSE toolchains, both have hired and trained systems engineers with model-based skills, and both have internal programs to extend DE practices to their critical suppliers.

The mechanism by which progress actually moves into programs is worth understanding precisely. Program offices that have succeeded tend to have done three things: defined the authoritative source of truth for the model, specified the interface standards for how suppliers contribute to it, and funded the transition rather than mandating it unfunded. Programs that have stalled tend to have done one or two of those things but not all three.

The model ownership question is particularly significant. In several programs, early DE adoption foundered because neither the program office nor the prime contractor nor the major subcontractors had clearly established who owned the authoritative systems model. Without that clarity, everyone builds their own model, the models diverge, and the digital thread breaks at exactly the organizational seams where it matters most.

Where MBSE Remains a PowerPoint Aspiration

The gap between policy and practice is most visible at Tier 2 and Tier 3 suppliers. A company that manufactures pumps, valves, control electronics, or structural components for a ship program may receive a contract deliverable requirement for model-based data in SysML or a related format. The same company may have no MBSE toolchain, no engineers trained in model-based methods, and no budget to acquire either.

This is not a small population. The naval shipbuilding supply chain is deep, and DE requirements are increasingly flowing down through contract structures designed for larger organizations. The result is one of two outcomes: suppliers produce nominal compliance artifacts — models that technically meet the format requirement but contain no genuine engineering content — or they subcontract the modeling work to consultants who produce deliverables without understanding the underlying system.

Neither outcome serves the purpose of digital engineering. Both outcomes are, at this moment, reasonably common.

The infrastructure problem is real. Enterprise MBSE toolchains from established vendors — IBM DOORS Next, Siemens Polarion, PTC Windchill — are capable tools built for large organizations with dedicated tool administrators and substantial licensing budgets. They are not practical for a 50-person engineering firm building specialized marine hardware. The choice those firms face is between under-investment in compliance and over-investment relative to program revenue.

It is in this specific context that AI-native, modern SaaS tools are beginning to matter. Requirements management platforms designed for connected traceability without the administrative overhead of legacy enterprise systems give smaller engineering teams a viable path to model-based practice. Tools like Flow Engineering, which build graph-based traceability and AI-assisted requirements analysis into a modern interface, can give a supplier-side engineering team the ability to manage requirements linkages, track verification status, and produce meaningful traceability artifacts without standing up a full MBSE infrastructure. This doesn’t replace a full digital engineering environment for a prime contractor, but it closes the compliance gap for organizations that would otherwise produce empty deliverables.

The structural question is whether Navy program offices will develop tiered DE requirements — scaled expectations for Tier 1 versus Tier 3 suppliers — or continue to flow down uniform standards that create uniform compliance theater. The former would require more sophisticated acquisition thinking. The latter is operationally easier in the short term and counterproductive in the long term.

Aviation Programs and the NAVAIR Comparison

Naval aviation programs operated under NAVAIR present a somewhat different picture from the shipbuilding enterprise. NAVAIR has been more consistent about digital engineering implementation, partly because the Air Force’s earlier precedents were directly applicable, and partly because aircraft programs already had more mature PLM toolchain investments that provided a foundation for DE expansion.

The F/A-18 sustainment programs are working through digital engineering adoption in a classic modernization context — trying to build digital representations of systems that were never designed that way. The progress is real but slow, and the priority is configuration management and modification tracking rather than new design development. F-35 Navy variants benefit from the joint program’s substantial DE infrastructure, which is one of the most mature in DoD.

The challenge area in NAVAIR is emerging unmanned systems programs. These programs move fast by naval acquisition standards, operate under different contracting mechanisms, and often involve non-traditional defense contractors who have strong software engineering practices but limited systems engineering toolchain maturity. The digital engineering requirements in these programs need to accommodate software-forward development cultures, and that accommodation is still being worked out.

Implications for the Supply Base

If you are an engineering manager at a company that supplies to Navy programs or is considering pursuing Navy work, the operational takeaways are concrete.

First, the DE requirements in your contracts are not going away and will expand. What is currently a data rights or deliverable format question will become a qualification requirement in future RFPs. The companies that begin building model-based practices now will have a competitive differentiator in three to five years.

Second, the toolchain decision matters. If your organization is large enough to justify an enterprise MBSE environment, the investment is worth making. If you’re not, you need a requirements management approach that delivers genuine traceability — connected requirements, linked verification, auditable change history — without the overhead. Understand what your prime contractor’s model interface requirements actually are before selecting tooling.

Third, the authoritative source of truth question will come to you eventually. In mature DE programs, suppliers are expected to contribute to a shared model environment, not just produce documentation. Understanding how your engineering data connects to the prime’s model, and what formats and exchange standards are required, is an engineering planning question, not a documentation question.

Fourth, your engineers need to understand systems modeling. This is a workforce development issue with a long lead time. The supply base that is competitive in Navy programs in 2030 will have systems engineers who can read and contribute to SysML models, who understand requirement-to-verification traceability as a technical discipline, and who treat the digital thread as an engineering artifact rather than a compliance artifact.

Honest Assessment

The Navy’s digital engineering transformation is real, uneven, and consequential. The programs where it is working — Columbia-class, DDG(X), significant portions of the Virginia-class enterprise — demonstrate that model-based systems engineering delivers genuine value in complex naval system development. The programs where it is stalling demonstrate that policy without program office investment, clear model ownership, and supply chain support produces compliance theater rather than engineering value.

For the supply base, the gap between what DE requires and what most Tier 2 and Tier 3 suppliers can practically deliver is the most underappreciated problem in naval acquisition right now. Closing that gap requires two things simultaneously: acquisition reform that creates scaled DE requirements appropriate to supplier size and role, and tooling evolution that makes model-based traceability accessible to engineering teams that are not large system integrators.

Both are happening, but neither is happening fast enough to match the pace at which DE requirements are flowing into contracts. That mismatch will create friction, compliance gaps, and program schedule risk across the naval industrial base for the next several years. The organizations that move now — building real practices rather than waiting for the friction to become contractually unavoidable — will be in a substantially better position when it does.