Warum funktionale Ketten keine Capability Threads sind

Ein Modell kann eine funktionale Kette zeigen und trotzdem nichts am Lieferproblem ändern. Dann beschreibt MBSE nur, wo später die Integration scheitert. Robin Yeman traf diesen Punkt in ihrer Keynote auf dem MBSE Summit. Ihr Thema war Industrial DevOps. Der schärfste Satz lag tiefer: Wer nach Fachfunktionen zerlegt, baut keine Fähigkeit. Er baut Übergaben.

Ein Lebenszyklus statt fünf Transformationen

Robin Yeman arbeitet seit rund dreißig Jahren an großen, sicherheitskritischen Systemen. Sie war lange bei Lockheed Martin, unter anderem in Satellitenprogrammen. Heute arbeitet sie als Technical Fellow bei Leidos an Flugsicherungssystemen. Ihre Dissertation untersuchte, wie sich Agile und DevOps auf große cyberphysische Systeme übertragen lassen. Dafür sprach sie mit Ingenieuren von SpaceX, Relativity, Planet Labs und der NASA.

Aus dieser Praxis entstand mit Suzette Johnson das Buch Industrial DevOps. Der Begriff klingt nach DevOps für Hardware, aber gemeint istmehr. Industrial DevOps fordert einen gemeinsamen Lebenszyklus für System, Software, Hardware, Test und Betrieb.

Genau daran scheitern viele Transformationen. Eine Organisation startet MBSE, Agile, DevSecOps, Cyber Security und KI als getrennte Initiativen. Jede Funktion bekommt ihre eigene Sprache, ihre eigenen Werkzeuge, ihr eigenes Budget und ihren eigenen Berater. Am Ende gibt es fünf Fortschrittsberichte und ein Integrationsproblem.

Robin nennt das Cognitive Load. Programm Management denkt in Earned Value und Terminen. Systems Engineering denkt in Modellen. Hardware denkt in Prototypen. Software denkt in Sprints. Test denkt in Nachweisen. Betrieb denkt in Stabilität. Alle arbeiten angeblich am selben System. Praktisch optimiert jede Funktion ihr eigenes Zwischenprodukt.

Modelle sind nicht das Ergebnis

Diese Logik trifft MBSE besonders hart. Robin beschreibt Teams, die exzellente Modelle bauen. Die Softwareentwicklung nutzt sie nicht. Der Kunde gibt kein Feedback, weil er die Notation nicht versteht oder das Modell nie sieht. Das Modell ist korrekt, aber nicht wirksam. Dann wird MBSE zum Silo.

Das Problem liegt nicht im Modellieren. Das Problem liegt darin, dass das Modell zum Ergebnis erklärt wird. Wer Software baut, hält Software für das Produkt. Modellierer halten das Modell für das Produkt. Tester halten die Tests für das Produkt. Keines davon ist das Ergebnis, das beim Kunden ankommt.

In einem Projekt zur Flugsicherung erzeugte Robin deshalb neben den Modellen weitere Sichten. Sie zeigten Bewegung, Datenflüsse und Sequenzen. Damit konnten auch Menschen Feedback geben, die keine MBSE Notation lesen. Das Modell blieb wichtig. Es verlor nur den Anspruch, allein verständlich zu sein.

Dahinter steht Conways Gesetz. Organisationen bauen Systeme, die ihre Kommunikationsstruktur spiegeln. Wenn Systems Engineering, Software, Hardware und Test getrennt arbeiten, entstehen die Risiken an den Grenzen. Genau dort explodieren sie später bei der Integration.

Funktion kippt in Organisation

Der zentrale Punkt in Robins Vortrag war die Dekomposition. Viele Programme zerlegen ihr System nicht, sondern beschreiben ihren Lebenszyklus.

Robin erzählte von einem Radarprogramm in Alaska. Auf die Frage, wie man das Radar zerlegt, kam als Antwort: erst Design, dann Architektur, dann Implementierung. Das ist keine Systemzerlegung sondern ein Ablaufplan.

Hier wird das Wort Funktion gefährlich. In MBSE meint Funktion eine Leistung des Systems. In der Organisation meint Funktion eine Disziplin. Robin kritisiert nicht, dass Systeme über Funktionen verstanden werden. Sie kritisiert, dass Programme ihre Arbeit entlang organisatorischer Fachfunktionen zerlegen.

Wer so zerlegt, landet bei Systems Engineering, Software Engineering, Hardware Engineering und Test. Wer nach Ergebnissen zerlegt, landet bei Fähigkeiten wie Command and Control, Guidance Navigation and Control oder OTA Update.

Nur die zweite Zerlegung erzeugt einen Capability Thread. Ein Capability Thread ist ein schmaler Durchstich durch Requirements, Modell, Architektur, Software, Hardware, Test und Betrieb. Er zeigt früh eine Fähigkeit des Systems. Nicht vollständig. Aber integriert genug, um Annahmen zu prüfen.

Automotive MBSE und die falsche Beruhigung

