{"slug": "a-paper-from-1995-describes-how-you-should-work-with-ai-agents", "title": "A Paper from 1995 Describes How You Should Work with AI Agents", "summary": "Philippe Kruchten's 1995 paper 'The 4+1 View Model of Architecture' remains relevant for designing systems with AI agents, according to a new analysis that maps its views to the AI Unified Process (AIUP). The paper's use-case-driven approach now enables every architectural view to be executed and verified through modern tools like Flyway, ArchUnit, and Playwright.", "body_md": "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?\n\nIn 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.\n\nWhen 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.\n\nThis 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.\n\n## A Quick Recap of the 4+1 View Model\n\nKruchten organizes a software architecture into five concurrent views. Each view addresses the concerns of different stakeholders:\n\n**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.\n\nOne 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.\n\n## Mapping 4+1 to the AI Unified Process\n\nHere is how the AIUP artifacts fit into Kruchten’s model:\n\n| 4+1 View | Purpose (Kruchten) | AIUP Artifact | Verification |\n|---|---|---|---|\nLogical 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 |\nDevelopment 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 |\nProcess 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 |\nPhysical View | Mapping of software onto hardware; deployment | Deployment description, SCS topology, container setup | Infrastructure as code, CI/CD pipeline |\n+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 |\n\nThree details from the original paper deserve a closer look.\n\n## The Entity Model Is a Legitimate Logical View\n\nKruchten 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.\n\n## ArchUnit Makes the Development View Testable\n\nThe 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.\n\nToday, 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.\n\nOne 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.\n\n## Tailoring: Why the Process View May Stay Lean\n\nKruchten 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.”\n\nThis 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.\n\n## What Has Changed: From Blueprints to Executable Views\n\nIn 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.\n\nAI-assisted development changes the equation. In the AI Unified Process, every view has an executable counterpart:\n\n- The\n**scenarios** are the primary specification. AI agents implement them, and Playwright tests verify them end to end. What Kruchten called redundancy becomes traceability. - The\n**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\n**development view** is enforced by ArchUnit. - The\n**physical view** is code: pipeline definitions and infrastructure configuration.\n\nThe views are no longer descriptions of the system. They are part of the system.\n\n## The Same Tradition, One Step Further\n\nThe 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.\n\nThe 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.\n\nSpec-Driven Development is not a break with proven software architecture. It brings it into the AI age.\n\n## References\n\n- Philippe B. Kruchten, “The 4+1 View Model of Architecture”, IEEE Software, November 1995\n- AI Unified Process:\n[unifiedprocess.ai](https://unifiedprocess.ai/)", "url": "https://wpnews.pro/news/a-paper-from-1995-describes-how-you-should-work-with-ai-agents", "canonical_source": "https://martinelli.ch/a-paper-from-1995-describes-how-you-should-work-with-ai-agents/", "published_at": "2026-08-17 09:56:39+00:00", "updated_at": "2026-09-02 08:52:06.028141+00:00", "lang": "en", "topics": ["ai-agents"], "entities": ["Philippe Kruchten", "Rational Software", "AI Unified Process", "Spring Boot", "Vaadin", "Flyway", "ArchUnit", "Playwright"], "alternates": {"html": "https://wpnews.pro/news/a-paper-from-1995-describes-how-you-should-work-with-ai-agents", "markdown": "https://wpnews.pro/news/a-paper-from-1995-describes-how-you-should-work-with-ai-agents.md", "text": "https://wpnews.pro/news/a-paper-from-1995-describes-how-you-should-work-with-ai-agents.txt", "jsonld": "https://wpnews.pro/news/a-paper-from-1995-describes-how-you-should-work-with-ai-agents.jsonld"}}