Von SysML v1 zu SysML v2: Lohnt sich der Umstieg?

Vor kurzem habe ich auf LinkedIn unser Whitepaper „From SysML v1 to SysML v2" vorgestellt. Der Post lief gut, aber die interessanteste Reaktion war eine kritische: „I wish somebody would address the value proposition for moving to V2. At a glance it does not look very good. I must be missing something…" Eine berechtigte Frage, auf die man selten eine nüchterne Antwort liest. Als unabhängige Berater verdienen wir unser Geld nicht mit dem Standard, sondern mit funktionierendem modellbasiertem Systems Engineering. Meine Meinung dazu ist deshalb etwas differenzierter und lässt sich am besten in drei Fragen beantworten: Was macht v2 wirklich besser, und wo zeigt sich das messbar im ROI? Was spricht gegen den Umstieg? Und für wen rechnet sich der Wechsel?

Was macht v2 wirklich besser, und wo zeigt sich das im ROI?

Vorweg zur Einordnung: SysML v2 ist kein v1.8. Die Sprache wurde auf einem formalen Fundament (KerML) neu aufgebaut, mit bewussten Brüchen zu v1. Fünf Verbesserungen halte ich für substanziell. Weil „höherer ROI" eine Behauptung bleibt, solange niemand die Kostenposition benennt, die sinkt, steht bei jeder dabei, ob sie messbar Geld spart oder ob sie das Leben der Beteiligten einfach leichter macht.

Ein Muster statt vieler Sonderfälle. Das Definition/Usage-Prinzip zieht sich durch fast alle Sprachelemente: part def und part, action def und action, requirement def und requirement. Wer das Muster einmal verstanden hat, kann sich große Teile der Sprache selbst erschließen. In v1 folgen Blöcke, Aktivitäten, Anforderungen und Ports jeweils eigenen Regeln, viele davon UML-Erbe. Messbar im ROI: ja, an der Einarbeitung. Miss die Schulungstage und die Zeit bis zur ersten produktiven Modelländerung, und vergleiche sie über deine Onboardings hinweg. Dieser Hebel wirkt bei jedem einzelnen Onboarding erneut, er ist also umso größer, je mehr Fluktuation oder Zulieferer-Ingenieure dein Projekt hat.

Verhalten lebt sichtbar in der Struktur. Auch v1 kann Verhalten an Struktur hängen: Ein Block besitzt sein classifierBehavior, Operationen haben Methoden. Die Trennung beginnt eine Ebene tiefer, innerhalb des Verhaltens. Eine v1-Aktivität arbeitet mit eigenen Parametern und Pins; die Ports des Blocks kennt sie nicht. Wer die Ein- und Ausgänge des Parts im Aktivitätsdiagramm nutzen will, baut Hilfskonstrukte aus ReadSelfAction und ReadStructuralFeatureAction und hält Ports und Pins von Hand konsistent. Genau daran sind wir in einem Cameo-Projekt gescheitert, bis die Sonderlösung stand. In v2 sind Aktionen Usages im Namensraum des Parts: Eine perform action greift direkt auf die Ports ihres Parts zu, und im Diagramm ist sichtbar, welches Verhalten welches Systemelement ausführt. Messbar im ROI: kaum. Eine Spezifikation, die Rückfragen vorwegnimmt, spart Review-Schleifen, aber sauber zurechnen lässt sich das selten. Dieser Punkt macht vor allem das Leben leichter.

Textuelle Notation und Standard-API. Ein v2-Modell ist auch Text. Das heißt: Diff und Merge in Git, Modell-Reviews im Merge Request, Analysen und Generierung ohne proprietäre Plugin-Entwicklung. Dazu kommt eine standardisierte API für den Werkzeug- und Skriptzugriff auf das Modell. Messbar im ROI: gleich zweimal. Erstens in Ingenieurstunden pro Review-Runde: Reviewer sehen im Diff, was sich seit dem letzten Stand geändert hat, statt zwei Diagrammversionen nebeneinanderzulegen. Bedingung ist, dass sie die Notation lesen können. Zweitens am Aufwand für Automatisierung: Gegen eine Standard-API schreibt jeder software-affine Ingenieur Konsistenzchecks, Auswertungen und Generatoren; in der v1-Welt hieß dasselbe oft Java-Plugin-Entwicklung durch einen dedizierten Tool-Spezialisten. Vergleiche, was euch eine solche Auswertung heute kostet.

