25 years ago Philippe Krutchen published an article in the IEEE Software magazine describing a different way to interpret and communicate software architecture. He used complex systems like air traffic control systems and phone systems in his example because those were the big, complex systems that needed this understanding at that time.
For some context, in 1995…
- Netscape introduced JavaScript.
- Netscape Navigator completely dominated the web browser market.
- Microsoft launched Internet Explorer 1.
- Microsoft released Windows 95. Most people were using Win 3.1 or 3.11 at the time.
- Sun announced Java.
- Linus Torvalds released version 1.2.0 of the Linux kernel (a.k.a. Linux 95).
Today, thanks to cloud computing and the internet any system can be a complex system and it’s import that we find good ways to understand and communicate our systems.
Why care about the 4+1 view model of software architecture?
It is hard to design and it is hard to describe many computer programmer-y things because they are more than just physical things. Many of the most difficult things to learn and to design are just abstract things that can be understood differently by different people.
We will consider an example using 3 programmers. We have Skylar who is new to programming, Bailey who is a little more experienced then Skylar and Nika who has the most experience. Nika never goes by Nik and these 3 people characters are in no way representative of people who I may know or be.
Skylar’s understanding of a Concept looks like a circle and Skylar is having a really tough time understanding and using the Concept. Skylar goes to Bailey for help. Bailey’s understanding of the Concept comes from a completely different approach but it’s definitely the same concept that Skylar is struggling with.
Bailey understands the concept as a rectangle and tells Skylar to consider the corners when using the Concept. This does not help Skylar at all because circles do not have corners and Skylar’s understanding of the Concept is a circle. They go a few rounds, getting more agitated and annoyed until Nika notices and joins the conversation.
Nika knows the concept very well and listens to both of the other developers describe their understanding and problems with the Concept. Then Nika tells Bailey and Skylar that both of their understandings are correct but their inability to see the Concept from each other’s point of view is what is making things difficult because the Concept is obviously represented as a cylinder that appears as a rectangle from one view and as a circle from another view.
Having a bit more of an understanding of the Concept, Bailey is intrigued by the idea that the rectangle is actually a cylinder and feels appreciation for Nika’s insight. However Skylar was barely confident in the circle representation and confused by the rectangle conversation and now Skylar’s brain has exploded because Skylar didn’t even have half a clue that the Concept could be 3D.
What does this have to do with the “4+1” View Model of Software Architecture? Being able to understand a thing one way is the sign of a good developer. Being able to understand a thing from more than one point of view is a sign of a good mid/senior developer. Being able to understand and describe a thing from multiple views is an ability held by senior developers in leadership positions.
Most systems that we build and maintain are much more complex than a cylinder and require much thinking to design, describe, build and maintain.
What is the 4+1 View Model of Software Architecture?
It is a way of thinking that is based on the use of multiple, concurrent views to address the separate concerns of various stakeholders of the architecture. It’s finding a way to look at the cylinder as a rectangle and as a circle but still understanding that the thing we’re looking at is a cylinder. One of the things that makes this still relevant is that the views are designed using a scenario driven, iterative process just like the current popular agile thinking.
The 4+1 views are the Logical View, the Process View, the Development View, the Physical View and the Scenarios.
Logical View (“What Do?”, “What Data?”)
The Logical View is solely concerned with the rules, or logic, of the system.
In object-oriented thinking this is represented by class diagrams and class templates. In data-driven systems this can also be represented by entity-relationship diagrams. This is our domain knowledge and interactions. This is the view we use when describing what our system does.
Process View (“How Do?”)
The Process View is solely concerned with the way things will happen in the system and is informed by the Logical View.
This view considers performance and availability. It deals with different “processes” and handles independent tasks. This is the view that most people think of when they think of Software Architecture.
Development View (“How Make?”)
The Development View is concerned with the way things will be built and maintained and is informed by the Logical View.
This is the view that is most comfortable with many web developers and project managers. This is 3 layered “architecture” of Presentation, Business and Data layers. This is DDD and TDD and BDD. This is branching strategies and Agile and scrum and project management and version control and CI/CD and all the other various thoughts and ideas that come with making software because making software is difficult.
Physical View (“Where Do?”)
The Physical View is concerned with the physical aspects of the system and is informed by both the Development View and the Process View.
This is all the computer and internet things that make up a system. This is servers and switches and ports and networks. For systems hosted in “the cloud” this is various cloud services that act like physical things.
Scenarios (Use cases)
The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios. Scenarios serve two main purposes:
- As a driver to discover the architectural elements during the architecture.
- As a validation and illustration role after the architecture design is complete.
These are the use cases for our MVPs and the use cases of our UX and DX designs. They allow us to consider the four other views when thinking through a scenario. I’d argue that this is the most important part of this model and it should be called the 1+4 View Model of Software Architecture.
Ways to use the 4+1 View Model of Software Architecture
Knowing things is one thing, knowing how to use the things we know is a whole other thing. So now that we know about the 4+1 View Model of Software Architecture, what can we do with it?
Better communication with stakeholders
Thanks to common terminology and different contexts, it’s easy to use the same words and talk completely past each other. Knowing about these views allows us to align our views with the stakeholders to talk about the same thing at the same time.
Better clarity in design
There is a lot to consider when designing a system and while we need to consider everything from memory usage to project management to network latency to user experience and it’s difficult to plan, communicate and consider all these things.
So don’t do that. Thinking of our designs in relation to these views allows us to slightly simplify our thinking when considering the design of a system.
Better understanding of systems and processes
The same complexities in design also exist when attempting to understand a system. Mixing concerns from differing views may result in lots of confusion. It’s difficult to understand everything about a system. By considering the different view models we can concentrate on understand a system from a certain view then work to understand how things from different views relate to each other.
Better combat of impostor syndrome
It is VERY difficult to understand systems by considering every view all the time. It is also VERY difficult to change our view of a system when we are taught to look at a system from one specific view.
It is more likely that we will not need to understand our systems from every view and that we will find that we enjoy and are stronger at relating to our systems from certain views. We should consider these strengths when we attempt to consider systems from different views.
Someone who is good at looking at systems while considering the Hardware View may not be good at looking at a system while considering the Logical View.
When we find ourselves looking at system from a different point of view, have confidence in our strengths in one view while acknowledging our weaknesses in the other view. This gives us a way to appreciate all the things we know while acknowledging all the things we don’t know without judgement.