4 Kritikpunkte zu SysML 2: Bitte mit Vorsicht genießen
Michael Pierce von TSP hat mit seinem Kollegen Bruce Cameron ein Essay verfasst, in dem er SysML kritisiert. Einerseits ist es lesenswert für Organisationen, die den strategischen Einsatz von SysML erwägen. Denn viele Punkte sind durchaus valide. Andererseits finde ich nicht alle Kritikpunkte als gerechtfertigt, jedenfalls nicht, ohne diese weiter zu qualifizieren. Trotzdem bringt uns diese Kritik weiter, um bezüglich SysML und MBSE fundierte Entscheidungen treffen zu können.
Das Schaf im Wolfspelz
Bruce Cameron ist Partner bei TSP (Technology Strategy Partners), einem kleinen, aber einflussreichen Beratungsunternehmen. Noch mehr qualifiziert ihn jedoch seine Rolle als Direktor der System Architecture Group am MIT, meiner Alma Mater. Sein Kollege Michael Pierce hatte in der Vergangenheit für mehrere Jahre bei SpaceX gearbeitet. Über die innovativen Ansätze im Systems Engineering bei SpaceX berichte ich hier ja auch regelmäßig.
Das sieben Seiten lange Paper haben die Autoren bei LinkedIn veröffentlicht und ist schnell gelesen. Der Titel „Ein Schaf im Wolfspelz“ suggeriert, dass SysML versucht, mehr zu sein, als es ist.
Die Kritik besteht aus vier konkreten Punkten, auch die ich gleich weiter eingehe. Vieles ist durchaus gerechtfertigt, aber: Leider enthält das Paper auch viel „Click-Bait“ und ist ein übertrieben. Das fängt schon beim Titel an: Wir haben einen Hype. Es gehört zur Definition eines Hypes, dass die Erwartungen überzogen sind.
SysML wurde als „Rosetta-Stein“ gesehen, um die durch Komplexität verursachten organisatorischen Spannungen aufzulösen. Es zeigt sich nun, dass SysML nicht die Lösung ist.
Michael Pierce und Bruce Cameron
Kritik 1: Die Lernkurve ist zu steil
SysML ist ohne Zweifel eine komplexe Sprache. Aber deswegen ist SysML ja auch für so viele unterschiedliche Domänen geeignet. Doch die Autoren sehen dies als die eigentliche Ursache für ihre Kritik an SysML. Hilfreich fand ich das folgende Bild aus dem Paper:
Eine „perfekte“ Modellierungssprache würde dem Szenario „Good“ im Bild entsprechen. Wo genau die Autoren SysML sehen sagen sie nicht, implizieren aber das Szenario „Less Good“. Verglichen mit den zwei anderen Alternativen ist das gar nicht schlecht. Mit entsprechenden Techniken (Einschränken der verwendeten Modellelemente, Profiling, etc.) können wir uns „Good“ annähern.
Fazit zu Kritik 1
Die Kritik ist zwar gerechtfertigt; aber zum einen sehen die Autoren keine wirkliche Alternative, zum anderen macht das SysML nicht automatisch zu einem Misserfolg.
Kritik 2: SysML ist sperrig
An dieser Stelle vermischen die Autoren die Modellierungssprache mit den Modellierungswerkzeugen. Ja, die Werkzeuge, mit denen wir heute arbeiten, sind sperrig und nicht sonderlich benutzerfreundlich. Doch das traf auch auf Softwareentwicklungswerkzeuge in den 1980ern zu.
Fairerweise schreiben die Autoren später auch, dass MBSE die Aufgabe hat, die „Komplexität zu maskieren“. Dennoch werden auch hier wieder Themen vermischt: MBSE, SysML und Werkzeuge sind nicht dasselbe.
Fazit zu Kritik 2
Die angesprochenen Probleme sind real, sind aber Probleme die weit über die Notation hinausgehen und teilweise wenig mit ihr zu tun haben. Doch gerade SysML v2 addressiert einige dieser Kritikpunkte, zum Beispiel durch die Einführung der API und der alternativen Textnotation.
Gerade werkzeugspezifische Probleme werden mittelfristig sicher durch die Hersteller (alte und neue) sowie Dienstleister gelöst werden. Wir sehen ja heute schon wie kleine Firmen wie LieberLieber (Enterprise Architect) oder Sodius-Willert (Rhapsody) eigene Erweiterungen entwickeln, um die Defizite der Werkzeuge zu entschärfen.
Kritik 3: Die unternehmensweiten Hürden sind zu hoch
Die Autoren argumentieren, dass SysML außerhalb des Systems Engineering keine Chance hat, da es für das Systems Engineering entwickelt wurde. Die Autoren sprechen aber gleichzeitig die Lösung an: Integration mit anderen Systemen im Unternehmen.
Fazit zu Kritik 3
Dieser Punkt bestätigt meine Meinung, dass MBSE lange brauchen wird, um in den Mainstream zu kommen. Kurzfristig werden nur Unternehmen MBSE einführen, wo der Schmerz (und Bedarf) entsprechend hoch ist. Denn dort sind die Hürden eben nicht zu hoch.
Ironischerweise erwähnen die Autoren das Mandat von Jeff Bezos (Amazon), APIs verpflichtend zu nutzen, als Grund für den Erfolg von AWS. Die API von SysML v2 hat zum Zweck, das Aufbrechen der Silos einfacher zu machen.
Kritik 4: SysML lässt einen Großteil des Produktlebenszyklus aus
Die Autoren bestätigen, dass SysML erfolgreich in der Systemarchitektur eingesetzt wird, kritisieren aber das Vernachlässigen/Fehlen in den anderen Phasen. Hier mischen sie wieder die Themen MBSE, SysML, und Werkzeuge.
Fazit zu Kritik 4
Wie auch bei den anderen Punkten haben die Autoren recht, dass SysML / MBSE vergleichsweise selten den ganzen Produktlebenszyklus abdeckt. Doch irgendwo müssen wir ja anfangen. Bei Firmen, die langfristig und strategisch auf Modellierung setzen, sieht das anderes aus (wie Andreas Willert in diesem Interview beschreibt).
Endgültiges Fazit
Die Autoren sprechen wichtige Probleme im MBSE an. Das wichtigste ist sicherlich, dass ein Hype immer schlecht für eine Technologie ist. Der Gartner Hype Cycle sagt für gehypte Technologien eine Endtäuschungsphase voraus, und die wollen wir natürlich möglichst vermeiden.
Doch viele der angesprochenen Kritikpunkte haben nur wenig mit SysML zu tun, doch genau darauf spielt der Titel des Papers an. Auch wenn es im Paper oft über MBSE und Werkzeuge geht, wird meiner Meinung nach hier nicht genug differenziert.
Das Ergebnis könnte sein, dass die Entscheider, die das Paper lesen, das MBSE-Baby mit dem SysML-Badewasser ausschütten. Und das wäre ein Jammer.
Bildquelle: Michael Pierce und Bruce Cameron
