4+1 Architectural View Model

The 4+1 view model, published by Philippe Kruchten in IEEE Software in 1995, describes a software architecture through four concurrent views plus a set of scenarios that tie them together. Its premise is that one diagram cannot serve every stakeholder, because different readers are asking different questions.

The four views divide as follows. The logical view is organized around the functionality the system provides. The process view addresses concurrency and distribution, and with them performance and availability. The development view describes how the software is organized into modules in the development environment. The physical view maps software onto processing nodes and is shaped mainly by non-functional requirements — what this site calls quality requirements.

The “+1” is scenarios — selected use cases traced through the other four. They are the consistency check: a scenario that cannot be followed across the views usually reveals that one of them is wrong or that a part is missing.

Thirty years on, the notation is less used than the distinction it made. The durable point is that what the parts are and what they are responsible for is a different description from where instances of them run. Folding both into one diagram is how a design can be logically sound and still violate a residency rule, or be redeployed without any change to its logical structure.

Later notations draw the same boundary in lighter form. The C4 model separates container diagrams from deployment diagrams for the same reason, which is a good sign that the separation was the substance rather than the diagrams.

How these views fit alongside a third description — who operates each part — is worked through in Architecture Levels and the Scope of a Decision.