Rating: 
Summary: Uneven presentation masks a uniquely valuable book
Review: I couldn't resist this book. Parts of it represent a clear-eyed, cards on the table look at the Software Architect job title. The introduction begins well, for example, explaining that software architects are politicians, technologists, authors, evangelists, and mentors. The description of a "marketing architecture" suitable only for PowerPoint slides is dead-on. But by page 16, the book lapses into a religious discussion of RM-ODP, Zachman Frameworks and the "horizontal-vertical-metadata" pattern, flinging information around for no discernable purpose.But this is the first book of its kind, in my experience. Buried within are some extremely practical nuggets and an overall useful treatise on what it means to be an architect that serve to remind those of us with that title on our resumes to take pride in our work. Later chapters cover topics such as "Architecture vs. Programming," "Leadership Training," "Communications Training," "Architecture Mining," and a concluding chapter on "Psychological Warfare"--techniques for building and selling the perception that a given architecture represents the correct future course of a large organization. (I can't help but feel that one of the two authors was dumping in raw data while the other contributed insightful gems--I blame the apparent lack of an editor for the uneven result.) Prentice Hall used to have higher quality standards. For this price, I was shocked to see so many typos, such as this from page 33: "...also we are adding some dynamic architecture elements represented metadata." In most cases, the meaning can be inferred, but here--perhaps the meaning is that the book had little or no copyediting.
Rating:
Summary: A useful introduction and overview
Review: I found this book [to be] useful... This is perhaps because I am newer to Software Architecture (I came to Architecture after a management stint lasting a couple of years). In addition I don't work in a Microsoft environment, but design open-source web applications. So the target audience is not the very experienced software architect working in a Microsoft shop. But the technical content is useful even if the future of CORBA (and IDL) seems uncertain at the moment. Technically, the book complements my current studies of the design of distributed object systems. I liked the introduction to componentware. I found many other aspects of the book quite interesting, for example the lightweight process presented, and the overviews of the other formal processes. It equipped me with the high-level knowledge I need to do my job. Talking about which - the description of the software architect's role in the organisation is another useful aspect of the book. Negatives: As mentioned by many, the proofreading was not done well enough. As someone with technical leadership experience, it ran out of steam for me towards the end. And unfortunately, the process templates presented in the appendix were incomplete. Still, I think that the book was a valuable read for me, and I now feel ready to tackle something more challenging, technically.
Rating: 
Summary: This is religion!
Review: I had high hopes for this book. Unfortunatly the authors were unable to rise above the technology/process wars. The words "In Our Opinion" or simalar statements occur on every other page. If you happen to be in disagreement with the opinions reading this book is torture. I am afraid this will hurt WWISA, the goal of creating a viable Software Architecture Profession can only be achieved if we stay independent of the wars. This book, being visable evidence of the organiztions existance will give readers a false impression of the WWISA.
Rating:
Summary: Jekyll & Hyde
Review: I have both good and bad things to say about this book. Over all, this book isn't useful to me on a daily basis, though it can be inspiring.
* This book contains some really good advice on being a successful software architect (or even a computer professional in general). It touches on many subjects related to software architecture, so it could possibly work well as a general reference. Such breadth should be welcome for a topic that is reportedly lacking in reference books.
* I find myself ignoring a lot of the specific information as being too specific, even biased. A good example is the excess coverage and admitted bias for RM-ODP (the Reference Model for Open Distributed Processing). Much of the specific information would be better off in a separate book (e.g., one providing the merits of RM-ODP over other approaches)
* A significant amount of the good information in this book is interlaced with material that really needs editing, giving the book an unfinished feel. While the good writing made me think the book was good before I bought it, the bad writing fooled me into thinking the book is bad after I bought it. (Well, that and its shortcomings for my original reason for buying it.) The good parts are actually quite good, but the bad parts contain spelling and grammar errors and often seem to just ramble. It's not unusual for the same thing to be restated repeatedly in different ways.
* I wanted a book more general than the GOF design pattern book with simple solutions, something that said: "if you want to do this, then use this approach." This book isn't it, which was disappointing. Maybe I should have read reviews before buying.
Rating: 
Summary: Exellent !
Review: I really enjoyed reading this book. It is really an exellent book for the people who are interested in building a career in Software Architecture
Rating:
Summary: Jekyll & Hyde
Review: I wanted a book more general than the GOF design pattern book with simple solutions that said if you want to do this, then use this approach. This book wasn't it. I was fooled by some of the good writing and should have read reviews before buying. * Yes, it badly needs an editor. Desparately. Really.
* This book does have some good information in it, but it is interlaced with hype/nazism, giving it a Jekyll&Hyde feel.
* The good parts are actually quite good, and the bad parts....
* It is often one-sided so that if you're not doing what they're doing, you're simply doing the wrong thing with your life and going the way of the dinosaurs. Wake up and smell the distributed components.
* The last part of the last chapter explains the problem: they think that information should be dumped into a book in raw form to avoid the risk of missing anything important. The suspense wasn't worth it. With Mowbray being the series editor, I won't be buying any more of the series.
Rating:
Summary: Extremely poor quality book mars few good ideas
Review: I was just recently given the opportunity to be the Chief Architect at the startup I work for. This is after many years of architect experience without the title. I also have an extensive background in software engineering, both practical and academic. My first inclination when given a new task is to go out and buy the books and sit down and read, to absorb the perspectives and views of others on the types of activities and endeavors that I am about to embark on. "Software Architect Bootcamp" (and the other WWISA titles) looked perfect for a thorough perspective on today's software architecture thinking. I have already read Shaw and Garlan's "Software Architecture" and Witt, and company's, "Software Architecture and Design", two very good books on the pragmatics of constructing software architectures. I have also gained architecture insight from reading such books as "Analysis Patterns" and "A System of Patterns". I was looking forward to significant additions to those books. Unfortunately, the basic aspects of "Software Architect Bootcamp", the writing, the thinking, the editing, and the copy-editing, are of such dismal quality that I have been more frustrated and angered than edified. I am dismayed that Prentice Hall would put out such a poorly managed book. I rely on a good book to provide references and pointers to further material to study. None of Chapter One's references were actually in the bibliography. That is sloppy. I rely on a good overview book to provide a balanced treatment of current thought. Instead, I get the strident, unsubstantiated diatribe against object-oriented programming in Chapter Two. And so forth. Buy the book if you want to mine for the little gold here and you don't mind a lot of mud along the way.
Rating:
Summary: Ambitious title, but poor content
Review: I was very enthusiastic to see the seal of the WWISA on this book. I had read their book titled "Software Architecture - Organizational Principles and Patterns" and thought this book would be just as useful. I was wrong. I stopped reading this book after the first chapter. The book lacked a focus. I jumped to a chapter in the middle of the book and found the same problem. This book needs more focus, better diagrams and more streamlined approach towards systems architecture.
Rating:
Summary: Terrible editing but the "right" message
Review: If you need an example of how to not write or edit a book this is it. What saves it is at least the architecture is based on contemporary thinking and not the latest pap out of Redmond. That alone makes it tolerable. Of course the RUP centric view and emphasis on CORBA are strong points. If you're out to learn architecture (as in go to bootcamp) at least study the solid features of architectures and methodologies. Leave the For Dummies series to the MS worshipers and architect [....]
Rating: 
Summary: An overview of the field of software architecture
Review: Judging by the title of this book, it should contain topics that represent the basic knowledge required from a software engineer must be aware of regardless of the role he plays -- software architect, designer, implementer. Indeed, this book covers topics like overview of the history of the software architecture discipline, major technologies at play, software development lifecycle, elements of software design, an extensive advise on how to handle team development risks, software design process, different aspects in the process of defining architecture, psychological techniques of survival in organization. The book is written with a ***distributed system architect*** in mind. This book covers well the field of managing software complexity through modeling and development processes; it talks about history of different approaches to architecting and designing complex systems, about managing team development, communication, organizational risks, etc. Most of the information in this book *is* common sense and must be known to any critically thinking mature developer. I found especially interesting the information on evolution of the architectural thought. The book has a number of shortcoming. In many places the presentation of material is sketchy and **quite boring**. Authors either skipped completely or dedicated just a few words to some topics, while they spent 20 times of that on the others. For example, the authors dedicated almost 20 pages to UML; at the same time I could not find any decent reference to RUP. The book often forces the reader to refocus, although all of the information presented in it is on the topic. After browsing the book it is not hard to imagine the authors screaming, "It's a war out there!! If you don't buy this book, your suffering will be enormous!" :). This probably explains the chapter names: Military History, Software Architecture: Going To War, Software Architecture: Drill School. Other chapters have equally obscure names: Software Architecture: Intelligence Operations (the chapter talks about managing information), Communications Training (communicating architectural and design concepts, UML), etc. On a serious note, I have found all this not very helpful and quite annoying. If you participate in architectural and project management activities in your organization, you should be aware of the most material covered in this book. Certain chapters could be helpful to a manager as well. This is unfortunate that the authors have failed to make the book more entertaining and readable.
| 
