It's not MBSE when you use draw.io or Visio

I have moderated quite a few modeling workshops over the last years, and it often was the first time all stakeholders had the chance to reason about a system collaboratively. Consequently, this was seen as very helpful. And it probably would have been the same if no formal language had been used and the work product had not been a formal model.

A picture is worth more than a thousand words. Fair enough.

But to think of a system model only as a means of communication is too short-sighted. If you limit yourself to drawing pictures, you can’t take advantage of a truly model-based approach. You can’t easily validate the information you capture. You can’t derive other useful representations from it: no FMEA framework based on a system’s functional and technical decomposition, no source code or test cases from interfaces and behavioral specifications.

I would even go so far as to say that you can only use generative AI meaningfully if your systems engineering is based on (formal) models. Given the inherent fuzziness this new technology brings, MBSE is the safeguard to secure generated content.

It’s fine if you just want to draw, but I’m sure it won’t get you across the finish line. And please, don’t call it MBSE. It isn’t.

What actually makes a model a model?

Draw.io and Visio produce geometry. Boxes, arrows, labels — visual artifacts that carry meaning only in the reader’s head. There is no machine-readable semantics behind them. No defined concept of “component” or “interface” or “function”. No rules that constrain what can be connected to what.

A formal model is different. Behind it lies a metamodel: a precisely defined vocabulary of concepts, relationships and constraints that governs what can be expressed and how. A component has a type. An interface has a direction. A connection between two incompatible ports is not just ugly — it is structurally invalid. The tool knows this and tells you immediately.

This is the foundational difference. It is not about graphical notation. SysML and Capella produce diagrams that look similar to what you might draw in Visio. The difference is what lives underneath: semantics that a machine can reason about.

Three things you can only do with a real model

Once your model carries semantics, three things become possible that drawings fundamentally cannot offer.

Consistency validation. A large part of model checking runs live, as you model. Structural and semantic rules are evaluated continuously. Errors appear in the model — not in a hardware prototype six months later. This is a classic shift-left effect, and it pays off exactly where it matters: complex systems where errors are expensive to find downstream.

Derived representations. The system FMEA is a canonical example. Deriving it manually from a Word document is painstaking and error-prone. From a model with a complete functional and technical decomposition and full requirements traceability, it can be derived semi-automatically — and it stays consistent with the architecture as the model evolves. The safety analysis is no longer a separately maintained document that drifts from the design. It is a view of the model. The same logic applies to interface specifications, test case frameworks, and architecture documentation.

Code generation. From a formal behavioral model — a statechart, for instance — you can generate production-ready C, C++ or Java code deterministically. The same model, the same generator, the same output. This reproducibility is not just a convenience: in regulated development under ISO 26262, DO-178C or IEC 61508, it is the basis for the evidence chain. You cannot get that from a drawing.

Formal models as the foundation for meaningful AI

The AI argument deserves more than a single paragraph.

Generative AI is powerful, but it is statistical. The same prompt generates different outputs. There is no guarantee of structural conformity, no traceability, no reproducibility. These are not incidental weaknesses — they are structural properties of how large language models work.

A formal model changes what AI can do. When an AI operates inside a model space — where concepts, relationships and validity constraints are precisely defined — its suggestions are automatically constrained to valid constructs. Entire classes of errors are structurally excluded before any human reviews the output. The model is not just documentation for the AI to read; it is a closed world that limits what the AI can propose.

AI-assisted modeling: LLMs generate an initial structural or behavioral model from natural-language requirements. Engineers validate and refine — the model is the stable artefact, not the prompt.

Concretely: AI can transfer requirements text into initial model drafts, suggest consistency improvements, or generate test cases from behavioral specifications. But these outputs remain within the semantic boundaries of the model. The deterministic generation step — model to code — stays fully reproducible and auditable. AI accelerates model building; the model remains the single source of truth; code generation remains deterministic. None of these three levels replaces the other.

This is why MBSE is the safeguard for AI-generated content. Not as a metaphor. As a structural argument.

When a drawing actually is enough

I want to be honest about this. If you are developing an isolated control unit for an existing machine, with a small team, stable requirements and no variant management, the overhead of a formal model likely exceeds the benefit. Document-based coordination is simply faster.

MBSE delivers its return when the development task is genuinely complex: when multiple disciplines are involved, requirements change dynamically, impact analyses need to cross subsystem boundaries, or safety evidence must be produced systematically. That is when the shift-left effect of formal validation, the consistency of derived representations, and the determinism of code generation translate into real savings.

If neither of those conditions applies to your project, don’t force it. But don’t call a Visio-diagram approach MBSE either — because it creates a false impression of the method’s actual capabilities and sets expectations it structurally cannot meet.

So what makes it MBSE?

A model that a machine can reason about. A defined vocabulary with semantic constraints. The ability to validate, derive and generate from it. That is the foundation.

The workshops, the visualizations, the collaborative reasoning — these are valuable. But they are valuable regardless of whether a formal language is used. Conflating the benefit of structured conversation with the benefit of formal modeling is the mistake. One gives you alignment; the other gives you a lever to manage complexity, derive safety evidence, and integrate AI reliably.

Draw if you want to communicate. Model if you want to engineer.

Introducing MBSE at itemis — from tool evaluation to methodology and rollout: Systems Engineering →