Ask five engineers on the same programme what the current design is and you can get five answers. Each one is correct for the document that engineer last opened.
Digital engineering is the promise that the answer stops depending on who you ask. One set of models and data, kept authoritative, read by every discipline from concept to disposal.
That sounds like a slide from a vendor deck. It is also, since December 2023, US Department of Defense policy, written into DoD Instruction 5000.97. This guide shows what it means on a real change, how it differs from MBSE, and where to start.
The definition, in one sentence
The definition the DoD uses is worth reading slowly, because every phrase is doing work:
Digital engineering is "an integrated digital approach that uses authoritative sources of system data and models as a continuum across disciplines to support life-cycle activities from concept through disposal."
| Phrase | What it rules out |
|---|---|
| Authoritative sources | "Latest_v7_FINAL.xlsx" on someone's laptop. If a number is not in the authoritative source, it is not the number. |
| System data and models | Documents as the primary record. Reports and drawings become views generated from the models. |
| As a continuum | Handing over a frozen snapshot at each gate and starting again downstream. |
| Across disciplines | A systems team with a beautiful model that design, test, cost and supply chain never open. |
| Concept through disposal | Stopping at critical design review. The model is still the reference in operation and maintenance. |
One change, two ways of working
Definitions only go so far. Here is a single requirement change on an electric vehicle door assembly, followed through both ways of working. The programme is illustrative; the steps are the ones every engineering change goes through.
The change: after a crash-test review, the requirement for the door latch to stay closed under a longitudinal pulse is raised from 30 g to 35 g.
| Step | Document-based | Digital engineering |
|---|---|---|
| Record the change | The requirements spec is updated and reissued as a new revision. | The requirement object is edited once. Its history shows who changed it, when and why. |
| Find what is affected | Someone searches the latch drawing, the crash simulation report, the test plan and the supplier spec for "30 g" and hopes nothing used a different wording. | The requirement is already linked to the latch design, the simulation, the verification test and the supplier allocation. The impact list is a query, not a hunt. |
| Tell the people who own them | An email with the new revision attached, sent to the list someone remembers. | Owners of every linked item are notified because the links say who they are. |
| Update the supplier | A revised specification is sent. The supplier's copy and yours are now two documents that must be kept in step. | The supplier works against the same requirement and records its evidence against it. |
| Close it out | Someone confirms by reading the updated documents side by side. | The test result is attached to the requirement. Open items show as open until the evidence exists. |
Nothing in the right-hand column needs exotic technology. What it needs is that every artefact lives in, or links to, one authoritative set of data. That is the whole idea.
Why documents drift
Documents do not go out of date because engineers are careless. They go out of date because every copy of a document is a fork. The moment a specification is emailed, exported or printed, there are two versions, and nothing connects them. Multiply that by every discipline, every supplier and every revision, and inconsistency is not a risk. It is the default.
Digital engineering removes the fork rather than policing it. People still produce reports, drawings and spreadsheets, but those are generated views of the authoritative data, not separate records competing with it.
Digital engineering vs MBSE
The two terms get used interchangeably. They are not the same thing, and the difference is scope.
| MBSE | Digital engineering | |
|---|---|---|
| Scope | Systems engineering: requirements, system architecture, verification and validation | Every discipline: design, simulation, manufacturing, cost, schedule, supply chain and operations |
| What it is | A method, a modelling language and a toolset | An organisation-wide way of working |
| Centre of gravity | The system model | Authoritative models and data across the lifecycle |
| Relationship | A core part of digital engineering | The ecosystem MBSE operates within |
A team can do excellent MBSE and still not be doing digital engineering, if the system model never connects to the CAD, the cost model or the test results. The worked example above is digital engineering precisely because the requirement reaches across all of them.
The pieces: ecosystem, thread and twin
Three terms come up in every digital engineering conversation. They describe different layers of the same thing.
- The ecosystem is the infrastructure, tools and methods that let models be created, connected and trusted: requirements tools, MBSE tools, CAD, simulation, PLM and analysis tools, all reading from and writing to shared data.
- The digital thread is the set of links between those models. It is what turned the impact search in the worked example into a query.
- The digital twin is a virtual model of a specific physical system, kept current with data from the real thing in operation.
Of the three, the thread is the one most organisations are missing. Plenty of teams have good models. Far fewer have them linked. Open interfaces such as the SysML v2 standard API are aimed squarely at that gap.
The five goals, and what each means on Monday
The term went mainstream when the US Department of Defense published its Digital Engineering Strategy in June 2018. It set out five goals. They remain the most useful checklist for any organisation, defence or not.
| Goal (DoD wording, abridged) | What it looks like in practice |
|---|---|
| 1. Formalise the development, integration and use of models | Decisions at reviews are taken from the model, not from a slide someone built from it. |
| 2. Provide an enduring, authoritative source of truth | Everyone can say where the current value of any requirement or parameter lives, and it is the same place. |
| 3. Incorporate technological innovation | New analysis and simulation methods plug into the shared data instead of starting their own copy of it. |
| 4. Establish a supporting infrastructure and environments | Tools, access and connections that let a supplier work in the same data without an export. |
| 5. Transform the culture and workforce | People maintain the model because it is easier than maintaining their own spreadsheet. |
Where to start
Nobody switches a programme to digital engineering in one move. The organisations that get somewhere start with the link that hurts most and extend outwards.
- Pick the most painful hand-off. Usually requirements to verification, or requirements to suppliers: the places where documents are copied most often.
- Make one source authoritative for it. Requirements, owners and verification evidence held once, with history, instead of in a spreadsheet that gets emailed. This is the job of requirements traceability software.
- Link before you model. Connecting the requirements you already have to the designs and tests they govern pays off sooner than building new models from scratch.
- Prove it on one change. Run the next real change the new way, as in the worked example, and measure how long impact assessment took compared with the last one.
- Extend outwards. Add the next discipline only once the first link is trusted.
For the modelling side of the journey, our guide to MBSE adoption covers tools, training and process in more depth.
Why it fails
Goal five is the one that decides the other four. Digital engineering fails in a predictable way: the tools are bought, the model is built, and engineers quietly keep their own spreadsheet because it is faster for the question in front of them. Within months the "authoritative" model is the one nobody trusts.
The fix is not a mandate. It is making the authoritative source the quickest place to get an answer, then treating the change as a transformation programme with owners and training, rather than a software roll-out.
Frequently asked questions
What is digital engineering?
Digital engineering is an integrated approach that uses authoritative digital models and data across a system's entire lifecycle and every engineering discipline. The US DoD defines it as "an integrated digital approach that uses authoritative sources of system data and models as a continuum across disciplines to support life-cycle activities from concept through disposal."
What is the difference between digital engineering and MBSE?
MBSE is a method for doing systems engineering with models, a modelling language and tools. Digital engineering is the broader, organisation-wide approach that connects models across all disciplines and the whole lifecycle. MBSE is a subset of digital engineering.
What is the digital engineering ecosystem?
It is the infrastructure, digital environment, methods and tools that let models be created, connected and trusted across an organisation, including requirements, MBSE, CAD, simulation, PLM and analysis tools working from shared authoritative data.
Is digital engineering only for defence?
No. The US DoD popularised the term with its 2018 strategy and made it policy in DoD Instruction 5000.97 in 2023, but the same approach is used in aerospace, automotive, rail, energy and medical devices: anywhere a product is too complex to manage on documents.
Related guides
- What is MBSE?: the core method
- The digital thread: how the data connects
- Digital twins: the virtual model of the real system
- SysML v2: the standard that makes cross-tool links practical