Dieser Punkt trifft die Automobilindustrie. Viele OEMs und Zulieferer arbeiten seit Jahren mit funktionalen Ketten. Das ist durchaus sinnvoll. Eine Fahrerassistenzfunktion, ein OTA Update oder ein Thermal Management System realisieren ihre Funktionen, indem sie Funktionsketten bilden, die kleiner Funktionen wiederverwenden.

Trotzdem bleibt die Lieferstruktur oft alt. Systems Engineering modelliert die funktionale Kette. Software implementiert Teile davon. Hardware liefert Steuergeräte, Sensorik oder Aktorik. Test prüft später gegen Anforderungen. Integration findet zu spät statt. Dann sieht das Modell nach End to End aus. Die Arbeit bleibt stückweise.

Eine funktionale Kette verbindet Systemfunktionen. Ein Capability Thread verbindet Arbeit. Er zwingt Requirements, Architektur, Schnittstellen, Implementierung, Test, Nachweis und Feedback in einen gemeinsamen Lernzyklus.

Genau dort entsteht MBSE Theater. Die funktionale Kette sieht nach früher Integration aus. Tatsächlich wurde nur früher dokumentiert, wo später integriert werden muss.

Integration zuerst

Robin stellt die übliche Reihenfolge auf den Kopf. Viele Programme planen, entwerfen und bauen lange getrennt. Drei Viertel durch das Projekt kommt die Integration. Dann zeigt sich, dass zentrale Annahmen falsch waren.

Ihre Gegenfrage ist schlicht:

„Why don’t we begin with the really hard thing?“

Robin Yeman

Suzette Johnson und Robin formulieren denselben Zusammenhang in ihrem Buch als Integrationsregel:

„There is a direct correlation between the length of time between integrating and the amount of rework that is required.“

Suzette Johnson, Robin Yeman

Je länger die Integration wartet, desto größer wird die Nacharbeit.

Robin zeigte das an einem F 16 Retrofit. Geplant waren rund vierzehn Monate. Sie stellte getrennte System, Software, Hardware und Testteams auf funktionsübergreifende Teams um. Diese Teams bauten Fähigkeiten am Flugzeug, nicht Artefakte für die nächste Übergabe. Das Programm lieferte nach neun Monaten und ging mit wenigen Fehlern in die Hardware Integration.

Das Tempo kam nicht durch schnelleres Tippen. Es kam durch weniger Übergaben.

Damit wird auch das V Modell nicht falsch. Falsch ist die bequeme Interpretation, dass Konvergenz bis zur rechten Seite warten darf. Das V Modell beschreibt eine logische Beziehung zwischen Spezifikation und Nachweis. Es ist keine Erlaubnis, Integration ans Projektende zu schieben.

KI beschleunigt auch den Stau

Robins Beobachtung zu KI ist trocken:

„AI just makes things faster, but if I’m building things faster in my silo, I have more work in progress and still nothing getting completed to the end.“

Robin Yeman

KI im Silo erzeugt mehr Work in Progress: Anforderungen, Backlog Items, Code, Testfälle und mehr Modelle. Nichts davon verbessert den Flow, wenn die Arbeit weiter an denselben Grenzen wartet.

Damit wiederholt sich das alte Muster. Eine neue Technologie beschleunigt lokale Arbeit. Das Gesamtsystem bleibt langsam.

Robin sieht den größeren Hebel deshalb nicht nur in der Softwareentwicklung, denn Software ist lediglich ein Teil des Value Streams. In großen cyberphysischen Systemen liegen viele Verzögerungen im Systems Engineering, im Test, in Compliance und in der Integration. Dort kann KI mehr bewirken als beim schnelleren Schreiben einzelner Codezeilen.

Praktische Beispiele aus ihrem Vortrag waren:

1. Backlog aus Anforderungen. KI erzeugt aus Anforderungen erste Backlog Strukturen und Akzeptanzkriterien. Das hilft, weil Akzeptanzkriterien in der Praxis oft schwach bleiben.
2. Modelle. Teams lassen SysML v2 generieren und importieren das Ergebnis in Werkzeuge wie Cameo oder Enterprise Architect. Sie starten nicht mehr bei null im Tool.
3. Trade Studies. Mehrere Agenten prüfen mit demselben Kontext verschiedene Architekturvarianten. Das ersetzt kein Engineering Urteil, verkürzt aber die Vorarbeit.
4. Compliance und Nachweise. KI unterstützt bei Evidenz, Bedrohungsanalyse und Dokumentenarbeit. Der Wert entsteht erst, wenn die Ergebnisse mit Traceability und Tests verbunden sind.

Ein zweiter Nutzen ist Sprache. KI übersetzt zwischen Disziplinen. Wer mit einem Elektroingenieur über eine Schnittstelle spricht, kann sich die Problemstellung in dessen Sprache erklären lassen. Dasselbe Problem haben die Werkzeuge. CAD, MBSE Tools, Testsysteme und Repositories sprechen selten dieselbe Sprache.

KI gehört deshalb auf den Digital Thread, nicht daneben.

Traceability als Nebenprodukt

