Book review – Fundamentals of Software Architecture: An Engineering Approach

I recently finished reading the book I've heard a lot of. Both authors are well-known Software Architects with dozen years of experience. Mark Richards, for example, runs great bi-weekly Software Architecture Monday lessons.
I want to share my opinion about this book, save some notes I made, and explain why I think it is worth to be read.

The book is well-structured and it has 3 main parts:

1. Foundations
2. Architecture Styles
3. Techniques and Soft Skills

Foundations

Authors start with the definition of software architecture and Architecture role. They says the architecture consists of several things:

1. Structure
2. Architecture Characteristics
3. Architecture Decisions
4. Design Priciples  

The architecture structure describes the system based on the used architecture styles.

The architecture characteristics of the system are the same as the nonfunctional requirements. Architects can use them for describing architecture structures and being able to compare different design decisions and approaches.
Here's the list of some architecture characteristics.

The architecture decisions define the rules for how a system should be constructed. It's based on architecture characteristics the system should provide.

The design principles behave like a guideline. They are more recommendations than strict rules engineers should follow in order to build the desired system.

Authors also define the expectations of an architect. They highlight and describe 8 core expectations:

1. Make architecture decisions
2. Continually analyze the architecture
3. Keep current with the latest trends
4. Ensure compliance with decisions
5. Diverse exposure and experience
6. Have business domain knowledge
7. Possess interpersonal skills
8. Understand and navigate politics

Two important software architecture statements are mentioned:

Everything in software architecture is a trade-off.
– First Law of Software Architecture

Why is more important than how.
– Second Law of Software Architecture

A good software architect should also have architectural thinking (thanks captain obvious 🙂). So authors say it's based on analyzing trade-offs and understanding business drivers skills.

Then, they focus on modularity. It's mentioned how to measure modularity by using cohesion, coupling, and connascence. Authors use specific formulas that help to calculate these metrics.

Several next chapters are related to architecture characteristics:

• definition of architecture characteristics: operational, structural, and cross-cutting;
• identification of architecture characteristics: explicit and implicit;
• measuring and governing architecture characteristics: operational and structural measures + fitnes functions;
• scope of architecture characteristics.

All this information is extended by architecture katas and decisions based on architecture characteristics. It's useful to see how the theoretical information can be applied to real-world examples.

When we understand architecture characteristics it is time to return back to the modularity and discuss the component-based thinking.

Components can be presented as:

1. Libraries: wrappers, that communicate via language function call mechanism.
2. Services: run in its own address space, communicate via different protocols (HTTP, TCP/IP, etc..), and form standalone units.

Components can be grouped by using 2 approaches:

1. Technical partitioning (layered architecture).
2. Domain partitioning (service architecture).

Authors describe how to identify components, analyze their roles and characteristics.

There're 3 main components discovering approaches:

• Actor/Actions approach: map requirements to components (what they can do and perform).
• Event storming: comes from DDD and based on an assumption the system will use messages/events as a communication channel.
• Workflow approach: it's similar to the event storming approach but without the constraints to use the message-based channel.

When the foundation is covered, it's time to understand architecture styles that exist nowadays.

Architecture Styles

This part authors start with the differences between monolithic (single deployment unit of all code) and distributed (multiple deployment units connected through remote access protocols) systems.

Monolithic architectures can be:

1. Layered
2. Pipeline
3. Microkernel

Distributed architectures include:

1. Sevice-based
2. Event-driven
3. Space-based
4. Service-oriented
5. Microservices

It's said that distributed architecture styles have multiple advantages but they also have plenty of difficulties or fallacies.
Here's the image of the list of 8 fallacies of distributed systems I took from a great technical blog.

All of these fallacies are quite obvious but engineers often don't take them into account when they build distributed systems.

Then authors describe 8 architecture styles with the topology, diagrams, and good examples:

1. Layered architecture: a style with several isolation levels, e.g. presentation layer, business layer, services layer, persistence layer, database layer.
   Examples: a standard frontend, backend, and database isolation inside a single monolith.
2. Pipeline architecture: it came from Unix systems where functionality is split into discrete parts that can communicate with each other via pipes.
   Examples: ETL tools, Apache Camel.
