Warning up front: This book is not about teaching hands-on, direct-to-use techniques for documenting software architectures. It is a lengthy, sometimes academically long-winding discussion about what a good documenation is and what techniques might be employed. It is a book to make the reader think, it is not a shop from which you can lift pracical recipes without reading the small print first. But the book does fulfill its promise: It makes you think about the problem. Pretty hard, actually. So read on if this is what you want.
Very few books on software architecture tackle the difficult problem of how a software architecture should be presented. This is a surprising omission given the commonly accepted dictum that architecture is, to a large extent, about communication. The omission may indicate that despite attempts at formalizing software specification (e.g UML, BPMN or various attempts at specifiying templates for architectural documents) no single technique of describing an architecture is sufficient in practice. From my own experience, I think this is not really surprising. Unlike specifications for physical machinery, software is prone to demand a plethora of different views. These range from the creation of the contextual language for a specific software (e.g. the formalisation of measurement in medicine as first step towards building a diagnostic system) over the various clasical views on an architecture all the way to a business perspective whithout which no budget may be available to the project. What makes software architecture documents particularly difficult is the interrelation between various views and the importance of dynamic aspects (which are among the more difficult aspects to capture in documentation). But to my mind, one of the hardest challenges of all, and usually mentioned at best in passing, is the problem of creating the right sort of contextual language up front.
The present book is a laudable attempt at discussing various methods of formally describing a software architecture. That the requiste material is all there can be glimpsed from the table of contents. I wish to make the following remarks: The authors make no attempt at finding a general formal solution to the title-problem of documenting a software architecture. Instead, they discuss the standard persepctives but remain aware throughout that there is no single solution. They take the reader through the various persepctives that need to be serviced by an architect. The authors challange their readers to think further by providing numerous exercises which help show the diversity inherent in the discussion. They do not limit themselves to one technique of documentation but, through their own example, make it plain that documenting an architecture requires different tools and, above all!, a sure command of language. It is this latter distinguishing feature, which is not explicitly mentioned in the book but implicit in the author's own way of presenting their thinking, that should be one of the main conclusions of the book. However, and this is where I have not been quite so happy, they stop short of showing how formal representations tie in with the way we first create the language in which we talk about the problem to be cast in software.
The book is not a book of recipes. It is a book that gets you thinking about the complex problem of writing up an architecture. The focus remains on documenting technical architectures and only implicity touches on the larger problem of how an architecture is, in writing, related to the problem domain it is intended for. I find it a useful restriction that templates for use in projects are not provided - these tend to limit inexperienced architects to given perspectives and in practice may lead you to omitting what may be particular and specific about your architecture. An excellent push in the right direction. Be pushed and then push on.