Auch bei Agilität räumt Robin mit einem Missverständnis auf. Agile in sicherheitskritischen Systemen heißt nicht, wie Netflix alle elf Sekunden zu deployen. Flugsicherung, Luftfahrt und Verteidigung brauchen formale Tests, Zertifizierung und Nachweise. Agile und reguliert schließen sich nicht aus. Sie verlangen nur andere Pipelines.

Eine solche Pipeline verbindet Anforderungen, Backlog, Tests und Repository. Anforderungen liegen zum Beispiel in DOORS oder Jama. Der Backlog hängt daran. Tests hängen am Backlog. Commits im Repository referenzieren die User Story. Die Pipeline zieht daraus bidirektionale Traceability.

Kein Mensch pflegt diese Spuren von Hand nach.

Damit wird Traceability ein Nebenprodukt der Arbeit. Sie entsteht nicht als Aufräumaktion kurz vor dem Audit. Sie entsteht, weil die normale Arbeit die richtigen Spuren hinterlässt.

Das ist der Unterschied zwischen dokumentierter Kontrolle und operativer Kontrolle. Dokumentierte Kontrolle erklärt später, was passiert sein soll. Operative Kontrolle macht sichtbar, was gerade passiert.

Skills statt Rollen

Skills statt Rollen: Dies trifft Systems Engineering, laut Robin, im Kern. SpaceX sagte laut Robin gegenüber der NASA sinngemäß, alle Ingenieure dort seien Systemingenieure. Das heißt nicht, dass es keine Systemtechnik gibt. Es heißt, dass Systemdenken nicht in einem Silo namens Systems Engineering eingesperrt ist.

Etablierte Unternehmen tragen an dieser Stelle eine besondere technische Schuld. Sie haben sich an ihre Organigramme gewöhnt. Teams modellieren, planen und liefern entlang dieser Struktur. Dann wundern sie sich, dass die Architektur dieselben Brüche zeigt.

Das Inverse Conway Maneuver setzt genau dort an. Teams werden entlang der gewünschten Systemarchitektur geschnitten. Nicht entlang der bestehenden Fachabteilungen.

Für Capability Threads bedeutet das: Ein Team braucht die Skills, um den Thread zu bauen und zu testen. Es braucht nicht alle Spezialisten permanent im selben Raum. Es braucht aber die Verantwortung für eine integrierte Fähigkeit. Sonst bleibt der Thread eine Koordinationsaufgabe zwischen Silos.

Vertrauen bleibt beim Engineering, nicht KI

KI ändert nichts an der Verantwortung des Engineering, verschiebt aber die Stelle, an der Engineering genauer hinschauen muss.

Robin unterscheidet nach Risiko. Bei Dokumentenarbeit reicht oft Human on the Loop. Der Mensch prüft Ergebnisse. Bei sicherheitsrelevanten Entscheidungen braucht es Human in the Loop. Der Mensch entscheidet, welcher Vorschlag gültig ist. Vieles bleibt Human Assist. Die KI arbeitet zu, aber der Mensch führt.

Für Safety Cases ist das entscheidend. Robin bejaht KI Artefakte in Safety Cases, aber nur mit Validierung. Kleine Schritte. Wiederholte Prüfung. Nachvollziehbare Entstehung. Keine magischen Textblöcke aus dem Modellnebel.

Ihre offene These ist die Verbindung von KI und formalen Methoden. KI liefert Geschwindigkeit und Sprache. Formale Methoden liefern Nachvollziehbarkeit, Reproduzierbarkeit und prüfbare Eigenschaften. Für sicherheitskritische Systeme reicht ein plausibler Text nicht. Das System muss belastbare Gründe liefern.

Damit ist schnell gegen sicher die falsche Gegenüberstellung. Schnell und sicher entsteht nicht durch Mut. Es entsteht durch eine Pipeline, die Integration, Test, Traceability und Nachweise früh verbindet.

Fazit

Robin stellt MBSE nicht infrage. Sie stellt die traditionelle Version von MBSE infrage. Funktionale Ketten reichen nicht, wenn sie nur Modelle strukturieren. Sie müssen Lieferarbeit strukturieren. Erst dann werden sie zu Capability Threads.

Für die Praxis folgt daraus das folgende Vorgehen:

1. Eine Fähigkeit wählen, die für das Produkt zählt.
2. Einen dünnen Capability Thread durch Requirements, Modell, Software, Hardware, Test und Nachweis schneiden.
3. Ein funktionsübergreifendes Team für diesen Thread verantwortlich machen.
4. Integration und Feedback an den Anfang ziehen.
5. KI dort einsetzen, wo sie den Thread beschleunigt, nicht nur ein Silo produktiver macht.

Der Bezug zu Product Velocity liegt genau hier: Geschwindigkeit entsteht nicht durch mehr Output in einzelnen Funktionen. Geschwindigkeit entsteht, wenn weniger Arbeit an Übergängen stecken bleibt.

Automotive MBSE hat mit funktionalen Ketten das richtige Strukturmuster erkannt. Der nächste Schritt ist härter: Das Muster muss aus dem Modell in die Lieferorganisation wandern.