Freie Toolwahl statt Herstellerfalle. Ein Standard, dessen Modelle als Text vorliegen, senkt die Eintrittshürde für Toolhersteller: Die Auswahl reicht schon heute vom leichtgewichtigen Editor mit Visualisierung bis zum klassischen Vollclient. Vor allem aber nimmst du dein Modell beim Wechsel von Hersteller x zu y einfach mit, wie Quellcode beim Wechsel der IDE. In v1 war der Toolwechsel wegen des verlustbehafteten Austauschs faktisch eine Neu-Modellierung. Wie eng die Falle sitzt, habe ich in einem Projekt mit IBM Rhapsody erlebt: Systemarchitektur in Version 9.x, die darauf aufbauende Softwarearchitektur in 8.x. Ein Modellimport für Verlinkungen und Allokationen zwischen beiden war nicht möglich, ohne die ältere Version unwiderruflich upzugraden, was aus diversen Gründen ausschied. Gleicher Hersteller, gleiche Sprache, und trotzdem eine Mauer. Eine Einschränkung gehört dazu: Mitnehmen kannst du das Modell und die View-Definitionen, nicht die handoptimierten Diagramm-Layouts. Grafische Darstellung bleibt auch in v2 toolspezifisch. v1s größte Achillesferse beim Austausch, die Diagramme, mildert v2 nur insofern, als Sichten dort generiert statt von Hand gepflegt werden. Messbar im ROI: erst im Ereignisfall, an vermiedenen Migrationskosten beim nächsten Tool- oder Versionswechsel und an den Konditionen der nächsten Lizenzverlängerung. Vorab lässt sich beides nur als Risikoabschlag im Business Case ansetzen.

Interoperabilität. Der vorige Punkt betraf den Wechsel des eigenen Tools. Hier geht es um den laufenden Austausch über Organisationsgrenzen hinweg, bei dem jede Seite ihr Tool behält. Ein Kommentator unter meinem Post, Doug Rosenberg, nannte sie „the biggest win by a wide margin". Ich teile die Richtung. Messbar im ROI: überall dort, wo heute Modelle an Organisationsgrenzen neu gebaut werden. Der Zulieferer bekommt ein PDF oder ein verlustbehaftetes XMI und modelliert nach, der Integrator prüft manuell gegen; ein standardisiertes Austauschformat macht aus dieser Doppelarbeit einen Import. Der heutige Aufwand pro Modellübergabe ist damit die Messgröße, und zugleich die Obergrenze des Einsparpotenzials. Zwei Bedingungen bleiben: Beide Seiten müssen v2 sprechen, und den Beweis dafür, welche Vorteile sich in der Breite wirklich ergeben, muss die neue Sprache erst noch abliefern.

Keiner dieser Punkte ist ein Automatismus, und für keinen gibt es eine belastbare Branchenzahl. Der Kern deines Business Case ist, sie im eigenen Kontext zu messen: Tage pro Onboarding, Stunden pro Review-Runde, Aufwand pro Modellübergabe, Konditionen bei der nächsten Toolentscheidung.

Was spricht gegen den Umstieg?

Die Werkzeuglandschaft ist jung. Kollaboration im großen Team, Integration mit Requirements-Management-Tools wie DOORS oder Polarion, Report-Generierung für Assessments: Diese Fähigkeiten wurden in reifen v1-Tools über Jahre gehärtet und sind in der v2-Werkzeuglandschaft noch ungleich verteilt. Prüfe die Muss-Kriterien deines Prozesses gegen konkrete Tool-Versionen, nicht gegen Roadmaps.

