Every engineering organization is trying to move faster, make better decisions earlier, and align teams that come from very different engineering cultures. And in a world where software now defines, and increasingly delivers, most of a product’s differentiated value, the tension between systems engineering and software engineering has never been more visible and damaging.

This raises a question I hear across industries: Is the V-diagram still relevant in a world of software-defined systems?

The V-Diagram: A Useful Structure, Often Misused as a Process

The V-diagram was never meant to be a timeline. It was created to clarify responsibilities and relationships, not to dictate a sequence or prescribe a process.

Yet many teams interpret it as a left-to-right development flow (as shown in the figure below), which leads directly to its association with the waterfall model. And that misconception is costly. Waterfall requires complete requirements upfront, limits iteration, and delays meaningful testing until late in the cycle. Those dynamics slow innovation, increase risk, and make it very hard to respond to new information.

When systems teams promote the V-diagram as the governing framework, and software teams misperceive it as waterfall, which they abandoned long ago in favor of Agile approaches, the conversation quickly becomes polarized. Systems engineers and software engineers start talking past each other, reinforcing silos instead of solving problems together.

Simulation and Virtualization: Different Perspectives, Same Goal

Much of the disconnect between systems and software engineers shows up in terminology. “Simulation” and “virtualization” sound like different practices, but they both describe creating a digital representation of the system to reduce dependence on physical hardware.

The difference is in how each group uses these representations.

• Systems engineers simulate to understand behavior, explore tradeoffs, and shape requirements before hardware exists.
• Software engineers virtualize the processor, the system, and the relevant operating scenarios so they can verify software much earlier, without waiting for physical parts.

Both groups are trying to shift understanding and verification earlier, when change is cheaper.

A very effective collaboration point is the continuous integration (CI) pipeline. Software engineers rarely want to simulate system models directly, and they do not need to. When those models are embedded into automated CI tasks, software teams can test their code against realistic system behavior and scenarios without ever launching the models themselves. This is more than “shift-left testing.” It is a practical way to align engineering disciplines through automation.

Model-Based Design: A Bridge Across Mindsets

Model-Based Design fits naturally into systems engineering,

But the story does not stop there. It also supports Agile and DevOps practices. From a software perspective, executable models enable automatic code generation, continuous integration, continuous verification, and rapid iteration.

The important point is that a single model provides value to both systems and software teams, even if each group interacts with it differently. In many organizations, that shared model becomes the primary mechanism for alignment.

So, Is the V-Diagram Still Relevant?

Yes, when it is used as intended. The V-diagram remains a helpful map for thinking about engineering responsibilities and relationships. But it is not a process diagram and treating it as one can create more problems than it solves.

The organizations that will succeed in digital engineering are the ones that align systems engineering and software engineering mindsets. That alignment depends on shared artifacts, shared automation, and a willingness to view digital engineering as a collaborative effort, not a sequence of handoffs.

How does your organization currently visualize its digital engineering workflow, and do you believe this approach truly bridges the gap between systems and software engineering mindsets?