Digital engineering is often introduced as a tooling conversation.

Which platform should we use? Which repository? Which modeling language? Which simulation environment? Which connector? Which standard?

But starting with the tools puts the emphasis in the wrong place. The VIPR-GS team emphasized that digital engineering starts with how you engineer the system. Tools implement that approach.

For teams beginning their own digital engineering journey, a useful first step is to find where the existing workflow breaks down:

• Where do teams struggle to explain failures?
• Where are requirements disconnected from validation evidence?
• Where are architecture, design, and test artifacts drifting apart?
• Where are decisions being made from intuition because the evidence is hard to trace?

The VIPR-GS team’s experience also makes clear that digital engineering adoption includes growing pains. Early structure can feel like overhead. Requirements engineering, architecture definition, and traceability can feel slower than directly attacking the problem. But the team found that the early inertia created momentum later, when validation results could be traced back to requirements and design choices.

That may be the most practical lesson from the series: digital engineering does not remove engineering complexity. It gives teams a way to manage it.

Interview

Tanmay Samak      Chinmay Samak

Q: What advice would you give to teams starting their digital engineering journey today?

Tanmay Samak: Do not fixate on tools. Digital engineering is about the way you think about engineering. The systematic nature of the approach brings clarity as the system grows.

Q: What should teams expect early on?

Tanmay Samak: Expect inertia at the start. You may feel like you are spending time on structure, but that effort becomes momentum later when you can trace validation evidence back to requirements.

Q: How should teams explain digital engineering to people who are new to it?

Chinmay Samak: Explain it in the context of their domain. Give intuitive examples from problems they already understand. If you start with jargon, people get lost. If you start with a real problem and show how digital engineering fits, the concepts make sense.

Q: What misconceptions would you correct early on?

Tanmay Samak: One common misconception is mixing up model-based systems engineering and model-based design. People use the terms interchangeably, but the workflows are not interchangeable. They play different roles.

Q: What habit matters most?

Chinmay Samak: The habit of thinking from a systems lens. Terminology can be corrected later. The habit of connecting pieces and maintaining traceability is what enables digital engineering to deliver value.

Key takeaways 

• Start with the engineering problem, not the terminology. Digital engineering is most effective when it is grounded in real workflow challenges.
• Look for the places where teams cannot explain outcomes, trace decisions, or understand change. Those gaps often reveal the best starting point for improvement.
• Tools matter, but they should support the workflow rather than define it. The goal is to improve how teams engineer systems, not simply deploy new technology.
• The initial structure may feel slow, but it creates momentum as complexity grows. Requirements, architecture, and traceability become more valuable as systems scale.
• The most important habit is systems thinking: connecting requirements, architecture, models, validation results, and decisions into a coherent engineering workflow.

Image of AutoDRIVE Digital Twin Ecosystem: Samak, Tanmay, et al. “AutoDRIVE: A Comprehensive, Flexible and Integrated Digital Twin Ecosystem for Autonomous Driving Research Education.” Robotics, vol. 12, no. 3, May 2023, p. 77, https://doi.org/10.3390/robotics12030077.

Closing thought for the series

This four-part series started with a simple question: what does digital engineering look like when a team has to make it work?

The VIPR-GS/GVSC example shows that digital engineering is not a slogan, a single tool, or a collection of disconnected artifacts. It is a practical approach for managing complexity. It helps teams move from isolated simulations and manual interpretation toward connected evidence, clearer decisions, and a shared system view.

That shift does not happen all at once. It starts when a team recognizes that generating data is not enough. The real value comes when engineering information is connected well enough to explain what happened, why it happened, and what to do next.

If you were starting a new program tomorrow:

Which part of your engineering workflow would break first as complexity doubled?

Would it be requirements management? Architecture? Verification? Cross-team communication?

Understanding the first point of failure often provides the clearest starting point for a digital engineering transformation.

Bonus material: This video includes the latest version of the work discussed in this blog series that integrates agentic tools into the digital engineering workflow.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. OPSEC11080.</