[Summary] Fundamentals of Software Architecture: An Engineering Approach, Chapter 1: Introduction

Recently, I’ve started reading Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford, and to support my understanding, I’ve started writing summaries and decided to share it in the form of articles.

In this article, I will be summarizing Chapter 1: Introduction with hopes of feedback in case you have any suggestions for improvement.

The chapter starts with the lack of a well-defined career path to the software architect and this is due to several reasons:

1- Having no exact definition for software architecture and here the book quotes a famous whitepaper by Martin Fowler, the author of the popular refactoring books, where he refuses to try to define it and instead falls back to the famous quote:

2- The scope of responsibility for the software architect that is initially massive and is continuously expanding due to the continuous change in the software development ecosystem allowing for more alternatives that were considered expensive or even impossible.

The chapter then follows on trying to define software architecture through different dimensions:

1- Architecture Characteristics, that is the important aspects of the system independent of the problem domain such as testability, scalability, performance, etc…

2- Structure, that is the architecture style used such as the layered architecture style.

3- Architecture decisions, that is the rules for how a system should be constructed and this is not always clear given the structure, that is you can use a layered architecture style but an example for architecture decisions would be the rules defining which layers are restricted.

4- Design principles, that is the guidelines put by the software architect for the developers to follow, an example would be "To leverage async messaging between services to increase performance whenever possible".

The chapter then tries to define the software architect’s job through several core expectations irrespective of any given role, title, or job description:?

• Make architecture decisions
• Continually analyze the architecture
• Keep current with the latest trends
• Ensure compliance with decisions
• Diverse exposure and experience
• Have business domain knowledge
• Possess interpersonal skills
• Understand and navigate politics

From this point, the chapter delves into some of the newer intersections between the role of software architecture and other parts of the organizations:

• Engineering Practices and DevOps where the chapter briefly introduces the concept of evolutionary architectures and architectural fitness functions to assess some architectural characteristic(s).
• Software Development Process and how could the architecture reflect on the way teams are organized and managed.
• Data and that's because a large percentage of serious application development includes external data storage.

The chapter finally closes by defining the laws of software architecture:

Note: If you’re interested in reading the book then please don’t skip part 1 as the book forms a pipeline where part 1 starts by helping you through analyzing requirements and extracting architecture characteristics to the second part where you use this to compare between different architecture styles leading to the third part where you’re given the guidelines and and soft skills to communicate and reap the benefit of what you've learnt.