{"id":235,"date":"2026-10-15T15:03:12","date_gmt":"2026-10-15T19:03:12","guid":{"rendered":"https:\/\/blogs.mathworks.com\/digitaleng\/?p=235"},"modified":"2026-10-15T15:03:12","modified_gmt":"2026-10-15T19:03:12","slug":"part-2-how-digital-engineering-scales-where-ad-hoc-workflows-fail","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/digitaleng\/2026\/10\/15\/part-2-how-digital-engineering-scales-where-ad-hoc-workflows-fail\/","title":{"rendered":"Part 2: How Digital Engineering Scales: Where Ad Hoc Workflows Fail"},"content":{"rendered":"
\n

When we launched Digital Engineering De-coded, our goal was simple: move beyond buzzwords and share practical patterns that help engineering teams solve real problems.<\/p>\n

This four-part series follows VIPR-GS researchers Tanmay Samak and Chinmay Samak as they reflect on their work developing and validating autonomous ground vehicle systems<\/a> in collaboration with the U.S. Army DEVCOM Ground Vehicle Systems Center. Their experience illustrates a challenge familiar to many engineering teams: individual digital artifacts may exist, but connecting them into a coherent engineering workflow is far more difficult.<\/p>\n

Across the series, we explore how their approach evolved from ad hoc simulation and analysis toward a more systematic workflow built around systems thinking, traceability, executable architecture, and evidence-based decision making.<\/p>\n

In Part 1: Why Digital Engineering Matters: Real Examples, Real ROI<\/a>, we explored why digital engineering is often misunderstood when teams focus on individual concepts rather than the connections between them.<\/p>\n

They will present their work at MathWorks EXPO Online 2026<\/a> on Wednesday, November 4.<\/p>\n<\/div>\n

Most teams do not start with a perfectly connected engineering workflow. They start with the immediate problem in front of them.<\/p>\n

Build a model. Run simulations. Collect data. Analyze results. Make changes. Try again.<\/p>\n

That approach is natural, and it can work well during early exploration. It gives engineers room to move quickly, test ideas, and learn. But it starts to break down when the number of scenarios, variables, design choices, system variants, and test results grows beyond what a team can track manually.<\/p>\n

That was a key lesson from the VIPR-GS team’s autonomous ground vehicle project. Their early approach centered on digital twins and simulation. They could run tests and collect KPIs, but the harder problem was connecting outcomes back to causes. As Tanmay described it, the bottleneck was not spinning up simulations or collecting data. The bottleneck was associating results with what caused them.<\/p>\n

Many digital transformation efforts assume the main challenge is generating more data, running more tests, or increasing automation. Those things help, but they do not solve the core engineering question: what changed, why did it matter, and what should we do next?<\/p>\n

For the VIPR-GS team, that question became harder as the workflow scaled. Different people were working on simulation orchestration, digital twins, and post-processing analysis. The team had version control and workflow automation, but the validation results were not transparently connected back to the perception, planning, and control subsystems that produced them.<\/p>\n

\"\"<\/p>\n

In this conversation, Tanmay and Chinmay describe how that challenge became the catalyst for a more systematic approach to digital engineering.<\/p>\n

Interview<\/h3>\n

\"\" Tamnay Samak\u00a0 \u00a0 \"\"\u00a0 Chinmay Samak<\/strong><\/p>\n

 <\/p>\n

Q: What did your early approach look like before you moved to a more systematic workflow?<\/strong><\/p>\n

Chinmay Samak:<\/strong> We started with an ad hoc approach. We did not bring in MBSE or model-based design at that point. We used digital twins, developed the autonomy algorithm, and put it through different test cases. Some parts were manual and some were automated.<\/p>\n

Q: At what point did that approach stop working?<\/strong><\/p>\n

Chinmay Samak:<\/strong> The scale of complexity becomes intractable. You cannot keep track of what change you made, what change you are supposed to make, or what test case should be executed next. For prototyping or proof-of-concept work, that may be fine. But as the system grows, you need a systematic way to track design choices and validation.<\/span><\/span><\/p>\n

Q: What was the real bottleneck? Was it running simulations?<\/strong><\/p>\n

Tanmay Samak:<\/strong> The problem was not spinning up simulations or collecting data. It was sitting down to analyze it and tying it back to what we would now call requirements. Even for a smaller problem, manually associating pass and fail regions with causes was not going to scale to an off-road autonomous vehicle.<\/p>\n

Q: How did the lack of traceability affect collaboration?<\/span><\/b>\u00a0<\/span><\/p>\n

Chinmay Samak:<\/span><\/b> It was difficult because different people were working on different parts: simulation orchestration, digital twins, and analysis. We were also distributed across campuses. Communicating next steps took a lot of time. Once the workflow became more centralized, everyone had more visibility into what was happening.<\/span><\/p>\n

Q: If you had to summarize the pre-digital-thread state, what did it look like?<\/strong><\/p>\n

Tanmay Samak:<\/strong> Earlier, there was no picture. We were directly attacking the problem. We had the digital twin, we were spinning up simulations, and we were trying to figure things out as the data came in. When we moved to digital engineering, the early steps felt like inertia, but once validation results were tied back to requirements, we realized there was a system-level picture we had been missing.<\/p>\n

Key takeaways<\/span><\/b>\u00a0<\/span><\/p>\n

    \n
  • As complexity grows, teams need a shared system view and a common way to understand what changed, why it changed, and what to do next. <\/span>\u00a0<\/span><\/li>\n<\/ul>\n
      \n
    • Ad hoc workflows are useful for early exploration, but they break down when system complexity exceeds what teams can track manually.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
        \n
      • The bottleneck often shifts from generating data to understanding what changed, why it changed, and what caused the outcome.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
          \n
        • Traceability provides the connection between validation results, requirements, architecture, and design decisions.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
            \n
          • Digital engineering often begins when teams need a more systematic way to connect results back to causes across the engineering workflow<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

            How much of your team’s decision-making is based on traceable evidence, and how much relies on expert knowledge, intuition, or manual investigation?<\/span><\/b>\u00a0<\/span><\/p>\n

            Next in the series:<\/span><\/b> If ad hoc workflows break at scale, what replaces them? The VIPR-GS team’s answer centered on executable architecture and evidence-based traceability.<\/span>\u00a0<\/span><\/p>\n

             <\/p>\n

             <\/p>\n

            Bonus material:<\/strong>\u00a0This video includes the latest version of the work discussed in this blog series that integrates agentic tools into the digital engineering workflow.<\/em><\/p>\n