Paul C. Clements

All software projects have architecture, but not all have formal Architecture. This is a book for projects of the latter sort. Although the text had gems scattered throughout, much of what was presented was much too formal for the more agile and informal environment I work.

My recommendation is that most people will get the most value by skimming the prologue, especially sections P.2.2 and uses and audiences for architecture documentation, section P.4 on architecture styles, and P.5 on rules for sound documentation[1]. Flip through the chapters on the different view types and read the description of those that feel most relevant (skip the text about the examples and just look at the diagrams). Read chapter 7 on documenting software interfaces. Skim chapter 8 on documenting behavior. Read chapter 11 on reviewing an architecture document.

You won't find all of the gems this way, but you'll get a better value for your time investment than if you were to read the whole thing.

[1] In sum:
1. Write documentation from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use a standard organization
5. Record rationale
6. Keep documentation current but not too current
7. Review documentation for fitness of purpose.… (plus d'informations)