By the end of the lesson, you can list the aspects along which architectures are compared, and you can justify why there is no best architecture for every situation.
Why is a common set of aspects needed?
The question "which architecture is better?" cannot be answered along a single aspect. A decision usually improves something and worsens something else at the same time. If the aspects are named in advance, the debate is about requirements, not tastes.
What are quality attributes?
Quality attributes (also called non-functional requirements) describe how the system should work, not what it should do. The course uses the following seven aspects throughout, because most of the differences between architectures show up in them.
Aspect
Question
Typical opposition
Coupling
How much must the parts change together?
Tight coupling is simple but rigid
Deployability
What can be released independently, how often and with what risk?
Independent release means more units and more coordination
Scaling
What can be increased separately when the load grows?
Fine-grained scaling means more actors and more network
Data management
Who is the owner, who may read and who may write?
Shared data is simple but couples
Consistency
When does everyone see the same state?
Strong consistency limits distribution
Failure handling
What happens if a part fails or is slow?
More independent parts also mean more failure possibilities
Team and operations cost
How many teams, what tools and how much operational burden are needed?
Independence comes with organisational and infrastructure cost
How do they relate to each other?
The aspects are not independent. Reducing coupling (for example with separate services) can improve deployability and fine-grained scaling, but because of the network call it worsens failure handling, data management and consistency. These costs are not "bugs"; they are the price of the decision.
flowchart LR
A["Less coupling<br/>(separated parts)"] --> B["Better: independent release,<br/>selective scaling"]
A --> C["Worse: network failures,<br/>distributed data, operations"]
The characteristics are meaningful in measurable form. Instead of "fast", it is better to say "most responses of the search arrive within a given deadline under a given load"; instead of "scalable", "the search can be increased separately without releasing billing as well". The threshold value of the measure is always given by the requirement, not by the course.
The organisation is part of the system
Team organisation affects the architecture. According to Melvin Conway's observation, organisations that design a system produce a design that is a copy of their own communication structure. That is why the number of teams and their level of skill are also aspects: the same architecture works differently in an organisation of four people and in one that coordinates several dozen teams.
There is no best architecture
An architecture is good if it meets the important characteristics in line with the requirements, at the expense of the others. If fast market feedback is the main goal, simple release and shared data may be an advantage. If many teams work at different paces, the price of independent release may be acceptable. The following chapters use the same aspects for every style.
Common misconceptions
Statement
Clarification
"The most advanced architecture is always the best."
The best is the one whose costs are acceptable for the actual requirements.
"Scalability means running on many machines."
Scalability means that growth can be accommodated at the necessary point, at acceptable cost.
"Fault tolerance means there can be no failure."
Fault tolerance is known, bounded behaviour in case of failure.
"Team organisation is not an architectural question."
By Conway's observation, the structure of the system follows the communication structure.
In short
Quality attributes describe how the system should work.
The course uses seven aspects: coupling, deployability, scaling, data management, consistency, failure handling, team and operations cost.
A decision usually improves one and worsens another.
Characteristics are best formulated as measurable requirements.
The structure of the organisation is part of the architecture.
Review questions
Why can splitting into services improve deployability, and why can it worsen consistency?
Rewrite a vague requirement ("it should be fast") into a measurable form.
How does the number of teams affect the choice of architecture?
Learning resources
Conway's law (Wikipedia) — the statement of the law and its source: Melvin E. Conway, "How Do Committees Invent?", Datamation, April 1968.
Quality Attributes and Trade-offs
Objectives
By the end of the lesson, you can list the aspects along which architectures are compared, and you can justify why there is no best architecture for every situation.
Why is a common set of aspects needed?
The question "which architecture is better?" cannot be answered along a single aspect. A decision usually improves something and worsens something else at the same time. If the aspects are named in advance, the debate is about requirements, not tastes.
What are quality attributes?
Quality attributes (also called non-functional requirements) describe how the system should work, not what it should do. The course uses the following seven aspects throughout, because most of the differences between architectures show up in them.
How do they relate to each other?
The aspects are not independent. Reducing coupling (for example with separate services) can improve deployability and fine-grained scaling, but because of the network call it worsens failure handling, data management and consistency. These costs are not "bugs"; they are the price of the decision.
The characteristics are meaningful in measurable form. Instead of "fast", it is better to say "most responses of the search arrive within a given deadline under a given load"; instead of "scalable", "the search can be increased separately without releasing billing as well". The threshold value of the measure is always given by the requirement, not by the course.
The organisation is part of the system
Team organisation affects the architecture. According to Melvin Conway's observation, organisations that design a system produce a design that is a copy of their own communication structure. That is why the number of teams and their level of skill are also aspects: the same architecture works differently in an organisation of four people and in one that coordinates several dozen teams.
There is no best architecture
An architecture is good if it meets the important characteristics in line with the requirements, at the expense of the others. If fast market feedback is the main goal, simple release and shared data may be an advantage. If many teams work at different paces, the price of independent release may be acceptable. The following chapters use the same aspects for every style.
Common misconceptions
In short
Review questions
Learning resources