The book has three parts: the fundamentals, a tour of architecture styles, and a closing section on skills that are not technical. The thesis holding it together is that there is no correct architecture, there are trade-offs, and that the job is not choosing well but explaining precisely what was given up by the choice.
What I took from it
Architecture decision records. Write the context, the decision, and above all the rejected alternatives and the reason. A year later nobody remembers why it was not done the other way, and without that record the same argument repeats in full, with new people who are quite right to ask.
Architecture characteristics as requirements that trade against each other. Asking for a system that is fast, cheap, flexible, auditable and easy to operate is asking for nothing. Forcing a ranked choice of three is one of the most productive conversations available with a management team.
And the final part, on negotiation and presenting, which is the least read and the one that decides whether an architecture gets built or stays in a document. A recommendation nobody understands is not a recommendation, and a diagram that needs its author standing next to it has the same problem.
What I left out
The style catalogue as a catalogue. It is useful for shared vocabulary, not for choosing from a comparison table: no real company fits entirely inside one style, and the star ratings the book assigns to each give a false sense of measurement. It is the most quoted part and the least useful.