The paper is older than Java. And it answers a question everyone is asking in 2026: Who guards the architecture when AI agents write the code?
In 1995, Philippe Kruchten published “The 4+1 View Model of Architecture” while working at Rational Software. It became one of the most influential papers in software architecture and later shaped the Rational Unified Process (RUP). Still, many developers and architects today have never heard of it. Time to change that.
When I designed the AI Unified Process (AIUP), I built on the Unified Process tradition, with use cases at the center. Recently I reread the original paper, and the match with the AI Unified Process is even closer than I expected. In some places, Kruchten describes almost word for word what the AI Unified Process does today, just without the AI agents.
This post gives a short introduction to the 4+1 views, maps them to AI Unified Process artifacts, and shows the one thing that has fundamentally changed since 1995: every view can now be executed and verified.
A Quick Recap of the 4+1 View Model
Kruchten organizes a software architecture into five concurrent views. Each view addresses the concerns of different stakeholders:
- Logical View: The functionality of the system from the end user’s perspective. Classically an object model. For data-driven applications, Kruchten explicitly allows an entity-relationship diagram as an alternative form.
- Process View: Concurrency and synchronization. It addresses performance, distribution, system integrity, and fault tolerance.
- Development View: The static organization of the software in the development environment. Modules, subsystems, and layers, shown in diagrams with import and export relationships.
- Physical View: The mapping of the software onto hardware. Nodes, networks, and deployment.
- +1 Scenarios: A small set of use cases that tie the four views together. They are redundant with the other views, but they play two critical roles: they drive the discovery of architectural elements during design, and they validate the architecture.
One sentence in the paper stands out: “The architecture is partially evolved from these scenarios.” The use cases are not just documentation. They shape the architecture.
Mapping 4+1 to the AI Unified Process
Here is how the AIUP artifacts fit into Kruchten’s model:
| 4+1 View | Purpose (Kruchten) | AIUP Artifact | Verification |
|---|---|---|---|
| Logical View | Functionality from the end user’s view; object model or ER diagram for data-driven systems | Entity model (Mermaid ER diagram, attribute tables, validation rules) | Flyway migrations and jOOQ code generation keep code and schema consistent |
| Development View | Static organization in modules, subsystems, layers; design-rule enforcement | Package and component structure, layering conventions of the plugins | ArchUnit tests enforce layer and dependency rules |
| Process View | Concurrency, distribution, fault tolerance | Deliberately lean: Spring Boot and Vaadin define most of the runtime model; for Self-Contained Systems, the communication between systems | Tailoring, as Kruchten suggests |
| Physical View | Mapping of software onto hardware; deployment | Deployment description, SCS topology, container setup | Infrastructure as code, CI/CD pipeline |
| +1 Scenarios | Driver and validation of the architecture; the only view that never gets omitted | Use case diagram, use case specifications, test cases as end-to-end journeys | Playwright and Browserless tests make the use cases directly executable |
Three details from the original paper deserve a closer look.
The Entity Model Is a Legitimate Logical View
Kruchten writes that for very data-driven applications, an entity-relationship diagram can replace the object model as the logical view. That is exactly what the AI Unified Process does. Business applications are data-driven by nature. The AI Unified Process entity model, with its ER diagram, attribute definitions, and validation rules, is not a workaround. It is a form of the logical view that the paper explicitly endorses.
ArchUnit Makes the Development View Testable
The development view is described through module and subsystem diagrams that show import and export relationships. Kruchten formulates a design rule: a subsystem may only depend on subsystems in the same or lower layers. In 1995, Rational Apex enforced these rules in the development environment.
Today, ArchUnit does this as part of the test suite. The layering and dependency rules of an AIUP project are not a diagram on a wiki page. They are unit tests that fail the build when an AI agent, or a human, violates them. This matters even more with AI-assisted development: agents generate code fast, so the guardrails must be automated.
One clarification: if a component diagram shows business building blocks, for example the cuts of Self-Contained Systems, it also touches the logical view. As soon as it is about code structure, packages, and dependency rules, it belongs to the development view.
Tailoring: Why the Process View May Stay Lean
Kruchten is pragmatic about the model itself. Not every architecture needs every view. You can drop the physical view if there is only one processor, or the process view if there is only one process. But he adds: “The scenarios are useful in all circumstances.”
This justifies two AI Unified Process decisions. First, the process view stays lean for typical Spring Boot and Vaadin applications, because the framework already defines the runtime model: thread per request, session handling, connection pooling. The process view becomes relevant again at the system level, when Self-Contained Systems communicate with each other. Second, the use cases are the one artifact that is never optional. They are the center of the method.
What Has Changed: From Blueprints to Executable Views
In 1995, the views were blueprints. Documents and diagrams, maintained by hand, drifting away from the code over time. That was the fundamental weakness of heavyweight methods, and one reason the industry moved to agile and threw much of the architecture discipline overboard.
AI-assisted development changes the equation. In the AI Unified Process, every view has an executable counterpart:
- The scenarios are the primary specification. AI agents implement them, and Playwright tests verify them end to end. What Kruchten called redundancy becomes traceability.
- The logical view is enforced by the toolchain. Flyway migrations define the schema, jOOQ generates type-safe code from it. If the entity model and the code drift apart, the build breaks.
- The development view is enforced by ArchUnit.
- The physical view is code: pipeline definitions and infrastructure configuration.
The views are no longer descriptions of the system. They are part of the system.
The Same Tradition, One Step Further
The AI Unified Process deliberately stands in the tradition of Kruchten, Jacobson, and the Unified Process. The scenario-driven, iterative approach that Kruchten describes in the paper, selecting scenarios by risk and criticality, scripting them against a strawman architecture, implementing, measuring, and iterating, is the core loop of the AI Unified Process as well.
The difference is who does the work in each iteration. In 1995, architects drew blueprints and developers implemented them. In 2026, the specifications are precise enough that AI agents implement them, and the views themselves have become tests that keep everyone honest.
Spec-Driven Development is not a break with proven software architecture. It brings it into the AI age.
References
- Philippe B. Kruchten, “The 4+1 View Model of Architecture”, IEEE Software, November 1995
- AI Unified Process: unifiedprocess.ai
