4 Criticisms of SysML 2: Please use with caution
Michael Pierce from TSP has written an essay with his colleague Bruce Cameron in which he criticizes SysML. On the one hand, it is worth reading for organizations that are considering the strategic use of SysML. Because many of the points are quite valid. On the other hand, I don't find all the criticisms justified, at least not without qualifying them further. Nevertheless, this criticism helps us to make informed decisions about SysML and MBSE.
The sheep in wolf's clothing
Bruce Cameron is a partner at TSP (Technology Strategy Partners), a small but influential consulting firm. What qualifies him even more, however, is his role as Director of the System Architecture Group at MIT, my alma mater. His colleague Michael Pierce had worked at SpaceX for several years in the past. About the innovative approaches in systems engineering at SpaceX I also report here regularly.
The seven-page paper was published by the authors on LinkedIn and is a quick read. The title "A sheep in wolf's clothing" suggests that SysML is trying to be more than it is.
The criticism consists of four specific points, which I will discuss further in a moment. Much of it is justified, but unfortunately the paper also contains a lot of "click-bait" and is an exaggeration. It starts with the title: We have a hype. It is part of the definition of hype that expectations are exaggerated.
SysML was seen as a "Rosetta Stone" to resolve the organizational tensions caused by complexity. It now turns out that SysML is not the solution.
Michael Pierce and Bruce Cameron
Criticism 1: The learning curve is too steep
SysML is undoubtedly a complex language. But that is why SysML is also suitable for so many different domains. However, the authors see this as the real reason for their criticism of SysML. I found the following image from the paper helpful:
A "perfect" modeling language would correspond to the "Good" scenario in the picture. The authors do not say exactly where they see SysML, but they imply the "Less Good" scenario. Compared to the two other alternatives, this is not bad at all. With appropriate techniques (restricting the model elements used, profiling, etc.) we can get closer to "Good".
Conclusion on criticism 1
The criticism is justified, but on the one hand the authors see no real alternative, and on the other hand this does not automatically make SysML a failure.
Criticism 2: SysML is bulky
At this point, the authors mix up the modeling language with the modeling tools. Yes, the tools we work with today are bulky and not particularly user-friendly. But this was also true of software development tools in the 1980s.
To be fair, the authors later also write that MBSE has the task of "masking complexity". Nevertheless, topics are again mixed up here: MBSE, SysML and tools are not the same thing.
Conclusion on criticism 2
The problems mentioned are real, but they are problems that go far beyond the notation and in some cases have little to do with it. However, SysML v2 in particular addresses some of these points of criticism, for example through the introduction of the API and the alternative text notation.
Tool-specific problems in particular will certainly be solved in the medium term by the manufacturers (old and new) and service providers. We are already seeing how small companies such as LieberLieber (Enterprise Architect) or Sodius-Willert (Rhapsody) are developing their own extensions to mitigate the shortcomings of the tools.
Criticism 3: The company-wide hurdles are too high
The authors argue that SysML has no chance outside of systems engineering because it was developed for systems engineering. At the same time, however, the authors address the solution: Integration with other systems in the company.
Conclusion on criticism 3
This point confirms my opinion that MBSE will take a long time to become mainstream. In the short term, only companies where the pain (and demand) is correspondingly high will introduce MBSE. Because there the hurdles are not too high.
Ironically, the authors mention the mandate of Jeff Bezos (Amazon) to make the use of APIs mandatory as a reason for the success of AWS. The API of SysML v2 is designed to make it easier to break open the silos.
Criticism 4: SysML leaves out a large part of the product life cycle
The authors confirm that SysML is successfully used in system architecture, but criticize its neglect/lack of use in the other phases. Here they again mix the topics of MBSE, SysML and tools.
Conclusion on criticism 4
As with the other points, the authors are right that SysML / MBSE comparatively rarely covers the entire product life cycle. But we have to start somewhere. For companies that rely on modeling in the long term and strategically, the situation is different (as Andreas Willert describes in this interview).
Final conclusion
The authors address important problems in MBSE. The most important one is certainly that hype is always bad for a technology. The Gartner Hype Cycle predicts a period of disappointment for hyped technologies, which we naturally want to avoid as far as possible.
However, many of the points of criticism raised have little to do with SysML, but this is exactly what the title of the paper alludes to. Even though the paper is often about MBSE and tools, in my opinion there is not enough differentiation here.
The result could be that the decision-makers who read the paper throw the MBSE baby out with the SysML bathwater. And that would be a shame.
Image source: Michael Pierce and Bruce Cameron
