History of the 4 + 1 Architectural View Model
February 28, 2019
This post explores the history and legacy of the 4 + 1 views. See 4 + 1 Architectural View Model: Introduction for the more technical overview.
Origin Story
In 1995, Philippe Kruchten was working at Rational Software Corp, at the time the pre-eminent vendor of software development tools.
With years of experience designing large scale complex software systems across telecommunications, aerospace, transport and defense, he had observed that software architecture diagrams often failed to provide clarity as to the actual system design. It was frequently confusing as to what the boxes, lines and arrows really represent, and stakeholders struggled to discover the information they needed.
He proposed a solution in a paper published that year - Architectural Blueprints—The “4+1” View Model of Software Architecture - to organise the description of a software architecture using a set of concurrent 'views', each addressing specific concerns, for specific stakeholders.
Historical Context
Comparisons between software architecture and the architecture of buildings have been made since at least 1968, when the Nato Science Committee sponsored a Working Conference on Software Engineering. Amongst many other topics the attendees discussed how to discover the "right attitude to design". Peter Naur (the "N" in BNF) suggested:
software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem.
The following decades contained numerous efforts to grapple with the large scale design of software systems with many foundational principles proposed and refined, but applied sporadically.
It was only in the early 1990s that the term "Software Architecture" came to the fore. In 1992 Dewayne Perry and Alexander Wolf published "Foundations for the study of Software Architecture":
The 1990s, we believe, will be the decade of software architecture. We use the term "architecture", in contrast to "design", to evoke notions of codifcation, of abstraction, of standards, of formal training (of soft-ware architects), and of style.
So it was in the context of a discipline with decades of development, but only nascent formalisation, that Kruchten proposed his 4 + 1 views.
It's no surprise given the historical analogues with building architecture that he would refer to the views as blueprints.
Legacy
In 1996, Kruchten was appointed the Director of Process at Rational Software where he led the development of the "Rational Unified Process" (RUP). The 4 + 1 views are a key concept in the RUP section on Analysis and Design.
While Kruchten was working at Rational, his colleagues were tackling the challenge of communicating about software on a different tack - the outcome was the Unified Modelling Language (UML).
The 4 + 1 views are a generic approach that does not prescribe any specific notation or diagramming structure (although Booch notation is used in the paper); UML fills in the blanks with prescriptive definitions of how to notate certain types of diagrams. Although the 4 + 1 views are not specifically referenced in UML, the intention of the RUP was that it would work in concert with UML as the notation for diagrams. It seems no coincidence and there is a neat alignment with the 4 + 1 views, with many UML diagrams being well suited for use in a specific view.
These days the 4 + 1 views are rarely utilised - technology and tech culture have moved on.
Where did the 4 + 1 views go?
Perhaps the fledgling rumblings of Service-Oriented Architecture (SOA) in 1998 heralded the end? In the context of Kruchten's paper, systems were large complex beasts with often custom implementations of both hardware and software. The rise of SOA aligned with the web as the communications medium of choice, the adoption of commodity hardware, and increased search for 're-usable' components (often pre-packaged components from vendors). It's possible that engineers started to see less value in explicitly documenting the separate views.
Or perhaps it was the rise of Extreme Programming (XP) and Agile? They have paved the way for a new kind of development process, one which eschews heavy formal frameworks like RUP (although Kruchten maintains that RUP is agile-compatible). Were the 4 + 1 views the baby thrown out with the bathwater?
