Rating: 
Summary: Constructing Software=Constructing Houses, why not Cooking?
Review: I looked forward to get this book with such a promising title, but it turned out to be a philosophical essay dancing around the bad analog between constructing a building and constructing software. To me the only common denominator between these two is the fact, that some of the terminology (like terms design, architecture, construction) can be applied to both. Equally useful analogy would be cooking food or composing music. I doubt this book helps anybody understand "The Software Architect's Profession" better.
Rating: 
Summary: An Intoduction to the Building Architect's Profession.
Review: The author laments the lack of a well defined practice of Software Architecture. The book starts out citing two failed software projects which could have used a software architect.
After that it delves into the history of architecture from ancient times to day. An entire chapter is devoted to how the building architect I.M. Pei sucessfully rearchitected the Louvre in Paris in the face of many challenges. So what's that got to do with software architects? While the authors claim that there are parallels between s/w architects and architects of the traditional kind they fail to establish a clear link.
An informative and brief read about architects (not the s/w kind) and their profession. If you are looking to be a s/w architect look elsewhere.
Rating:
Summary: Nice introduction
Review: The book starts with a comparision of software architect with building architect and said that there is a perfect parallelism between the two(I doubt so ..). It then goes on and on and talks about building architecture .... which gets dry at times. The author believes that software architect is a completely different breed from Project Managers and Programmers, just like building architects and builders. However, in software design, I can't really agree with this. A software architects need to be able to build and understand the technical stuff before he can be a software architect. Not like what the author says "takes a few course in CS or computer engineering and want to work somehow in IT".What is good about this book is that at least it tries to define the software Architect profession which has all along been rather fuzzy. I do not agree fully with it but I guess it's a good step, a baby step towards the defining the profession. Although it's an interesting read, I felt that it's overpriced. It's only a thin book with around 100 pages. Moreover, it's not written in simple english and sprinkled with words like "firmitas", "venustas". Read it if you have the patience. :)
Rating: 
Summary: It had to be said.
Review: The Sewell's try to address the crisis in our industry by attempting to formalise and define the role and profession of the software architecture. They do this by comparing the software industry to the building industry. They advocate specific educational programs for software architects. Personally I feel that this approach is valid - I have post-graduate qualifications from a school of (building) architecture and design, plus bachelors in computer science - but work as a software architect. Yet I find a lot of confusion in the marketplace (and sometimes in my own mind) about what a software architect is and is not. This is not a practical book. Instead it attempts to provide a philosophical basis and justification for the profession of software architecture. If you read this book hoping to find an architectural process or methodology, look somewhere else. If you are looking for a set of templates to use as a basis for your practice, read Dikel eta al's "Software Architecture" instead. But perhaps the current book will contribute significantly the debate that is sorely needed in the software industry. The book is well-written and a pleasure to read. I found the anecdotes relevant and enlightening.
Rating:
Summary: Good subject - poor execution
Review: 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.
Rating:
Summary: Can I have my time back please?
Review: 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.
Rating: 
Summary: Good Introduction to a Badly Needed Profession
Review: This is an easy read for those (i.e., Software Architects) who want to draw parallels between the traditional meaning of the term "Architect" and that of the "foggy" Software Architect in order to help teach others that this profession is badly needed. More emphasis on the role of a Software Architect and case studies of the project successes with a Architect are needed. Also, the essence of the material could have been covered in 50 pages; however it is a step-forward in defining the profession.
Rating:
Summary: Software Architect - the next respected Professional?
Review: We are in an industry whereby progress can be effectively described by Moore's Law, stating that every 18 months, processing power doubles while cost holds constant. Telecommunications bandwidth and computer memory and storage capacity are experiencing a similar fate. Although we cannot say the same may apply to methodology, process and framework supporting software construction. These have also evolved in quick and overlapping pace. I joined the IT workforce 13 years ago happy with designing application software using straightforward FlowCharts and Structured language writings of collaborating modules. This has wondered off for a while to the "false" promise of 4th GL and subsequently to the existing Object Oriented world. The author propose the Software Architect be educated and will earn his due recognition as a true Professional, as we see in a Doctor, Lawyer or Building Architect. One important aspect the author rightly argues for is the definitively role of a software architect in a complex software construction exercise. But without the institutionalization of the Software Architect profession, it is going to be a challenge holding any individual accountable for the "soundness" of software design. It is hard to agree that a proficient Software Architect may not be a first class software builder. The analogy of the Building and Construction industry gives hope to people who enjoys software but may not fancy sitting in front of machine churning out beautiful language constructs only a machine can effectively execute. I do look forward to that day for that will be when everyone gladly assimilates software as part of his/her daily essential existence, and without suspecting fear. Anyone with the audacity to leave a backdoor for the next "Y3K bug" will be revoked of his rights to design any future system. I cannot imagine a Building Architect designing a state-of-the-art Hospital structure that may just collapse when we are celebrating the arrival of the next "millennium". But if there's any realization through this process of discovery, it would be that software construction is often more important an art than about technical prowess. The next great software architect will not only inspire more "breath taking" structure to be planned and built, but also should leave a lasting legacy behind (just as Imhotep would with the pyramids), even if it's only in a virtual world.
Rating:
Summary: Overpriced, pedantic essay
Review: While I recognize the need for a distinct role of software architect, different from that of software developer, this book takes the analogy to building architecture way too far. It fails to recognize that while physical architecture is literally set in stone, software structures are forever malleable, that physical architecture is concrete and there is a standard way to communicate it while software architecture can be abstract and efforts to standardize its representation have not been truly successful, that aesthetic factors play an important role in physical architecture while software architecture is driven almost exclusively by practical considerations, and that software construction often calls for professionals, not tradesmen comparable to plumbers and brick masons, etc. I think for most organizations it makes practical and economic sense for developers to be able to take on more than one role during the course of a project, and most team members would look forward to it as well. I also think that the superstar architect championed by this book who sticks to a bird's eye view of things while the lowly "builders" fill in the details would have a difficult time coming up with practical designs as well as getting the respect from developers he would need to be truly effective. This books gets two stars from me because it does contain some useful insights. For instance, the case it makes for architects as client advocates is particularly compelling. It also stresses that an architect should understand the client's world view in a way that goes above and beyond laundry lists of requirements, which is hard to argue against. I guess if this book were a ten to fifteen page manifesto, with the key insights and ideals behind software architecture presented concisely (along with a proportional reduction in the [$$] price tag), it would be worth it. But unless you are interested in a tour through architecture history (filled with such illustrating words as "venustas" and "firmitas"), a cliched account on why software projects fail, and a concept of software architecture that raises more questions than it answers, it would be better to look elsewhere.
| 
