My story is a great example of the problem the authors are trying to address with their book. Namely, that in the software field, the Architect role is very misunderstood. Many think this role is purely to do the high level design. But the authors dissassemble this assumption, and several others, and show the true role for the software architect.
The book begins with two trains of thought. One train is a broad view of the classical approach to building things that Civilization developed over thousands of years of making buildings, bridges, castles, and other objects of technical prowess. If we cannot learn from our forebears then we are doomed. The other train of thought examines several spectacular software project failures, and how the teams did not use sound architectural processes.
In their view there are three roles in a software development project. These derive from the three roles in, for instance, building a house. They are: Client, Architect, and Builder.
Since my job is in a Quality team, I think they're leaving out a very important role. Namely, Quality Assurance. The lack of sound QA has doomed just as many projects as the lack of sound architectural processes.
In any case, the Architect role is to be the go-between. The Architect gathers requirements from the Client, translates them into Builder-speak, and is the Clients agent in assuring that the Builder's production turns into something close enough to what the Client wants that they'll accept it. The authors use an analogy of a three-legged stool, the stool cannot stand upright unless it has all three legs.
This book is highly recommended for all who wish to understand better what a Software Architecture offers. The book is merely the beginning point, an introduction, in a whole series of books about Software Architecture.
You can find out more at the Worldwide Institute of Software Architects