Nexus V: Eine neue, entscheidungszentrierte Sicht auf das V‑Modell in regulierten Industrien

Wenn wir in Automotive, Medizintechnik oder Luftfahrt über Entwicklung sprechen, landen wir früher oder später beim V‑Modell. Gleichzeitig arbeiten unsere Teams längst agil, iterativ, verteilt und datengetrieben. Das Ergebnis kennen viele von uns nur zu gut:

Water-Scrum-Fall. Spezifikationen, die am Anfang Hochglanz bekommen und dann veralten. Traceability als Pflichtübung. Architekturentscheidungen, die in Meetings getroffen und danach nie wieder gefunden werden. Audits, die sich anfühlen wie ein eigenes Projekt neben dem Projekt.

Genau in diesem Spannungsfeld ist Nexus V entstanden: eine alternative Interpretation des V‑Modells für regulierte Umfelder, gespeist aus bekannten Bausteinen und bewusst neuen Entscheidungen.

Was ist Nexus V in einem Satz?

Nexus V liest das V‑Modell als Ontologie des Systemwissens.

Mit Ontologie meine ich hier: eine explizite Beschreibung, welche Arten von Systemwissen es gibt (zum Beispiel Anforderungen, Funktionen, Komponenten, Risiken, Tests) und wie diese Wissenselemente zusammenhängen.

Artefakte, Tests, Risiken und Code bilden in Nexus V einen gemeinsamen Wissensgraphen. Die Verbindungen in diesem Graphen tragen Traces, Entscheidungen und Verträge. Genau dieses Geflecht ist der Nexus – der Knotenpunkt, an dem das Systemwissen zusammenläuft. Daher der Name.

Der Kern von Nexus V in fünf Punkten

Bevor ich in die Details gehe, hier die fünf Eckpunkte, die Nexus V ausmachen:

1. Traceability als Entscheidungs- und Vertragsnetz Traces werden zu Trägern von Entscheidungen, Kontext und Commitments.
2. Arbitrierung als zentrale Aktivität Jeder neue Zusammenhang im V repräsentiert eine bewusste Abwägung zwischen Optionen. Entscheidung und Trace gehören untrennbar zusammen.
3. Rhizomatisches V mit Anchor Points Projekte starten an realen Ankerpunkten wie Legacy, Technologie, Normen oder Features. Das V verdichtet sich von dort aus, statt idealisiert von links nach rechts zu laufen.
4. Governance über einen Wissensgraphen Der Nexus Steward verantwortet die Integrität des Entscheidungsgraphen.
5. Continuous Compliance als emergente Eigenschaft Auditfähigkeit entsteht als Sicht auf denselben Nexus, der die Entwicklung steuert.

Diese fünf Aspekte sind alle einzeln anschlussfähig an vorhandene Praktiken. Das wirklich Neue entsteht im Zusammenspiel.

Warum ich eine neue Sicht auf das V‑Modell gesucht habe

Ich arbeite seit vielen Jahren in regulierten Umfeldern wie der Automobilindustrie. Die Muster wiederholen sich:

• Spezifikationen werden mit hohem Aufwand erstellt und verlieren im Projektverlauf den Anschluss an die Realität. Ich nenne das gern Spec Fiction.
• Traceability wird aufgebaut, weil Normen und Assessments es verlangen. Im Alltag nutzt sie kaum jemand aktiv. Es entsteht ein Datenfriedhof.
• Architekturentscheidungen entstehen in Workshops, finden ihren Weg in Folien und Mails und sind danach für neue Teammitglieder praktisch unsichtbar.
• Das System verändert sich schleichend durch neue Anforderungen, Workarounds und Plattformzwänge. Die Architektur erodiert langsam im Hintergrund. Das ist der Silent Decay der Architektur.

Wir haben darauf mit vielen sinnvollen Einzelbausteinen reagiert:

• MBSE und SysML, um Systemstruktur und Verhalten modellbasiert zu erfassen
• Architecture Decision Records, um wichtige Entscheidungen explizit zu dokumentieren
• Test Driven Development und Contract Based Design, um Tests als Verträge an Systemgrenzen zu definieren

Alle diese Elemente sind wertvoll. Aber sie bleiben oft nebeneinander stehen:

• Das MBSE‑Modell lebt in einem Tool.
• ADRs liegen in einem Repo oder Wiki.
• Tests und Testfälle leben in Testmanagement und CI.
• Traceability steckt im ALM.

Was fehlt, ist eine integrierte Sicht, die all das als ein System begreift.

Genau hier setzt Nexus V an.

V‑Modell als Ontologie des Systemwissens

Der erste Perspektivwechsel ist vielleicht der wichtigste:

Statt das V‑Modell als Abfolge von Phasen zu lesen, betrachte ich es als Ontologie des Systemwissens – also als strukturiertes Bild davon, welche Wissensarten in der Entwicklung existieren und wie sie sich gegenseitig beeinflussen.

• Links im V stehen bestimmte Wissensarten: Stakeholderziele, Anforderungen, Risiken, Sicherheitsargumente.
• In der Mitte stehen Struktur- und Verhaltensentscheidungen, Architektur, Design, Partitionierung.
• Rechts stehen Verifikations- und Validierungsartefakte, Tests, Nachweise, Berichte.

Dieses Wissen lebt über den gesamten Lebenszyklus. Die Frage ist:

Wie modellieren wir dieses Wissen so, dass es zusammenhängend, durchsuchbar, nachvollziehbar und auditierbar wird?

Die Antwort von Nexus V ist: Als Wissensgraph aus Knoten und Kanten.

• Knoten sind Artefakte: Anforderungen, Funktionen, Komponenten, Risiken, Tests, Releases, Entscheidungen.
• Kanten sind Beziehungen, zum Beispiel: „erfüllt“, „realisiert“, „absichert“, „begründet“, „erbt von“, „steht im Widerspruch zu“.

Bis hierhin könnte man sagen: Das erinnert an Digital Thread oder Knowledge Graph. Der entscheidende Schritt kommt jetzt.

Traceability als Entscheidungs‑ und Vertragsnetz

In den meisten Organisationen sind Traces passive Metadaten: A ist mit B verlinkt, weil es ein Prozess verlangt.

In Nexus V sind Traces aktive Objekte:

• Ein Trace steht für eine Entscheidung. Zum Beispiel: Diese Anforderung wird durch diese Funktion realisiert.
• Er verkörpert einen Vertrag zwischen Artefakten. Zum Beispiel: Diese Architekturkomponente verpflichtet sich, dieses Verhalten bereitzustellen, das durch diese Tests abgesichert wird.

An die Kante gehören Informationen wie:

• Welche Optionen wurden betrachtet?
• Warum wurde genau diese Verbindung gewählt?
• Welche Annahmen gelten?
• Wer hat dem zugestimmt und wann?

Damit wird aus der klassischen Aussage „Requirement A ist getraced auf Test B“ die reichere Aussage:

Wir haben entschieden, dass Requirement A durch Designoption X umgesetzt und durch Test B abgesichert wird. Die Entscheidung fiel aus Gründen 1, 2 und 3. Diese Personen haben zugestimmt.

Traceability wird damit zum Entscheidungs- und Vertragsnetz, weit über die Liste von Linien im Tool hinaus.

Rhizomatisches V und Anchor Points

Die zweite wichtige Beobachtung: Kaum ein Projekt startet wirklich so, wie das klassische V es suggeriert.

In der Realität beginnen Systeme an Anchor Points:

• ein bestehendes Steuergerät oder eine Plattform
• eine neue Technologie, die gesetzt ist
• eine harte regulatorische Forderung
• ein besonders kritischer Use Case oder Safety Hazard
• ein schon vorhandener Integrations- oder Systemtest

Das Wissen ist fragmentiert. Es gibt Inseln mit viel Inhalt und Lücken dazwischen.

Hier hilft das Bild des rhizomatischen Wachsens: Ein Rhizom ist ein Wurzelgeflecht, das sich verzweigt, ohne eine zentrale Stammstruktur zu haben. Übertragen auf Systementwicklung bedeutet das:

• Der Nexus entsteht um diese Anchor Points herum.
• Neue Artefakte werden ergänzt, Lücken geschlossen, Zusammenhänge im Entscheidungsgraph verdichtet.
• Das V wächst als Struktur aus echten Wissensinseln heraus.

Das ist ein anderer Anspruch als: „Wir müssen am Anfang alles vollständig beschreiben, sonst geht es nicht weiter.“

Stattdessen lautet die Frage:

Wo ist unser aktueller Nexus am dichtesten, wo sind wir blind und welche Entscheidungen fehlen dort?

Arbitrierung und Decision Records

Wenn Traces Verträge sind, brauchen wir ein klares Objekt für die Entscheidung selbst:

Das sind die Decision Records im Nexus.

Ein Decision Record umfasst typischerweise:

• Kontext
• betrachtete Optionen
• Kriterien und Bewertung
• gewählte Option und Begründung
• betroffene Artefakte im Nexus
• Beteiligte und Commitment

Wichtig ist die Kopplung:

• Decision Records sind direkt mit den verbindenden Kanten der Artefakte verknüpft.