Migration ist Re-Modellierung. Eine verlustfreie Knopfdruck-Migration von v1 nach v2 gibt es nicht. Die OMG spezifiziert zwar eine Transformation, aber die Semantiken unterscheiden sich, und spätestens bei euren Profilen, Stereotypen und Skripten endet jede Automatik. Realistisch ist eine werkzeuggestützte Neu-Modellierung mit Review, keine Konvertierung. Manche Toolhersteller bieten zwar native Transformations-PlugIns an, den vollen Mehrwert der v2 wird man dadurch jedoch ohne weitere, manuelle Anpassungen nicht heben können.

Eure v1-Investitionen sind real. Geschulte Teams, etablierte Methodik, Profile und Bibliotheken, Automatisierung, eingespielte Review-Prozesse. Dieser Bestand wiegt in jedem Business Case schwerer als Sprachvorteile auf dem Papier.

Und die Fundamentalkritik. Ein weiterer Kommentar unter meinem Post lautete sinngemäß: v2 habe zu viel auf das ohnehin missratene v1 draufgepackt, Semantik müsse vor Notation kommen, und Ansätze wie CSDL oder Werkzeuge der CORE/GENESYS-Linie hätten das lange vor SysML vorgemacht. Diesen Einwand nehme ich ernst. Die v2-Antwort darauf ist KerML als formale Basis unter der Sprache. Ob die OMG damit den Nagel getroffen hat, wird sich erst zeigen, wenn große Programme mit v2 durch mehrere Produktzyklen gegangen sind.

Für wen rechnet sich der Umstieg?

Ob die messbaren Hebel aus dem ersten Kapitel die Umstiegskosten übersteigen, hängt davon ab, wo du startest:

Reife v1-Bestandsmodelle. Hier bin ich eindeutig: Ein funktionierendes, validiertes v1-Modell allein der v2-Konformität wegen zu portieren, rechnet sich nicht. Du bezahlst Re-Modellierung, Re-Validierung und die Umschulung des Teams und bekommst dieselbe Information in schönerer Sprache zurück. Die eine Ausnahme, die ich gelten lasse: Das Modell wird zur Basis einer neuen Plattform-Familie mit langem Produktlebenszyklus. Dann verteilt sich die Investition über viele Jahre, und die v2-Vorteile bei Automatisierung und Austausch zahlen über die gesamte Laufzeit ein.

Neues Produkt, neues Modell. Ohne Migrationskosten sieht die Rechnung anders aus. Die flachere Lernkurve und die Automatisierungsmöglichkeiten wirken ab dem ersten Tag. Bleibt die Tool-Frage: Erfüllt eine v2-Toolchain heute die Muss-Anforderungen deines Prozesses? Wenn ja, spricht wenig dafür, ein neues Modell in einer Sprache zu beginnen, deren Lebensende absehbar ist.

MBSE-Einführung von null. Der stärkste v2-Fall. Wer aus einer dokumentenbasierten Organisation kommt, muss niemanden von v1 umgewöhnen, und das einheitliche Definition/Usage-Muster senkt die Einstiegshürde für das ganze Team. Eine Warnung aus Projekterfahrung gehört aber dazu: MBSE-Einführungen scheitern nicht an der Sprachversion. Methodik, Modellierungsrichtlinien und Management-Rückhalt wiegen schwerer als die Frage v1 oder v2.

Wechseln oder bleiben?

Aus den drei Ausgangslagen ergeben sich für mich klare Muster:

Und für alle Fälle dazwischen gilt: nicht nach Bauchgefühl und nicht nach Konferenz-Stimmung urteilen. Evaluiere mit euren eigenen Use Cases und einem Pilotmodell gegen eure eigenen Kriterien. Niemand zwingt dich zur Eile; v1-Tools verschwinden nicht über Nacht, und ein gut geführtes v1-Modell ist allemal mehr wert als ein schlecht geführtes v2-Modell.

MBSE-Einführung mit itemis — von der Analyse deiner Ausgangslage über die Tool-Auswahl bis zur Implementierung der ersten Schritte zum finalen Modell: Systems Engineering →