Opening the chapter, the author begins asking about what it designs and architecture and what the difference about it. First he contextualizes those words: architecture as high level and design as low level. As an example, he uses an analogy as a house project, making us to go in the way to say: architecture and design are different, but in the analogy's end he shows to us, it makes no sense because the result, high level, and the "blueprint", low level, are parts from the same thing.
The low-level details and the high-level structure are all part of the same whole.
After saying that, he questions one more time, yet this one is about the goal of good architecture. Himself answer with:
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
This affirmation match about what he wrote in the introduction section of the chapter, what he says anyone can code software, software programs that needs hordes of programming to code and maintain, but good software, software what does not need this all, software that can be maintained by few developers is hard to do and needs good architectures decisions.
He shows a use case about what he's writing; a business what he does not edify, but demonstrate what happens when the overconfidence of programmers that say they can do changes when the product is in production and does not need making good decision architecture now, what makes this code frustrating, expensive and unprofitable.
Ending the chapter he affirms that the best way to develop good software is avoiding the overconfidence, thinking about architecture seriously and to that and to learn these rules it is needed to know what good software architecture is and recommending the book for archive this task.
To build a system with a design and an architecture that minimize effort and maximize productivity, you need to know which attributes of system architecture lead to that end.