4+1 Architectural Views
Kruchten's logical, process, development, physical, and scenario views of architecture.
The 4+1 Architectural Views model was articulated by Philippe Kruchten of Rational Software in his 1995 paper 'Architectural Blueprints — The 4+1 View Model of Software Architecture' (IEEE Software). The model holds that no single diagram or view can adequately describe a non-trivial software architecture, and that architects should produce four primary views serving different stakeholders, plus a fifth 'scenarios' view that ties them together. The Logical View (end-user concerns, the system's functional structure, conceptual classes); the Process View (system designer concerns, concurrency, performance, distribution, runtime processes); the Development View (programmer concerns, module organization, packaging); the Physical View (system engineer concerns, deployment, hardware, network topology); and the Scenarios View (the +1, often called Use Cases or Use Case View, illustrating how the other four views work together for representative scenarios). The model was substantially shaped by and influential within the Rational Unified Process (RUP) and remains a reference framework in software-architecture education, though its UML-era detail conventions feel dated relative to lighter-weight modern alternatives like the C4 Model.
Core components
- Four primary views: Logical (functional structure, classes), Process (concurrency, distribution, runtime), Development (module organization, packaging), Physical (deployment, hardware)
- Scenarios view (the +1, ties views together via use cases)
- Each view serves different stakeholders
- Connection to UML and Rational Unified Process
- Substantial influence on subsequent architectural-views frameworks
Primary use case
Software architecture documentation in enterprise and large-system contexts; teaching framework in software-architecture education; basis for architectural views structure that influenced many subsequent frameworks (including ISO/IEC/IEEE 42010 — Systems and Software Engineering — Architecture Description); reference in IBM Rational Unified Process and similar enterprise methodologies.
Common criticisms
- UML-era detail conventions feel heavy relative to modern lighter-weight alternatives like C4 Model
- production of all five views in detail is rarely done in practice — most projects produce one or two views adequately and the rest as afterthought or not at all
- views can become snapshots rather than living documentation, going stale rapidly
- 1995 framing predates microservices, cloud-native, event-driven, and serverless architectures, making some view definitions awkward for modern systems
- formal RUP-style architecture-description practice has substantially declined in favor of lighter-weight architecture-as-code approaches
- framework's strength is conceptual rather than operational — useful as a thinking tool, less useful as a documentation prescription.
Lineage
- Siblings
- C4 Model