15 Jahre Softwareentwicklung ohne formale Architektur: Warum sich das jetzt ändern könnte

Ich muss etwas gestehen: In 15 Jahren Softwareentwicklung haben wir für unsere internen Projekte praktisch nie eine vollständig spezifizierte, formale Softwarearchitektur erstellt.

Natürlich gab es Architektur. Es gab Whiteboards, PowerPoint-Folien, Diagramme und jede Menge Diskussionen. Aber ein durchgängig spezifiziertes, konsistentes und gepflegtes Architekturmodell, wie man es aus klassischen Entwicklungsmethoden kennt?

Fehlanzeige.

Eine Rechnung, die nicht aufging

Und das hatte einen guten Grund: Es hat sich wirtschaftlich schlicht nicht gelohnt.

Wir unterlagen keiner Regulatorik, die uns dazu gezwungen hätte. Also konnten wir Kosten und Nutzen frei gegeneinander abwägen.

Die Kosten waren offensichtlich: Ein formal korrektes Architekturmodell zu erstellen und kontinuierlich zu pflegen, kann ähnlich aufwendig sein wie die eigentliche Implementierung.

Der Nutzen dagegen war schwerer zu greifen: bessere Kommunikation, frühzeitiges Erkennen von Architekturfehlern, Möglichkeiten zur formalen Verifikation und natürlich Compliance.

Gerade in einer agilen Entwicklung entsteht hier ein fundamentales Problem: Eine Architektur, die sich nicht mit dem Code weiterentwickelt, verliert mit jeder Änderung an Wert. Gestern noch korrekt, heute schon veraltet. Als Kommunikationsmittel zunehmend irreführend, als Grundlage für Verifikation unzuverlässig.

Ein Modell, das nicht mit dem Code mitwächst, beschreibt nicht das System. Es beschreibt, wie das System einmal gedacht war.

Also haben wir uns in unseren internen Projekten für den pragmatischen Weg entschieden: Von der Anforderung direkt zum Code. Architekturentscheidungen wurden getroffen, diskutiert und implementiert, aber selten vollständig formalisiert.

Dokumentiert heißt nicht aktuell

Bei unseren Kunden sah die Welt anders aus.

Unsere Kunden kommen fast ausschließlich aus regulierten Branchen. Dort sind Architekturmodelle, Nachvollziehbarkeit und dokumentierte Entwicklungsprozesse oft unverzichtbar.

Aber machen wir uns nichts vor: Nur weil eine Architektur dokumentiert ist, bedeutet das noch lange nicht, dass sie die tatsächliche Implementierung beschreibt.

In der Praxis entwickeln sich Anforderungen, Architekturmodelle und Implementierung häufig parallel nebeneinanderher. Und kurz vor dem nächsten Audit wird dann mit viel Aufwand versucht, alles über Traceability miteinander zu verbinden, sodass die Lücken möglichst nicht auffallen. Schließlich war Traceability bislang vor allem ein quantitativer, selten ein qualitativer Beleg.

Das eigentliche Engineering-Wissen steckt selten in den Modellen. Es steckt in den Köpfen der Entwickler und in der Implementierung.

Die Dokumentation existiert zwar, es gibt aber ein Delta.

MBSE war nie ein Geschwindigkeitsversprechen

Als Verfechter von Model-Based Systems Engineering (MBSE) und modellgetriebener Entwicklung war unsere Argumentation deshalb immer:

„Wenn ihr das Modell ohnehin erstellen müsst, dann macht es so, dass es euch auch nutzt!"

FMEA und TARA aus dem Modell ableiten. Code generieren. Traceability by Design.

Die Idee: Mehr Engineering im Modell, weniger manuelle Arbeit in nachgelagerten Prozessschritten. Was sich deterministisch ableiten lässt, muss nicht aufwendig manuell gepflegt werden.

Technisch funktioniert das gut. Wirtschaftlich nur bedingt.

Um die Vorteile nutzen zu können, müssen die Modelle eine Qualität und Detailtiefe erreichen, deren Wartung enorm aufwendig ist. Das muss sich rechnen.

Die Entwicklung wird in der Regel nicht wirklich schneller. Man erreicht ein definiertes Qualitätsniveau nur zuverlässiger, erkennt Fehler früher und reduziert den Aufwand für Assessments.

Das ist wertvoll. Aber gerade unter Kostendruck nicht immer ausreichend sichtbar, um die Investition zu rechtfertigen.

MBSE war nie ein Geschwindigkeitsversprechen. Es war ein Qualitätsversprechen. Und Qualität lässt sich schlecht gegen Liefertermine rechnen.

Zwei Entwicklungen verändern gerade diese Rechnung grundlegend: CRA und KI.

1. Der Cyber Resilience Act verändert den Nutzen