3. Microkernel architecture: it includes a core system and plug-in components.
   Examples: Eclipse IDE, Jira, Jenkins.
4. Service-Based architecture: independent applications that are deployed separately but usually have a single database.
5. Event-Driven architecture: it's made up of decoupled event processing components that asynchronously receive and process events. There are 2 topology types: mediator (a single node that is responsible for all communications between other nodes) and broker (there's no central place that manages all the messages).
6. Space-based architecture: it's based on processing units that can have a shared database but should also include replicated local storages (caches).
7. Orchestration-Driven Service Oriented architecture: it uses shared resources and communication buses across multiple services. It sounds more like an enterprise legacy.
8. Microservices architecture: it includes multiple services for each bounded context. Each service is independant and include its own persistance layer (database). The communication between services can use the choreography or the orchestration approach (similar to the Event-Driver architecture style).

When the main architecture styles are described, it's time to see how to choose the correct one for a particular system. Authors mention the evaluation approach that allows architecture to build systems based on:

• Observations from the past
• Changes in the ecosystem
• New capabilities
• Acceleration
• Domain changes
• Technology changes
• External factors

In order to compare these styles, authors use a set of architecture characteristics. I created a summary table with all the described architecture styles.

The main point here is (again):

Everything is a trade-off.

However, knowing all these styles doesn't automatically make you an architect. You also need...

Techniques and Soft Skills

In the last part of this book authors cover other important topics:

• decision justification;
• documentation;
• communication.

They describe the architecture decision anti-patterns:

1. Covering your assets: avoiding making the decision out of fear of making the wrong choice.  
   Solution: wait until the last responsible moment
2. Groundhog day: it happens when people don't understand why this decision has been made and constantly asking about the reasons.
   Solution: provide clear technical and business justifications.
3. Email-drivern architecture: it happens when there is no central place where the architecture decisions are stored.
   Solution: keep architecture decision records (ADR) in a single point of truth, e.g. git repo.

Then, authors explain the structure of architecture decision records (ADR) and request for comments (RFC).

Possible ADR's structure:

• title;
• status;
• context;
• decision;
• consequences;
• compliance;
• notes.

The interesting chapter in this part is related to the architecture risk analyze.
It's shown how to use the risk matrix and risk assessment.

When leveraging the risk matrix to qualify the risk, consider the impact dimension first and the likelihood dimension second.

For example, what is the impact if one of the services goes down and becomes unavailable? Let's say, it'll be an issue and the system won't be able to work without this service. So, the impact is high (3). However, let's assume, this service is situated in a highly available server or there's a cluster of these services. In that case, the potential risk is low(1). It gives us an overall risk rating of 3 (medium).

A risk assessment is a summarized report of the overall risk. It's based on analysis of every system element and its risk criteria by using the risk matrix.

The authors also say it's better to include as many senior engineers, team leaders, and architects in this analysis. This procedure is called risk storming (don't mess it with the event storming).

Then authors make a quick note about the tools, standards, and techniques that can be used for diagramming and making presentations: UML, C4, ArchiMate.

The effective architect should also apply the correct level of control and understand plenty of external factors:

• team size;
• team familiarity;
• team experience;
• project complexity;
• project duration.

And last but not least, soft skills play a huge role in an architect's career. Negotiation skills are important as well as the 4 C's of architecture: Communication, Conciseness, Collaboration, and Clarity.

Architects should know so many things and constantly track new technologies. But how to do that in our busy lives? The authors propose to use the 20-minutes rule: spend this time learning something new every morning just before starting your job routine. One possible way is to build the personal technology radar.

Summary

The book is well-structured and gives a high-level overview of modern software architecture design practices and styles. I'd recommend it to any Engineer who wants to better understand the responsibilities of the Software Architecture role as well as the main difficulties Architects need to deal with.

I'll definitely keep this book on my bookshelf and return to it from time to time. It tells a lot to me 👍.

That's it! Theoretical knowledge is good but don't forget that:

Practice is the proven way to build skills and become better at anything in life...including architecture.
– Mark Richards & Neal Ford

P.S. The newest book of these authors  "Software Architecture: The Hard Parts" is already on my reading list for 2023 and I can't wait to start learning it.