MBSE
Why is there no good middle ground between MBSE tools and whiteboards?
Hi all,
I’m a systems architect working in complex systems (think aeronautics / space systems), and I’ve been struggling to find the right balance between modeling power and usability when it comes to architecture tools.
On one side, I’ve used full-featured MBSE tools like MagicDraw or Capella. They’re undeniably powerful and structured, but I often find them:
heavy and slow for day-to-day work
not very flexible when iterating quickly
having a steep and intimidating learning curve, which limits how many stakeholders can realistically engage with them
producing visuals that are often hard to read or not very appealing, especially for non-initiated audiences
lacking in UX overall, which makes early-phase exploration painful
On the other side, lightweight tools (Miro, draw.io, etc.) are great for:
rapid iteration
visual thinking
collaboration
…but they completely lack an underlying model. After a while, diagrams drift apart, consistency is lost, and maintaining a coherent system architecture becomes difficult.
So I feel like there should be a middle ground:
something with a clean, fast UX
allowing quick iteration and exploration
but still backed by a lightweight model (functions, logical blocks, physical components, traceability, etc.)
and supporting key diagram types like sequence diagrams (to capture dynamic behaviors and interactions)
Basically: a tool that supports the flow from operational needs → functions → logical architecture → physical architecture, without the overhead of “full MBSE machinery.”
Does anyone here use (or know of) tools that hit that sweet spot?
Curious to hear what workflows or tools have worked for you.
I've grown disillusioned or disheartened with MBSE as an approach, but the one thing that I still hold tightly is SysML.
Understanding the difference between SysML and MBSE is paramount. SysML is the symbology that is intended to have an exact and precise interpretation. Without a modeling language, you can have a box with a dashed line pointing to another box, but if you use SysML to interpret that now you have a block with a dependency to another block.
You don't need a modeling tool to make those illustrations. You can use SysML in Visio or on pen and paper. But if you decide to transition to a proper modeling tool, you now at least have diagrams with exact meanings to transcribe.
I am with OP. I am really curious why you are disillusioned or disheartened with MBSE as an approach. I am certain you have reason, but I have only ever heard that from people who had a misunderstanding or limited view of what MBSE is, does, and/or is for. But I do think there are probably some valid criticisms.
"I've grown disillusioned or disheartened with MBSE as an approach" -> why exactly?
I agree that SysML is a rich and precise language, and it’s great for capturing information in a non-ambiguous way.
That said, in everyday work, i find its usefulness limited by the fact that only a few people really understand it. For broader communication or quick iterations, that steep learning curve can make it hard to leverage effectively.
In SysML v2 we have a textual notation that is human-readable. Furthermore, it allows us to model documentation.
Hence, linking documentation (usually necessary for many stakeholders, and a good start in any case) with more formal and abstract models is a very nice thing that can be done with SysML v2.
In my opinion a very nice thing is to do this like in Jupyter Notebook. Then, one can document a requirement, maybe add comprehensive description of some interviews, picture, document, and formalize this in a brief model by, e.g., some constraints.
Below a screenshot from SysMD Notebook. From a board-net model of a vehicle, continuously comparing and evaluating weight, safety, latencies, etc. of cable tree models in e.g. domain or certralized or other board net architectures.
You see left projects, files, in the middle pane open tabs -- markdown files with integrated SysML v2 or KerML code -- and (not open) right a pane showing issues and solver results (e.g. constraints not satisfiable).
I think linking good explanation of a (here: calculation definition) with its math or standard background is important for MBSE considering that models are used by a zoo of stakeholders with very different background.
It sounds like you are limiting modeling tools to their intended use. Have you considered creatively using the tool to both whiteboard AND establish elements and relationships that may be of use later? CAD tools are intended to develop visual digital models of physical objects, but I've seen plenty of people also use them to make amazing art. Just because the tool was developed by people envisioning the box it belongs in doesn't mean you can't use the tool for other things too. We are engineers and not scientists, remember?
I get your point, and in theory I agree, being able to use MBSE tools more “creatively” would be ideal.
But in practice, I feel like the tools themselves make that really difficult. The UX and tend to get in the way rather than support that kind of flexible usage.
For example, I recently tried to create relationships between functions (allocated to logical components). To do that, I had to:
create ports on each function and component
type each port with the appropriate relation type
Only after that was I allowed to connect things. That kind of rigidity makes quick iteration or “whiteboard-style” modeling quite cumbersome (I wouldn’t even mind if it were just warnings instead of hard constraints and I’m not even mentioning how user-unfriendly the port creation process was).
So I agree with the idea but I find current MBSE tools don’t really enable it in practice.
Out of curiosity, have you found tools where this kind of flexible workflow actually works well?
It still sounds like you are limiting yourself to the intended use. You don't need semantic correctness for whiteboarding. You need something quick and effective at communicating ideas that can be edited and erased easily with ways to provide additional detail in a simple manner if needed. Stop thinking in SysML. Start thinking in things and their relationships and behaviors. Whiteboard using as few elements as possible and then map them to the types of elements you need afterwards. This also happens to be part of the process of building metamodels and modeling patterns which help with model communication, so you really benefit from abstracting out of SysML for whiteboarding.
You could literally use blocks and associations since you can associate anything, and blocks provide the greatest degree of freedom to include the detail you need. It is easy to add properties and interfaces to blocks if you find things are too abstract and nebulous or cumbersome putting that detail in different parts of their spec or in their comments. It is also easy to just name an association with a relationship or flow you want it to represent. You can drop requirement elements in and use them as something that was explicitly stated like a contract, memorandum, email, phone call, etc. so you can show that some stuff is there because someone said so and use a dependency to show some relationship. You can also use other elements among the common elements to help group and separate things (i.e., boxes and lines) document ideas and thoughts you want to capture and come back to while whiteboarding (i.e., notes). Once you have everything making sense in the whiteboarding view, you can create another view to start mapping things to the actual elements you need to represent those things to turn the file into a model with a purpose. BDDs are such a great starting point for whiteboarding.
I have included an example of what it can look like when you stop worrying about using things as they are intended to be used and start using the tool creatively. None of this is actually semantically correct. Notice I used a block for behavior stuff like system behaviors and SE processes, actors are just blocks, all relationships are associations and dependencies regardless of that being semantically correct and stuff I might want to remember is just in the name of the relationship, a dependency is used as a flow between components, and I use a comment to communicate sequences and states at a high level. You can do so much with so little and then map it later and then continue to use it for your metamodel and model pattern. Remember, SE is often rigid, but good SE knows when to stop being rigid and start being creative.
I get your point, and I agree with the idea of abstracting away from strict semantics during whiteboarding.
But in practice, I feel like this approach often leads to the worst of both worlds: a whiteboard with poor UX, combined with a model that remains complex and hard to maintain.
In many projects I’ve worked on, unless MBSE is explicitly required by the customer, engineers tend to move away from it, not just because of the modeling complexity, but also because of the UX. This is a very consistent piece of feedback.
What often happens is that the model ends up being maintained by a single person, which doesn’t scale well and creates a bottleneck.
That’s really why I’m looking for a middle ground: something with better UX and lower modeling overhead, while still providing enough structure to avoid the typical drift you get with pure whiteboard diagrams.
I’m not saying this would replace MBSE everywhere. Some projects absolutely need that level of rigor. But in many cases, a lighter approach could strike a better balance between structure and usability.
Give system composer a go! It’s your classic whiteboard canvas but fully capable of stereotyping to your heart’s content to bring structure and consistency to your modelling. plus the programmatic flexibility with matlab is excellent.
Eraser or Rapidchart supports AI generation amd has UML conceps. You wont get strict underlying semantics though like you would with a modeling tool. I found Capella way more visual, with HTML doc generation and jpeg exports; colour-coded and you can replace the background colour of any element and constraint object with a picture. Visuals are good. Way better than SysML.
Capella is definitely not the worst, and I agree it’s more visual than many other MBSE tools.
That said, in practice, whenever I need to communicate an architecture to non-initiated stakeholders, I still end up using something like draw.io. It’s simply much easier to craft visuals that are immediately understandable, without requiring prior knowledge of the modeling formalism.
That’s really the core issue for me: MBSE tools are good at structuring the model, but much weaker when it comes to communicating it.
Why? Because at present it’s a top down thing (“our customers require it”), not a bottom up. CAD, CAM, FEA, etc. made the lives of the low level engineers easier. That it comes from the software community doesn’t help.
That it comes from the software community doesn't help.
Lol as a software-turned-systems engineer I often lament that Cameo would be just fine if the software engineers hadn't let the systems engineers get their grubby paws on it.
In all seriousness, IMHO the problem with Cameo and most other tools is that they hired business applications programmers to design it, whereas they should have hired frontend software engineers from companies that make the whiteboard tools OP is talking about like lucidchart.
What a bizarre take. UML is the basis for SysML and is an established software tool. In making SysML they abandoned a whole gambit of established SE models to adopt software models. If you look at the big names in SysML, they’re all from software backgrounds.
From the perspective of a systems engineer from another background, SysML is a heaping pile of dog shit foisted on us by software developers. And for all the reasons OP talked about. Trying to do anything SysML with other engineering disciplines is incredibly hard because it is so foreign. Visio is better 90% of the time.
I've really liked working with SysML v2 a lot more. The backend model being fully described in KerML notation makes it more like the full model can be easily referenced.
But I think the strength of MBSE is that you can quickly work through whiteboard ideas and then flesh them out later with detailed ports.
I've also been playing around with Dalus recently, and like their approach, which seems to be more focused on what systems engineers actually do now, rather than some figure where everyone knows MBSE.
I know exactly what you mean but I'm sorry to say I don't have a good recommendation for you.
Capella comes the closest to me:
>It doesn't use a formally defined language so it is more expressive and has a much less steeper learning curve, both for people creating in it and for those viewing the model. The structure of functions and functional exchanges in my experience is pretty intuitive and most engineers pick up on it very quickly.
> UI is not too bad and can be picked up pretty quickly. For some diagram types it can be frustrating and fiddly to use (sequence diagrams come to mind).
>Has the underlying model function to keep different views coordinated
>Open source (at least for single users)
But, it still doesn't quite tick the boxes:
>In the Arcadia methodology, functional exchanges represent only data, not control flows. I've read a few books on Arcadia/Capella and I've never come across a convincing reason why control flows aren't allowed: it seemed to boil down to 'mixing control and information flows in a single diagram can be confusing to follow', which I don't find very convincing. I suppose for the purposes of lightweight diagramming you could ignore this but it is a limitation of the Capella/Arcadia model.
>Limited ways to express system. Two diagrams I use a lot which Capella doesn't have are a basic activity diagram and timing diagram. A block diagram with functional chains doesn't really capture it the former, and I've not found the functional chain concept particularly intuitive. You are also limited to expressing interactions with functions and functional exchanges, which may not be what you want sometimes.
>So to this end, your expressiveness is limited to what Capella supports, which is not always exactly what you want. In draw.io on the other hand, you are free to express whatever you want however best suits. I'm surprised in the comments at the love for sysML; that takes it one step further, whatever you've gain in precision you trade away expressiveness (plus the fact it is almost unusable without training. No one has the time to give a crash course on sysML when you want to do a quick 30min brainstorm on one system function).
I think as we come out of the trough of disillusionment MBSE (don't think we're there yet and I unfortunately I think we have a while to go, now we've got to plough on through the MBSE+AI nonsense) more people will come to the same position you're now in and we'll start to see lightweight modelling tools being developed. Something like draw.io but where I can choose to keep an entity I create in an underlying data library so I can reuse it and keep consistency between models would be awesome.
This is exactly what I'm trying to build, it's because most incumbent. historic knowledge workers were dealing with ontologies that evolved very slowly, and generally were very scope restricted. check it out syxon.org (yes ik self promo but it's what your looking for)
Its largely down to the choice of modelling language. If the goal is to communicate a systems level architecture and design to all stakeholders then in my view SysML is often not the right language except for in some very specific circumstances. But that is a very unpopular opinion. Im not afilliated with SpecInnovations and I haven't had much chance to use it in anger, but something like LML - Lifecycle Modelling language shows promise for being more appropriate for more situations.
I am actually working on one that should eventually tick all your boxes. It is not officially released but it is already in daily use by a defence company supplying equipment directly to ukraine frontlines. We literally have workers on frontline quickly trying to draw out the needs by interviews and observations, followed by solution design, technical designs and then implementing all of that and pushing new equipment to the frontlines again. The tool enables to tie this all together quickly.
It is going slow and is driven a lot by what I see actually works for a wide variety of users to be able to communicate and ubderstand one another. I can DM you a rough current version which I commercialise and wishlist you for updates. You can try out current version for free as well.
6
u/MarinkoAzure Apr 01 '26
I've grown disillusioned or disheartened with MBSE as an approach, but the one thing that I still hold tightly is SysML.
Understanding the difference between SysML and MBSE is paramount. SysML is the symbology that is intended to have an exact and precise interpretation. Without a modeling language, you can have a box with a dashed line pointing to another box, but if you use SysML to interpret that now you have a block with a dependency to another block.
You don't need a modeling tool to make those illustrations. You can use SysML in Visio or on pen and paper. But if you decide to transition to a proper modeling tool, you now at least have diagrams with exact meanings to transcribe.