{"id":8193,"date":"2026-10-22T08:00:00","date_gmt":"2026-10-22T06:00:00","guid":{"rendered":"https:\/\/www.se-trends.de\/?p=8193"},"modified":"2026-10-19T11:15:04","modified_gmt":"2026-10-19T09:15:04","slug":"sysml-v2-transforms-modeling-into-engineering-infrastructure","status":"publish","type":"post","link":"https:\/\/www.se-trends.de\/en\/sysml-v2-wird-modellierung-zur-engineering-infrastruktur\/","title":{"rendered":"SysML v2: Is Modeling Becoming Part of the Engineering Infrastructure?"},"content":{"rendered":"\n

Boeing hat \u00fcber Jahrzehnte in Model-Based Systems Engineering (MBSE) investiert. SpaceX hat das nie in vergleichbarem Umfang getan und entwickelt trotzdem schneller. Bei Gespr\u00e4chen \u00fcber schnelle Hardwareentwicklung fallen immer wieder dieselben (teilweise ausgelutschten) Begriffe: Digital Thread, Impact-Analyse, durchg\u00e4ngige Traceability. Eigentlich sollte ein Systemmodell genau dies skalierbar erm\u00f6glichen. Brauchen wir Modellierung also unbedingt, oder ist sie optional?<\/p>\n\n\n\n

Der Widerspruch l\u00f6st sich auf, wenn man nicht fragt, ob modelliert wird, sondern wof\u00fcr. Ein Modell, das nur ein Expertenteam pflegt und liest, steckt in einem Silo und hat geringen nutzen. Ein Modell, auf das andere t\u00e4glich aufbauen, ohne dar\u00fcber nachzudenken, ist Infrastruktur. <\/p>\n\n\n\n

SysML v2 verspricht unter anderem, dies zu vereinfachen. Andererseits haben auch andere Modellierungssprachen diesen Anspruch. Ob sich mit SysML v2 diesbez\u00fcglich etwas \u00e4ndern wird, ist eine Frage, die ich mit Tim Weilkiens im Webinar am 2. November 2026 untersuchen werde (Anmeldung<\/a>).<\/p>\n\n\n\n\n\n\n\n

System Stewardship braucht eine Grundlage<\/h2>\n\n\n\n

Product Velocity<\/a> beschreibt Produktentwicklung als Velocity Loop aus vier Praktiken. Business definiert Richtung und Priorit\u00e4ten. Engineering entwirft und verifiziert. Delivery baut, betreibt und \u00fcberwacht. In der Mitte steht System Stewardship. Diese Praktik pflegt die Systemarchitektur, \u00fcbersetzt zwischen den drei \u00e4u\u00dferen Praktiken und bewahrt Wissen \u00fcber Iterationen hinweg.<\/p>\n\n\n\n

Wichtig ist dabei die Abgrenzung. System Stewardship ist eine Entscheidungs- und Strukturfunktion, keine Dokumentations- oder Governance-Funktion. Sie trifft verbindliche Entscheidungen \u00fcber Struktur, Schnittstellen und Trade-offs. Das\u00a0Product-Velocity-Modell\u00a0fasst ihre Aufgaben in drei Aktivit\u00e4ten zusammen:<\/p>\n\n\n\n

    \n
  1. Structure.<\/strong>\u00a0Business-Input wird in strukturierte Information \u00fcbersetzt, mit der Engineering arbeiten kann. Das System wird so zerlegt, dass Subsysteme m\u00f6glichst entkoppelt sind.<\/li>\n\n\n\n
  2. Commit.<\/strong>\u00a0Stewardship verantwortet die Zusage auf Systemebene: globale Konfiguration, systemweite Trade-offs, die unterschiedliche \u00c4nderungsdynamik von Hardware und Software.<\/li>\n\n\n\n
  3. Evolve.<\/strong>\u00a0Erkenntnisse aus dem Betrieb flie\u00dfen zur\u00fcck in die Architektur und von dort als gesch\u00e4ftsrelevante Einsicht zur\u00fcck zu Business.<\/li>\n<\/ol>\n\n\n\n

    Alle drei Aktivit\u00e4ten verlangen eine Repr\u00e4sentation der Architektur, die pr\u00e4zise genug f\u00fcr Analyse ist und lesbar genug f\u00fcr alle Beteiligten. Ein Systemmodell ist der naheliegende Kandidat. Die Frage lautet also: Wie weit kann System Stewardship Modellierung im Allgemeinen und SysML v2 im Speziellen als Grundlage nutzen?<\/p>\n\n\n\n

    \n
    \n
    \n
    Der Velocity-Loop erkl\u00e4rt: Ein Leitfaden f\u00fcr die Produktvelocity<\/a><\/blockquote>