Das Paper ist älter als Java. Und es beantwortet eine Frage, die sich 2026 jeder stellt: Wer kontrolliert die Architektur, wenn AI-Agenten den Code schreiben?
1995 publizierte Philippe Kruchten „The 4+1 View Model of Architecture“, damals bei Rational Software. Das Paper wurde die Basis für die Softwarearchitektur und prägte später den Rational Unified Process (RUP). Trotzdem kennen es heute viele Entwickler und Architekten nicht mehr. Zeit, das zu ändern.
Als ich den AI Unified Process (AIUP) entworfen habe, baute ich auf der Tradition des Unified Process auf, mit den Use Cases im Zentrum. Kürzlich habe ich das Original-Paper erneut gelesen, und die Übereinstimmung mit dem AI Unified Process ist noch grösser als erwartet. An einigen Stellen beschreibt Kruchten fast wörtlich, was der AI Unified Process heute macht, nur ohne die AI-Agenten.
Dieser Beitrag stellt die 4+1 Sichten kurz vor, ordnet sie den AI Unified Process Artefakten zu und zeigt, was sich seit 1995 geändert hat: Jede Sicht kann heute ausgeführt und verifiziert werden.
Das 4+1 Sichtenmodell in Kürze
Kruchten organisiert eine Softwarearchitektur in fünf parallele Sichten. Jede Sicht adressiert die Anliegen anderer Stakeholder:
- Logical View: Die Funktionalität des Systems aus Sicht der Endbenutzer. Klassisch ein Objektmodell. Für datengetriebene Anwendungen erlaubt Kruchten explizit ein Entity-Relationship-Diagramm als alternative Form.
- Process View: Nebenläufigkeit und Synchronisation. Sie adressiert Performance, Verteilung, Systemintegrität und Fehlertoleranz.
- Development View: Die statische Organisation der Software in der Entwicklungsumgebung. Module, Subsysteme und Layer, dargestellt in Diagrammen mit Import- und Export-Beziehungen.
- Physical View: Das Mapping der Software auf die Hardware. Knoten, Netzwerke und Deployment.
- +1 Scenarios: Eine kleine Auswahl von Use Cases, welche die vier Sichten verbindet. Sie sind redundant zu den anderen Sichten, spielen aber zwei entscheidende Rollen: Sie treiben die Entdeckung der Architekturelemente während des Entwurfs, und sie validieren die Architektur.
Ein Satz im Paper sticht heraus: „The architecture is partially evolved from these scenarios.“ Die Use Cases sind nicht nur Dokumentation. Sie formen die Architektur.
Mapping von 4+1 auf den AI Unified Process
So passen die AIUP-Artefakte in Kruchtens Modell:
| 4+1 Sicht | Zweck nach Kruchten | AIUP-Artefakt | Verifikation |
|---|---|---|---|
| Logical View | Funktionalität aus Endbenutzer-Sicht; Objektmodell oder ER-Diagramm bei datengetriebenen Systemen | Entity Model (Mermaid ER-Diagramm, Attribut-Tabellen, Validierungsregeln) | Flyway-Migrationen und jOOQ-Code-Generierung halten Code und Schema konsistent |
| Development View | Statische Organisation in Module, Subsysteme, Layer; Design-Rule Enforcement | Package- und Komponentenstruktur, Layering-Konventionen der Plugins | ArchUnit-Tests erzwingen Layer- und Abhängigkeitsregeln |
| Process View | Nebenläufigkeit, Verteilung, Fehlertoleranz | Bewusst schlank: Spring Boot und Vaadin geben das Laufzeitmodell weitgehend vor; bei Self-Contained Systems die Kommunikation zwischen den Systemen | Tailoring, wie es Kruchten selbst vorschlägt |
| Physical View | Mapping der Software auf Hardware; Deployment | Deployment-Beschreibung, SCS-Topologie, Container-Setup | Infrastruktur als Code, CI/CD-Pipeline |
| +1 Scenarios | Treiber und Validierung der Architektur; die einzige Sicht, die nie wegfällt | Use Case Diagramm, Use Case Spezifikationen, Test Cases als End-to-End Journeys | Playwright- und Browserless-Tests machen die Use Cases direkt ausführbar |
Drei Details aus dem Original-Paper verdienen einen genaueren Blick.
Das Entity Model ist eine legitime Logical View
Kruchten schreibt, dass bei sehr datengetriebenen Anwendungen ein Entity-Relationship-Diagramm das Objektmodell als Logical View ersetzen kann. Genau das macht der AI Unified Process. Business-Anwendungen sind von Natur aus datengetrieben. Das AI Unified Process Entity Model mit ER-Diagramm, Attribut-Definitionen und Validierungsregeln ist kein Workaround. Es ist eine Form der Logical View, die das Paper explizit gutheisst.
ArchUnit macht die Development View testbar
Die Development View wird durch Modul- und Subsystem-Diagramme beschrieben, die Import- und Export-Beziehungen zeigen. Kruchten formuliert eine Design-Regel: Ein Subsystem darf nur von Subsystemen im gleichen oder in tieferen Layern abhängen. 1995 hat Rational Apex diese Regeln in der Entwicklungsumgebung durchgesetzt.
Heute macht das ArchUnit als Teil der Testsuite. Die Layering- und Abhängigkeitsregeln eines AI Unified Process Projekts sind kein Diagramm auf einer Wiki-Seite. Sie sind Unit-Tests, die den Build brechen, wenn ein AI-Agent oder ein Mensch sie verletzt. Das ist mit AI-gestützter Entwicklung noch wichtiger: Agenten erzeugen Code schnell, also müssen die Leitplanken automatisiert sein.
Eine Abgrenzung noch: Wenn ein Komponenten-Diagramm fachliche Bausteine zeigt, zum Beispiel die Schnitte von Self-Contained Systems, berührt es auch die Logical View. Sobald es um Code-Struktur, Packages und Abhängigkeitsregeln geht, gehört es zur Development View.
Tailoring: Warum die Process View schlank bleiben darf
Kruchten ist pragmatisch, was sein eigenes Modell betrifft. Nicht jede Architektur braucht jede Sicht. Die Physical View kann wegfallen, wenn es nur einen Prozessor gibt, die Process View, wenn es nur einen Prozess gibt. Aber er ergänzt: „The scenarios are useful in all circumstances.“
Das rechtfertigt zwei AI Unified Process Entscheidungen. Erstens bleibt die Process View für typische Spring Boot und Vaadin Anwendungen schlank, weil das Framework das Laufzeitmodell bereits definiert: Thread per Request, Session-Handling, Connection Pooling. Relevant wird die Process View wieder auf Systemebene, wenn Self-Contained Systems miteinander kommunizieren. Zweitens sind die Use Cases das eine Artefakt, das nie optional ist. Sie sind das Zentrum der Methode.
Was sich geändert hat: Von Blueprints zu ausführbaren Sichten
1995 waren die Sichten Blueprints. Dokumente und Diagramme, von Hand gepflegt, die mit der Zeit vom Code wegdrifteten. Das war die fundamentale Schwäche der schwergewichtigen Methoden, und ein Grund, warum die Branche zu agilen Methoden wechselte und dabei viel Architekturdisziplin über Bord warf.
AI-gestützte Entwicklung verändert die Rechnung. Im AI Unified Process hat jede Sicht ein ausführbares Gegenstück:
- Die Scenarios sind die primäre Spezifikation. AI-Agenten implementieren sie, Playwright-Tests verifizieren sie End-to-End. Was Kruchten Redundanz nannte, wird zu Traceability.
- Die Logical View wird durch die Toolchain erzwungen. Flyway-Migrationen definieren das Schema, jOOQ generiert daraus typsicheren Code. Wenn Entity Model und Code auseinanderdriften, bricht der Build.
- Die Development View wird durch ArchUnit erzwungen.
- Die Physical View ist Code: Pipeline-Definitionen und Infrastruktur-Konfiguration.
Die Sichten sind nicht mehr Beschreibungen des Systems. Sie sind Teil des Systems.
Dieselbe Tradition, einen Schritt weiter
Der AI Unified Process steht bewusst in der Tradition von Kruchten, Jacobson und dem Unified Process. Der szenariogetriebene, iterative Ansatz, den Kruchten im Paper beschreibt, also Szenarien nach Risiko und Kritikalität auswählen, gegen eine Strawman-Architektur durchspielen, implementieren, messen und iterieren, ist auch der Kern-Loop von AI Unified Process.
Der Unterschied liegt darin, wer die Arbeit in jeder Iteration macht. 1995 zeichneten Architekten Blueprints und Entwickler implementierten sie. 2026 sind die Spezifikationen präzise genug, dass AI-Agenten sie implementieren, und die Sichten selbst sind zu Tests geworden, die alle ehrlich halten.
Spec-Driven Development ist kein Bruch mit bewährter Softwarearchitektur. Es bringt sie ins AI-Zeitalter.
Referenzen
- Philippe B. Kruchten, „The 4+1 View Model of Architecture“, IEEE Software, November 1995
- AI Unified Process: unifiedprocess.ai
