Model-Based Systems Engineering (MBSE) has a reputation for being difficult to adopt. The language can feel complex, the tools can appear intimidating, and the return on investment is not always immediate.
But for two experienced MBSE educators, the answer is not to abandon the approach. It is to make it simpler, more practical and better connected to the way engineers actually work.
Hamza Bassam, trainer, consultant and coach at oose eG, and Doug Rosenberg, Author of Pain-free MBSE, both spend their time helping engineers learn how to model systems with SysML and CATIA Magic. Their perspectives come from training and consulting rather than from working as OEM practitioners. Yet their experiences point in a similar direction: MBSE does not have to mean more work.
For both educators, the combination of SysML v2, CATIA Magic and AI is opening new possibilities for making MBSE easier to learn, easier to apply and, ultimately, more useful.
The problem is not necessarily MBSE: it is how we approach it
Doug Rosenberg is deliberately blunt about the reputation MBSE has acquired.
He says that many people see SysML modeling as “too slow, too expensive, too painful.” But, in his view, the problem is not fundamentally SysML or CATIA Magic. It is the way people are taught to use them.
Training can sometimes focus on every feature, every diagram and every possible modeling option. That may make sense when preparing for a certification, but a real project has schedules, budgets and practical objectives.
Doug’s answer is what he calls the value-to-pain ratio: for each modeling activity, ask how much value it provides and how much pain it creates. If the ratio is unfavorable, question whether the activity is really necessary.
MBSE doesn’t have to be more work. If you do it right it should actually be less work, it should make you more efficient, not less efficient.
His philosophy is therefore not about doing more modeling. It is about doing the modeling that actually helps.
MBSE adoption is also a cultural change
Hamza Bassam reaches the problem from another direction.
For him, one of the biggest obstacles to MBSE is not the technology. It is the organizational and cultural change involved in adopting a different way of developing systems.
Getting a tool and running a training course does not automatically mean that an organization has embraced MBSE. Teams need to change the way they develop systems and understand how the modeling language and tools support that change.
There is also a business challenge: the benefits may not appear immediately. Hamza explains that the return can become more visible later, when teams can reuse models, analyze different variants and solutions, or apply product-line engineering.
That makes the initial investment harder to justify, particularly when the value is expected beyond the first program.
The technical barriers, however, are becoming more manageable. Hamza sees AI as a way to reduce some of the complexity of both the tools and the language.
And that is where SysML v2 becomes particularly interesting.
SysML v2: a language designed for a new generation of engineering
For Hamza, SysML v2 represents more than an incremental update.
He describes SysML v1, in use since 2007, as the generation the industry learned on. Twenty years of MBSE practice with SysML V1 showed what worked and what were the key needed enhancements for MBSE adoption, and those lessons were written directly into the requirements for SysML v2 new standard (started by OMG in 2017). SysML v2, formally adopted by OMG in 2025, is no longer a UML profile. It is built on a new kernel language, “KerML”, with formal semantics that cover both discrete and continuous behavior and the capability build specialized domains extensions.
With textual and graphical notations built in by design, as well as a standardized API, Hamza sees in SysML V2 a key enabler to approaches from software engineering, including agile development, while also making SysML particularly interesting for Generative AI.
For engineers, the textual notation can initially be a challenge.
Systems engineers often come from mechanical or other non-software backgrounds. For someone who has not written code for years, seeing a textual modeling language can trigger an immediate reaction:
I’ve never written code.
But Hamza sees different reactions in training. Software-oriented engineers often welcome the notation immediately. Some engineers from mechanical backgrounds resist at first. Others, particularly those already comfortable with graphical modeling, gradually become comfortable with the textual approach.
That learning curve may matter less as engineers begin to see what textual SysML v2 makes possible.
CATIA Magic: making the language accessible
Both educators teach CATIA Magic, but their interviews highlight different reasons why it matters.
For Hamza, one important strength is the ability to work with both graphical and textual SysML v2 notation. The graphical representation gives beginners an accessible entry point, while the textual notation exposes more of what is happening in the language, and provides an interesting foundation for AI assistance.
He also highlights capabilities such as traceability and features carried over from SysML v1, but the capability he emphasizes most strongly is simulation.
A model is useful only if it represents the system and behaves as intended. Simulation provides feedback, allowing engineers to identify errors earlier in the design process.
For Hamza, this feedback loop becomes even more interesting when AI is involved: an AI system can produce a response, but engineers still need a way to check whether they are heading in the right direction. Connecting AI with simulation creates the possibility of iterative loops between generation and validation.
Doug approaches CATIA Magic from a more pragmatic perspective.
He describes it as the tool most of his industry clients use for their system models and therefore the environment he teaches. His focus is not on using every available feature, but on understanding how to use the tool intelligently.
One example he gives is the recurring problem of item flow violations on SysML internal block diagrams. CATIA Magic’s validation rules identify these issues, but Doug says there is a way to avoid the problem that many users do not know about.
For him, this illustrates a broader point: the tool implements the language, but users can work with it intelligently or less intelligently. The objective is to find the practices that help teams avoid unnecessary pain.
AI changes the economics of modeling
If there is one area where the two interviews converge particularly strongly, it is AI.
Hamza sees AI reducing some of the complexity associated with tools and modeling languages. The textual nature of SysML v2 is particularly relevant because it gives AI something it can work with directly.
Doug goes one step further with a concrete example.
Because SysML v2 has a code representation, large language models can easily generate code. That code can then become a graphical representation, leveraging CATIA Magic built-in synchronized textual and graphical notations.
Doug describes generating approximately 30 to 40 pages of a SysML model for a lunar lander using three prompts. What previously required manually drawing diagrams can now be accelerated by generating the underlying model representation with AI.
The point is not that AI eliminates engineering work.
Doug explicitly warns that AI-generated output must be checked. You cannot simply trust the result.
Instead, AI changes where engineers spend their time: rather than manually creating every element of a model, they can increasingly focus on defining what they want, reviewing what has been generated and refining the result.
For educators, this creates both a significant opportunity and a new responsibility. If AI can automatically generate models, to what extent should trust and decision-making be delegated to AI, and what responsibilities remain uniquely human? More fundamentally, what does the role of the systems engineer become in this new paradigm?
From teaching features to teaching judgment
Both interviews ultimately point toward a change in what MBSE education should focus on.
Doug argues that traditional training can leave engineers with too many options. SysML provides multiple ways to achieve things, and courses can teach all of them without necessarily explaining which approach makes the most sense for a real project.
His experience with UML shaped his philosophy: he spent decades simplifying UML’s 14 diagram types down to five, and he now applies a similar mindset to SysML.
The goal is not to know everything.
It is to know enough to make good decisions.
Hamza’s perspective is complementary. For him, adopting MBSE means changing the culture around engineering. The technology supports that transformation, but the humans using it remain central.
This also explains why both educators emphasize experimentation.
Hamza’s advice is to stop waiting for the industry to become completely mature before trying new approaches. Engineers should experiment, see what works and what does not, learn and develop from there.
Doug expresses a similar philosophy through one of his central principles:
The perfect is the enemy of the good.
His advice is to get something working, get it working quickly, and then learn from it rather than spending disproportionate effort pursuing perfection.
Making MBSE less painful starts with making it more practical
The common message from these two educators is surprisingly simple.
MBSE does not have to be an exercise in maximizing complexity.
For Doug, that means identifying and eliminating high-pain, low-value practices. His rule is memorable: 10% of the practices cause 90% of the pain.
For Hamza, it means recognizing that MBSE is a cultural transformation, not simply the deployment of a new tool. Teams need to understand why they are modeling, how they will reuse what they create, and how technologies such as AI and simulation can support the engineering process.
SysML v2 brings together several of the capabilities that make this evolution possible: textual and graphical representations, a standardized API and a structure that is particularly suited to AI-assisted workflows.
CATIA Magic provides the environment in which these models can be created and used, while simulation and validation can provide feedback on whether the models actually behave as intended.
And AI can increasingly help with the mechanics of creating and manipulating those models.
But neither educator presents technology as a magic solution.
The real opportunity is to combine the technology with better practices and better judgment.
The educators’ message: don’t wait for perfect MBSE
For Hamza, the future of MBSE is tied to experimentation, openness to new languages and tools, and a willingness to move beyond established mental models.
For Doug, it is about efficiency: modeling should help engineers do their jobs better, not create unnecessary work.
Their approaches are different, but the destination is similar.
MBSE should help engineers think about systems, communicate about them, validate their ideas and make better decisions, without creating unnecessary modeling work along the way.
As AI and SysML v2 continue to change what is possible, the role of educators may therefore become even more important: not simply teaching engineers how to use every feature, but helping them understand which features, practices and workflows are actually worth using.
The objective is not more modeling.
It is better modeling and less pain along the way.
Conclusion
For Hamza Bassam and Doug Rosenberg, making MBSE more effective does not mean adding more complexity. It means adopting simpler practices, using the capabilities of SysML v2 and CATIA Magic intelligently, and taking advantage of AI to reduce unnecessary manual work.
Their message is ultimately about experimentation and efficiency: MBSE should help engineers work better, not harder.
To go deeper, see Doug Rosenberg’s book Pain-Free MBSE, and his training on this approach.
👉Click here to download the free CATIA Magic Community Edition SysML V2, 100% free for learning & teaching!
👉Discover CATIA Magic & GenAI with Virtual Companion here
👉 Watch the interview with Hamza Bassam (Oose eG) here
👉Watch the interview with Doug Rosenberg (Author of Pain-free MBSE) here
FAQ
Both argue that MBSE does not need to create unnecessary complexity or work. Hamza emphasizes cultural change, practical adoption and the potential of SysML v2 and AI. Doug focuses on eliminating high-pain, low-value modeling practices and making teams more efficient.
Hamza highlights its textual notation and standardized API, while Doug points specifically to its code representation. This allows AI to generate SysML code that can then be transformed into diagrams in CATIA Magic.
Hamza highlights the combination of graphical and textual notation, as well as simulation and other modeling capabilities. Doug emphasizes the importance of using CATIA Magic intelligently and avoiding practices that create unnecessary pain.
No. Doug explicitly stresses that AI-generated models must be checked. The interviews present AI as a way to accelerate modeling and reduce manual effort, while engineers remain responsible for reviewing and validating the results.
Experiment. Hamza encourages engineers not to wait for the industry to mature before trying new approaches. Doug similarly recommends getting something working quickly rather than pursuing perfection from the beginning.
Guillaume Belloncle is the CATIA MBSE Strategic Engagements Industry Process Director, within CATIA Industry Process Success organization