Jede neue Verbindung im V wird damit zu einer Arbitrierung. Mit Arbitrierung meine ich hier eine bewusste, strukturierte Abwägung mit dokumentierter Wahl und nachvollziehbarer Begründung.

• Wir wägen Anforderungen, Risiken, Kosten, Termine und technische Zwänge ab.
• Wir treffen eine Entscheidung.
• Wir manifestieren sie im Nexus.

Arbitrierung wird damit von einer impliziten Aktivität in Meetings zu einem sichtbaren, wiederkehrenden Muster in der Entwicklung.

Governance über den Nexus: Die Rolle des Nexus Stewards

Wenn der Nexus ein Entscheidungsgraph ist, stellt sich die Frage: Wer achtet auf seine Qualität?

Hier kommt die Rolle des Nexus Stewards ins Spiel.

Der Nexus Steward ist weder klassischer Projektleiter noch reiner Systems Engineer. Er oder sie:

• definiert und pflegt die Ontologie des Nexus,
• moderiert wichtige Arbitrierungen,
• achtet darauf, dass Decision Records konsistent, verständlich und auffindbar sind,
• beobachtet, wo der Nexus Löcher, Inseln oder Widersprüche hat.

Governance findet damit auf der Ebene der Beziehungen statt:

• Die Leitfrage lautet: „Ist die Entscheidung, die dieses Dokument implizit behauptet, im Nexus verankert und nachvollziehbar?“

In regulierten Umfeldern ist das besonders wertvoll, weil viele Normen Inhalt und nachvollziehbare Entscheidungen verlangen.

Continuous Compliance als Sicht auf denselben Nexus

Auch wenn ich in diesem Artikel bewusst nicht in ROI-Rechnungen gehe, ist ein Punkt konzeptionell wichtig:

In vielen Organisationen gibt es faktisch zwei Welten:

1. die Welt der Entwicklungsteams, in der gearbeitet wird
2. die Welt der Audits, Assessments und Safety Cases, in der nachträglich geordnet wird

Nexus V versucht diese Trennung aufzulösen, indem:

• Entwicklungsarbeit und Entscheidungsdokumentation im selben Wissensgraph stattfinden,
• Nachweise, Argumentationsketten und Assessments als Sichten auf denselben Nexus erscheinen.

Compliance bleibt streng und wird zugleich integrierter:

Continuous Compliance ist eine emergente Eigenschaft eines gut gepflegten Nexus, nicht ein Sonderzustand am Projektende.

Für mich ist das ein wichtiger Teil der neuen Interpretation des V‑Modells in regulierten Industrien.

Warum das einen eigenen Namen verdient

Ist das alles komplett neu? Nein. Und das ist mir wichtig zu betonen.

Nexus V baut bewusst auf bekannten Konzepten auf:

• V‑Modell in regulierten Umfeldern
• MBSE und SysML
• Architecture Decision Records
• Test Driven Development und Contract Based Design
• Traceability, wie sie viele Normen und Reifegradmodelle fordern

Das Neue entsteht dadurch, dass ich diese Elemente als System begreife:

• das V als Ontologie des Systemwissens
• Traces als Träger von Entscheidungen und Verträgen
• Arbitrierung als explizite, wiederkehrende Aktivität
• ein Wissensgraph, über den Governance betrieben wird
• Continuous Compliance als Sicht auf denselben Nexus

Wenn sich die Interaktionen ändern, entsteht ein neues Verhalten des Gesamtsystems. Genau das beobachte ich in der konzeptionellen Arbeit an Nexus V.

Darum habe ich mich entschieden, diesem Ansatz einen eigenen Namen zu geben:

Nexus V als Bezeichnung für eine integrierte, entscheidungszentrierte Sicht auf das V‑Modell in regulierten Industrien.

Einladung zum Austausch

Dieser Artikel gibt einen ersten Einblick in mein Denken zu Nexus V und markiert einen Standpunkt für die weitere Ausarbeitung:

• Wir müssen in regulierten Umfeldern nicht alles neu erfinden.
• Wir können bestehende Konzepte so miteinander verknüpfen, dass ein neues Ganzes entsteht.
• Dieses Ganze stellt Entscheidungen, Verträge und ihren Kontext in den Mittelpunkt.

Wenn du in einem Umfeld arbeitest, in dem V‑Modell, Normen, Safety, Traceability und Agilität miteinander ringen, dann interessiert mich deine Sicht:

• Wo erkennst du diese Muster wieder?
• Wo stellst du dir einen entscheidungszentrierten Ansatz hilfreich vor?
• Welche Erfahrungen hast du mit ähnlichen Konzepten gemacht?

Schreib mir gern eine Nachricht. Nexus V ist für mich ein Praxisrahmen, der mit jeder Anwendung besser wird.