Why Defense Primes Are Spinning Up Digital Engineering Centers of Excellence

Between 2022 and 2025, every major defense prime contractor stood up — or significantly expanded — a dedicated Digital Engineering Center of Excellence. Northrop Grumman, Raytheon Technologies (now RTX), L3Harris, and Boeing Defense all made organizational announcements, hired program managers with “digital engineering” in their titles, and began publishing internal playbooks for how programs should implement model-based systems engineering, digital threads, and connected traceability.

The immediate catalyst was not a sudden internal revelation. It was the DoD Digital Engineering Strategy, published in 2018, followed by increasingly concrete contract language in defense acquisition programs requiring evidence of digital engineering implementation. When customers write compliance requirements into RFPs and award criteria, organizational responses follow. The CoE model was the response the industry landed on.

What These Centers Actually Do

A Digital Engineering Center of Excellence is, at its core, a capability-building and standards-setting body. It is not a delivery organization — it rarely owns program execution responsibility. Its functions fall into three broad categories.

Toolchain governance. The CoE evaluates, procures, and maintains enterprise licenses for the tools programs are expected to use. This includes systems modeling environments, requirements management platforms, simulation frameworks, and increasingly, the integration infrastructure that connects them. When a prime negotiates an enterprise agreement with IBM for DOORS Next or with Dassault for Cameo, the CoE is typically the internal sponsor and owner of that agreement.

Methods and standards development. Beyond tools, the CoE produces internal standards: how models should be structured, what metadata is required for traceability, what the artifact set looks like for a Preliminary Design Review in a digital engineering context. These become the internal equivalents of MIL-STD guidance, written to satisfy both customer audit requirements and the prime’s own engineering governance.

Training and workforce development. This is where CoEs spend more time than they expected. Tool adoption at scale requires more than licensing. It requires engineers who were trained on document-based processes to change how they work. Most primes underestimated this. The workforce challenge — particularly for engineers in their 40s and 50s who built careers on Word documents, Excel matrices, and IBM DOORS classic — has been the most time-consuming CoE function in practice.

A fourth function has emerged more recently: competitive differentiation. As digital engineering language appears in source selections, primes have begun treating CoE outputs as proposal content. The ability to demonstrate a mature digital engineering approach, backed by a real internal CoE and real program deployments, has become part of competitive positioning.

How CoEs Influence Tool Selection

The influence CoEs exercise over program-level tool decisions varies considerably across organizations and even across programs within the same organization.

At RTX, the CoE model has leaned toward establishing preferred platforms with strong guidance but preserving some program-level flexibility, particularly on legacy programs where switching costs are prohibitive. New starts are expected to align to enterprise-standard toolchains from day one. Existing programs in execution are given transition roadmaps, not mandates with hard deadlines — a practical concession to schedule risk.

At Northrop Grumman, internal reporting suggests a more prescriptive approach on certain classified programs, where the digital thread architecture is tightly specified and tool deviation requires CoE waiver. This makes governance cleaner but introduces friction when program teams encounter limitations in mandated tools that don’t surface until mid-program.

L3Harris, operating across a more distributed acquisition portfolio from multiple legacy company mergers, has faced the hardest standardization challenge. The CoE there has focused more on defining interoperability standards — how tools exchange data — than on mandating specific tools, which is a pragmatic acknowledgment that enterprise monoculture is unachievable across that kind of program diversity.

Boeing Defense’s situation is complicated by the broader Boeing organizational context. The CoE effort there has been real, but has operated under considerable organizational pressure from program performance issues on fixed-price development contracts that have dominated internal attention and resource allocation.

The common pattern across all four: new program starts are where CoE influence is strongest. Legacy programs and programs in late development or production largely operate with the toolchains they have. The CoE’s effective domain is the front end of program life cycles.

Is the Investment Producing Results?

This is the question program managers, CFOs, and customer program offices are all asking. The honest answer is: sometimes, unevenly, and it is hard to measure cleanly.

The most credible evidence of improvement comes from requirements volatility management. Programs that have implemented connected traceability — where a requirement change automatically surfaces impacted design elements, verification events, and dependent requirements — report reductions in late-cycle defect escapes tied to requirements misalignment. When an engineer can run an impact analysis in minutes rather than days, more analyses actually get run. That is a real operational improvement.

Where CoEs have demonstrated less impact is in the deeper problem of requirements quality. A well-connected requirements database filled with poorly written, ambiguous, or decomposed-but-not-traced requirements does not perform better than a flat document with the same problems. The tooling is necessary but not sufficient. This is a harder problem, because it requires changing how systems engineers write requirements, not just how they store and link them.