Der Cyber Resilience Act verlangt von Herstellern betroffener digitaler Produkte nicht nur Sicherheit zum Zeitpunkt der Auslieferung, sondern auch dokumentiertes Risikomanagement, technische Nachweise und einen wirksamen Umgang mit Schwachstellen über den gesamten Lebenszyklus.

Damit reicht es nicht mehr, die Architektur so zu dokumentieren, dass man einmal durchs Assessment kommt.

Wenn morgen eine kritische Schwachstelle in einer Komponente auftaucht, muss ich wissen, welche Produkte betroffen sind, wo die Komponente eingesetzt wird, welche Abhängigkeiten bestehen und welche Maßnahmen erforderlich sind.

Ein aktuelles, mit der Implementierung verknüpftes Architekturmodell wird damit vom lästigen Dokumentationsaufwand zum operativen Werkzeug.

Der CRA schreibt das zwar nicht vor, aber es macht einen erheblichen Unterschied, ob ich ein Systemmodell einmal im Assessment oder jeden zweiten Tag zur Risikobewertung brauche.

Aus einmaligem Nachweis wird kritische Infrastruktur.

2. KI und SysML v2 verändern die Kosten

Mit Large Language Models und der textuellen Syntax von SysML v2 entsteht gleichzeitig eine völlig neue Möglichkeit, Architekturmodelle zu erstellen und zu pflegen.

LLMs können aus Anforderungen und bestehenden Implementierungen strukturierte Modellentwürfe erzeugen. Die formale Sprachdefinition von SysML v2 ermöglicht es, diese Modelle automatisiert auf syntaktische Korrektheit und definierte semantische Regeln zu prüfen.

Damit wird Modellierung plötzlich ein Stück weit zu dem, was wir aus moderner Softwareentwicklung kennen: textbasiert, automatisierbar, versionierbar und in kontinuierliche Entwicklungsprozesse integrierbar. Model as Code!

Natürlich garantiert ein syntaktisch korrektes Modell noch keine korrekte Architektur. Und auch die KI ersetzt keine Engineering-Entscheidung, aber sie kann den manuellen Aufwand für die Formalisierung und Pflege drastisch reduzieren.

Das Teuerste an einem Modell war nie, es einmal zu erstellen, sondern es jeden Tag aktuell zu halten.

Mehr Nutzen, weniger Aufwand

Dass MBSE zu besseren Produkten führt, davon bin ich überzeugt, und zum ersten Mal sehe ich die Chance, dass es sich auch messbar wirtschaftlich lohnt.

Durch den CRA steigt der Nutzen aktueller, nachvollziehbarer Architekturinformationen mit jedem Tag, und das über den gesamten Produktlebenszyklus.

Auf der anderen Seite sinken durch KI und SysML v2 die Kosten, diese Informationen formal zu erfassen, zu prüfen und aktuell zu halten.

Mehr Nutzen. Weniger Aufwand. Und was war mit der Kommunikation?

Formalität und Kommunizierbarkeit laufen auseinander

Unsere Whiteboards und Folien waren natürlich nie formal. Sie waren das, worüber tatsächlich kommuniziert wurde. Ein paar Kästchen, ein paar Pfeile, und alle im Raum wussten, worum es geht: Entwicklung, Produktmanagement, Management, Kunde.

Ein formales Modell leistet das nicht. Je präziser es spezifiziert ist, desto mehr setzt es voraus, dass man seine Sprache beherrscht. Textuelles SysML v2 ist für Menschen lesbar. Aber nicht für alle Menschen.

Je präziser ein Modell wird, desto kleiner wird der Kreis derer, die es verstehen.

Formalität und Kommunizierbarkeit laufen fundamental auseinander. Das eine nützt der Maschine, das andere dem Menschen. Wer eine formale Architektur hat, hat in Wirklichkeit zwei: die präzise im Modell und die verständliche auf der Folie.

Mit genau dem Drift, den wir oben zwischen Modell und Implementierung beschrieben haben.

Dasselbe Synchronisationsproblem. Nur eine Ebene höher.

KI und SysML v2 lösen es nicht. Sie machen formale Modelle billiger, aber nicht verständlicher. Eher im Gegenteil: Wenn Modelle schneller und detaillierter entstehen, wächst der Abstand zu denen, die sie verstehen müssen.

Die Antwort kann nicht sein, dass alle SysML v2 lernen. Sie kann aber auch nicht sein, wieder Folien neben das Modell zu legen. Die Antwort ist, verständliche Diagramme und Sichten direkt aus dem formalen Modell zu generieren. Deshalb haben wir itemis PRISM gebaut.

MBSE mit itemis — von formalen SysML-v2-Modellen bis zu Sichten, die alle Beteiligten verstehen: Systems Engineering →