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

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.

Can I have my time back please?:
This book was nearly painful to read... The point of the book can be summed up so easily, I can't imagine why it took 100 pages to do it. "The Software Architect role is not viewed correctly in the software development industry. A Software Architect is analogous to Building Architects - responsible for the aesthetics and overall vision and for the software. Their goal is to manage the software design (venustas) and make sure the software is useful." There, now you don't have to read the book. I do agree with the author's premise, and I also find that the role of Software Architect is either misplaced or not placed at all into software development projects. But the comparisons to ancient architecture are only vaguely relevant, and I would have been happy if the tangents only stretched that far. Did you know that the word "normal" originally meant "right-angled" and that it's current meaning only took shape in 1828? This (any many, MANY other tidbits of scantly useful information) can be found in the book (pg 38). A great explanation of what a Software Architect does for a living cannot.

Speaks to the essence of a Software Architect's profession...:
A quick yet enlightening read. This is a must read for any wanna-be software architect. It clearly points out that software architecture is not software engineering, or project management, and that the software development industry could accelerate its maturity greatly by applying the abstract principals of other architectural disciplines to software. That shouldn't be too hard, right? After all, we who develop software believe we own the corner on abstraction! This book will not teach you the Unified Modeling Language (UML), patterns of software abstraction, or how to write modular software, but it will help you think clearly and didactically about what software architecture needs to be.

Allow the book to inspire you:
Sewell and Sewell take an opportunistic stand at the ongoing debate regarding the building metaphor in IT systems engineering. Many authors before have argued that the differences between building a house, a city or an airport versus building an application, information system or an enterprise architecture are way to big to adopt each others roles. These authors do not try to convince anyone that there is a similarity between the two fields. On the contrary, they simply state that these builders have a long tradition in engineering complex constructions. They take you on a journey to find out how their profession has evolved and leave it to the reader whether software professionals should learn anything from this experience. For the open mind, this is an exiting perspective.