[Summary] – Fundamentals of Software Architecture An Engineering Approach – Part 3: Architectural Thinking

This is my learning note from the book Fundamentals of Software Architecture: An Engineering Approach written by Mark Richards and Neal Ford. All the contents are mostly distilled and copied from the book. I recommend you to buy this book to support the authors.

An architect sees things differently from a developer’s point of view, much in the same way a meteorologist might see clouds differently from an artist’s point of view. This is called architectural thinking. Unfortunately, too many architects believe that architectural thinking is simply just “thinking about the architecture”

Architectural thinking is much more than that. It is seeing things with an architectural eye, or an architectural point of view. There are four main aspects of thinking like an architect.

• First, it’s understanding the difference between architecture and design and knowing how to collaborate with development teams to make architecture work.
• Second, it’s about having a wide breadth of technical knowledge while still maintaining a certain level of technical depth, allowing the architect to see solutions and possibilities that others do not see.
• Third, it’s about understanding, analyzing, and reconciling trade-offs between various solutions and technologies.
• Finally, it’s about understanding the importance of business drivers and how they translate to architectural concerns.

Architecture Versus Design

Making architecture work through collaboration

Making architecture work through collaboration

Unlike the old-school waterfall approaches to static and rigid software architecture, the architecture of today’s systems changes and evolves every iteration or phase of a project. A tight collaboration between the architect and the development team is essential for the success of any software project. So where does architecture end and design begin? It doesn’t. They are both part of the circle of life within a software project and must always be kept in synchronization with each other in order to succeed.

Technical Breadth

The scope of technological detail differs between developers and architects. Unlike a developer, who must have a significant amount of technical depth to perform their job, a software architect must have a significant amount of technical breadth to think like an architect and see things with an architecture point of view

Enhanced breadth and shrinking depth for the architect role

As shown above Figure, any individual can partition all their knowledge into three sections: stuff you know, stuff you know you don’t know, and stuff you don’t know you don’t know.

As an architect, it is more beneficial to know that five solutions exist for a particular problem than to have singular expertise in only one

As an architect, breadth is more important than depth. Because architects must make decisions that match capabilities to technical constraints, a broad understanding of a wide variety of solutions is valuable.

Read more on how to gain Technical Breadth

Analyzing Trade-Offs

Thinking like an architect is all about seeing trade-offs in every solution, technical or otherwise, and analyzing those trade-offs to determine what is the best solution. To quote Mark (one of your authors):

Architecture is the stuff you can’t Google.

There are no right or wrong answers in architecture—only trade-offs.

Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

The point here is that everything in software architecture has a trade-off: an advantage and disadvantage. Thinking like an architect is analyzing these trade-offs, then asking “which is more important: extensibility or security?” The decision between different solutions will always depend on the business drivers, environment, and a host of other factors.

Understanding Business Drivers

Thinking like an architect is understanding the business drivers that are required for the success of the system and translating those requirements into architecture characteristics (such as scalability, performance, and availability).

Balancing Architecture and Hands-On Coding

One of the difficult tasks an architect faces is how to balance hands-on coding with software architecture. We firmly believe that every architect should code and be able to maintain a certain level of technical depth (see “Technical Breadth”).

• The first way is to do frequent proof-of-concepts or POCs. This practice not only requires the architect to write source code, but it also helps validate an architecture decision by taking the implementation details into account.
• Another way an architect can remain hands-on is to tackle some of the technical debt stories or architecture stories, freeing the development team up to work on the critical functional user stories.
• Similarly, working on bug fixes within an iteration is another way of maintaining hands-on coding while helping the development team as well.
• A final technique to remain hands-on as an architect is to do frequent code reviews. While the architect is not actually writing code, at least they are involved in the source code.

Trong part này thì mình nghĩ kỹ năng mở rộng phạm vi hiểu biết “Technical Breadth” là điều kiện cần để trở thành 1 architect đủ tốt. 1 architect cần liên tục cập nhật kiến thức để có lý luận trong việc phân tích trade-offs của kiến trúc. Cũng cần balance giữa lý thuyết và thực hành.