Program schedule and cost performance data at the prime contractor level is not publicly available in a form that permits clean attribution to digital engineering maturity. The GAO has begun asking about digital engineering in its annual weapon systems assessments, but the data is still early and program populations are small. What is observable is that programs that have gone through full MBSE implementations on new starts — where the model was authoritative from the beginning rather than reconstructed from documents — are reporting fewer interpretation discrepancies between systems engineering and design teams at CDR. That is meaningful, even if it is not a cost savings number.

The Tension: Enterprise Mandates vs. Program Autonomy

The structural tension at the center of the CoE model has not been resolved. It has been managed, imperfectly.

Enterprise tool mandates exist because standardization creates real value: cross-program talent mobility, reusable model architectures, negotiating leverage with vendors, and consistent audit artifacts. These are legitimate benefits. A prime with 80 programs all using the same requirements management platform and the same traceability schema can move engineers between programs, build shared libraries, and train the workforce once.

Program-level engineering teams operate under a different set of incentives. They are measured on cost and schedule performance for their specific program. A tool that is technically superior in the abstract, but requires six months of data migration and a workforce retraining effort, is a schedule risk they are being asked to absorb for benefits that accrue elsewhere. When enterprise IT timelines slip — and they always slip — programs that waited for enterprise infrastructure end up holding the cost.

This tension has produced a predictable equilibrium in most organizations: formal compliance with enterprise tool mandates, combined with informal workarounds at program level. Engineers use the mandated platform for artifacts that go into reviews and audits. They use spreadsheets, local scripts, and increasingly, purpose-built AI tools for the actual analytical work. The enterprise platform becomes a documentation system rather than an engineering system.

This is not a failure of the CoE model specifically. It is a consequence of procurement and governance cycles being far slower than the pace at which engineering teams need to work. It is also an area where the tool landscape is shifting in ways that matter.

What Modern Tooling Is Changing

The CoE model was designed around legacy enterprise platforms — IBM DOORS, DOORS Next, Polarion, Jama Connect — which were built as document management and requirements database systems with collaboration and traceability features added over time. These platforms are mature, deeply integrated into defense acquisition workflows, and carry significant organizational inertia.

What is changing is the availability of purpose-built AI-native platforms that approach requirements management and traceability as graph and inference problems rather than document management problems. The difference is not cosmetic. When you model a requirements architecture as a connected graph, you can ask questions about it — “what breaks if this requirement changes?” — without running a manual query or exporting to a spreadsheet. When AI is built into the core of how requirements are written and analyzed, rather than added as a plugin to an existing document store, the engineering capability is qualitatively different.

Tools like Flow Engineering represent this newer generation: built from the ground up for systems engineers working on complex hardware programs, with AI-assisted requirements authoring, graph-based traceability, and impact analysis that is genuinely fast enough to use during a working session rather than as a batch process. CoEs at several primes have begun evaluating platforms in this category, initially for new program starts where there is no legacy data migration burden.

The evaluation question being asked is not “is this better than DOORS?” in the abstract. It is “can this run alongside our enterprise platform for programs where the legacy toolchain is entrenched, while being the primary environment for new starts?” The answer, for the leading AI-native platforms, is increasingly yes.

Honest Assessment

The Digital Engineering Centers of Excellence are real organizations doing real work, and the primes that have invested in them are better positioned than they would have been without them. The workforce training function alone has produced measurable improvements in how engineers think about requirements structure and traceability.

The limitations are equally real. CoEs have been more effective at governing tools than at changing how engineers think about requirements. They have been more effective on new starts than on legacy programs. They have been more effective at producing audit-ready artifacts than at producing engineering insight during program execution.

The DoD’s expectation — embedded in the Digital Engineering Strategy and reinforced in contract language — is that digital engineering produces better programs, not just better documentation. Meeting that expectation requires the full stack: capable tools, genuine workforce behavior change, and requirements quality at the source. The CoE model addresses all three, but the tool layer is the easiest and the requirements quality layer is the hardest. Most CoEs have made more progress on the former than the latter.

The programs that will demonstrate the clearest outcomes from this investment are the ones that started digital — where the model was authoritative from the first requirement, the traceability was built in rather than retrofitted, and the CoE’s standards were designed in rather than imposed. Those programs are still in early development. The data on whether this generation of digital engineering investment produces the program performance outcomes the DoD is paying for will be visible in the 2028–2032 timeframe, when today’s new starts reach CDR and early production milestones.

That is not a comfortable answer. It is the accurate one.