4+1 Architectural View Model
History of 4+1 Architectural View Model
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 organize the description of a software architecture using a set of concurrent ‘views’, each addressing specific concerns, for specific stakeholders.
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?
Introduction
Have you ever worked on a microservices system experiencing challenges like these?
- I’ve separated my system into loosely coupled microservices — why is integration between them still so hard? I’m spending all my time implementing circuit breakers, bulkheads & retry patterns when I’d rather be writing business logic!
- My autonomous microservices teams are still blocking each other from delivery — why?
- We still struggle with version incompatibilities between microservices… we’ve had to invest heavily in consumer driven contract testing to ensure we don’t break things
- Making an update is so hard — we have to update code in multiple repositories containing our shared libraries and wait for a nuget or npm publish cycle in each of them before we can test the integration of changes
Or perhaps you’re a startup who doesn’t want to over-engineer their launch solution, but also doesn’t want to end up with a big ball of mud, or unable to scale their system when the business starts doing well?
Either way — the “4 + 1 Architectural Views” may help.
This is the first in a series of posts about the views. Throughout the series, I hope to demonstrate how useful the 4 + 1 Views can be in understanding complex distributed systems, as well as facilitating more nuanced approaches to system design.
This first post will provide a brief introduction to each of the views, with deep dives into each view coming soon.
The Views
The “4 + 1 Architectural Views” were proposed in 1995 to solve increasing challenges communicating about software architectures.
The purpose of separating the architecture into multiple concurrent views was to isolate and illustrate different aspects of the design with information specifically oriented towards different stakeholders.
Each view should:
- define the system in terms of Components, Connectors and Containers
- use appropriate styles, forms and patterns for each view
- consider applicable constraints in each view
- consider the relationship between the views
For any given system, you may not need to document all the views, and there may be other, more relevant views for your system. I recommend creating the minimal documentation to explain architectural decisions, and ensure you are ready and willing to evolve your architecture (in each of the views) as your solution matures.
Logical View
The logical view illustrates how the system is decomposed into specific areas of functionality. You will likely need to diagram the system at various levels of abstraction.
If you are using Domain Driven Design (DDD) then at the highest level (the most abstract) you might show domains, sub-domains and bounded contexts and the flow of events between them. In the Domain Blue Book 2, this is called the ‘context map’. At the lowest level (the most concrete), you might illustrate aggregates, aggregate roots, entities and relationships.
However, DDD is not the only way to design software — for some systems it may be better to illustrate functional modules, perhaps with a simple entity-relationship diagram.
Deep dive into the Logical View: coming soon…
Process View
The process view gets us to closer to an illustration of running software. Components in the process view are real executables that make up the run-time of your system.
For example, each of the following would be considered a ‘process’:
- IIS Web Application Pool
- Single-page app running in a browser
- Linux Daemon
- Database engine running stored procedures or SQL scripts
- etc.
Processes can be thought of as a unit of ‘tactical control’. An individual process can be deployed, started, recovered, reconfigured, scaled out, and shutdown.
The purpose of the process view is to start to capture both the flow of inter-process information exchange (e.g. REST API calls, messaging via a bus) and the sequence and timing of these inter-process communications. This allows us to consider questions such as concurrency and reliability.
Deep dive into the Process View: coming soon…
Physical View
Even with the advent of Cloud computing and virtualised hardware, the physical architecture view still plays a critical role in understanding system performance and capacity.
Components are either processing nodes (servers, virtual machines, docker containers, serverless configurations, etc.) or networking channels (routers, firewalls, proxies, load balancers, etc.) and the diagram should illustrate which nodes host which processes from the process view. This allows us to start considering compute and network capacity, as well as latency and other performance considerations.
Deep dive into the Physical View: coming soon…
Development View
I often think about the development view as the “source code” view. As such, you can consider it as having two ‘sub-views’, or perspectives:
- Physical perspective, comprised of:
- repositories
- file systems
- IDE projects/solutions & structure (e.g. Visual Studio Solutions)
The physical perspective helps you ‘find’ the code. There is a concept of ‘nearness’ which can be helpful when considering what code you want to keep ‘near’ what other code to enhance cohesion.
- Logical perspective, comprised of:
- modules (e.g. assemblies, packages)
- dependencies between modules
- layering of modules
The logical perspective helps you understand how the code modules work together. It allows you to understand static dependencies between the modules, as well as the flow of execution through the actual source code. This should help with understanding a run-time model — i.e. which modules will execute within which processes in the process view.
Deep dive into the Development View: coming soon…
Scenario/Use Case View
The scenario, or ‘use case’ view helps tie the architecture together. Different diagrams help to illustrate the flow of activity in a system and illustrate which logical, process, physical and development components are working together to facilitate the outcome.
Deep dive into the Scenario/Use Case View: coming soon…
Why should I care?
In this series of posts, I hope to demonstrate that many challenges facing teams today are a consequence of blending and ignoring the distinctions between the views — trying to solve problems in one view with design patterns in a different view, or by tightly aligning the design in each view. My experience is that if you allow yourself to evolve your solution in each view independently, many of these challenges become much easier to reason about.
This means you can plan ahead to scale appropriately, you can more easily trace performance or scalability issues back to the source, and you can understand why different teams (owning different components in the development view) have complex developer-time interactions affecting autonomy and progress.
After exploring each of the views in depth in the coming posts, we’ll return to this idea in more detail and explore how specific view alignment (or mis-alignment) patterns cause common risks and challenges.
References
Wikipedia :
Devcycles :
