[.ca] The Software Architect's Profession: An Introduction (ISBN 0130607967)

initially interesting but ultimately disappointing:
I liked this book, it was a quick and enjoyable read about the history of building architecture. Relatively little was said about software architecture, as I read it the book says the role of a software architect needs to be defined but does not attempt any sort of definition itself. This is not a criticism, the book has in its title that it is an introduction, and it makes for a good introduction. The writing style was amusing, I took a quick poll around the office to see who knew what a hair shirt is, including me only 2 out of 10 knew. I say ultimately disappointing because as I reached the end of the book and realized that the authors really weren't going to give any direct information about what software architects do, not even drawing clear distinctions between the designs they turn out vs. what an engineer turns out, I lost interest and thought it wasn't really worth the $.

enlightening:
An apt paradigm for the software profession. Contains the best definition and differentiation I've seen of the roles in software development.

Must Read for Software Architects:
As other reviewers have pointed out, there is very little reference to software in this book. But as the Sewell's point out, most of the actual software technology is in the province of the builders, and/ or the experience base that the architect brings to their engagement. It doesn't belong in this book. If you're a practicing software architect, as we are, I think you'll find this book puts into context a great deal of what occurs on your projects. While others, such as John Zachman also use this analogy, they use it to different ends. Zachman, for instance uses it as a framework to build successively more detailed models of the systems to be built. This is a book is advocacy for Software Architecture as a Profession

Good subject - poor execution:
This book starts out well, but leads nowhere. By the end of the book, I felt that the authors had no business writing about software architecture because they seemed to have little insight into software development. When they make statements like "great design is rarely mentioned in the software field" (I've paraphrased) I can't help but wonder where they have been for the past 30 years. I'm in the industry and I hear and participate in those discussions frequently. There are of course projects, where the design (and architecture) are not properly done, but it is common knowledge that this a bad idea. My determination of a good software book is whether or not, I would want the authors working on a project with me. By the end of this book, I felt like I would not want these two on any project I was leading. They seem too naive, and too eager to embrace over-simplifications of complex topics. I'll give them one star for at least trying to define the role of software architect and for taking on a complex subject.

A mature definition of roles in Software Development:
I found this book quite insightful. I am not sure if the analogies between traditional building construction and software development presented in the book hold, yet they do provide a different perspective of looking at this industry. The software development crisis and problems mentioned in the book seem to be relevent with the existing workforce in the industry. I being a developer myself for the past 5 years know this first hand. This book certainly helped me in attempting to align my own core interests with the roles in the industry (as they should be). I know I don't have all the answers to my career questions...but I think this book if nothing else serves as a lamp in whose light I may be able to mould my own understanding and model of the industry to suit myself. Enjoy!!!