Customer Reviews

Software Architect Bootcamp (2nd Edition)

5 star:		(5)
4 star:		(4)
3 star:		(7)
2 star:		(2)
1 star:		(13)

 

 

Like the famous description of soccer, this book is very much a "game of two halves". Half the book, maybe more, discusses the role of a software architect - the architect's approach, attitude, responsibilities, processes and techniques. This is excellent: clear and concise, encouraging if you are a newcomer but still stimulating if you are a more seasoned architect. It is without doubt one of the best descriptions I have read.

Unfortunately, the other half of the book is less useful. The technical parts are either too simplistic, or too detailed when discussing a particular solution favoured by the authors. The text frequently tends to become a repetitive and thinly-disguised commercial for CORBA, and there is an obsession with standards such as RM-ODP which are simply not relevant to a great many commercial developers. The few examples are very simplistic, with no real discussion of many of the technical issues which a real architecture must address.

The book would have been much better for more care in its editing and presentation. The quality of proof-reading is in general poor, but becomes quite appalling in some of the technical sections - evidence perhaps that the authors allowed their technical stance to dictate a poor choice of word processor. The choice of diagrams seems random: some are good, but some difficult discussions cry out for a diagram (horizontal and vertical partitioning, for example), while in other places a diagram confuses where the text is clear. The reference list is incomplete, omitting even the authors' "primary" reference which is quoted, frequently, in the text. All this is doubly disappointing when you consider that one of the authors is the series editor, and both were co-authors of the excellent "AntiPatterns" book.

My advice: if you are happy with the technological side of software architecture, and want advice on how to be a better architect, then buy this book, but read chapters 5 through 9 before you even attempt to read the first part. If, however, you are seeking technical guidance in the real world of software from Microsoft, Oracle and a host of legacy systems, then look elsewhere.

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.

The title of this book is appropriate because bootcamp is an intense indoctrination of fundamental skills and discipline. Bootcamp prepares recruits for the real world in which they are further trained in a specialty and become part of a team that has a shared mission.

In the case of software architecture, this book's approach to bootcamp is narrow in that it focuses on component-based architecture instead of a more general and encompassing treatment of this aspect of software engineering. Despite the narrow focus, this book covers some important fundamentals that will serve the new or aspiring architect well in his or her career path or job.

What I like most about the book is that it's independent of vendors and products. The foundation is, instead, based on standards and methods that are important to the discipline of software engineering in the component-based development domain. An excellent example is RM-ODP (Reference Model for Open Distributed Processing), which allows you to decompose an architecture into viewpoints to examine specific dimensions of requirements. Even if you do not adopt RM-ODP, the paradigm is a great foundation for architecture. Moreover, the Unified Modeling Language (UML)is placed into context with respect to architecture. Finally, although I personally believe CORBA has some problems, the mechanics and concepts are solid foundation material for understanding object request broker infrastructure as one building block of an architecture.

There are some things I do not like about the book. The oscillations between high- and low-level details are akin to a roller coaster and it's disorienting to a reader who is intent on learning the basics of architecture. The lack of good editing makes the book read like a patchwork instead of an "intense indoctrination."

Editing and writing problems notwithstanding, this book is a worthwhile (if ponderous) resource on an important aspect of software architecture for the new practitioner. Although the focus is on component-based development, the fundamentals can be extended into a more general view of architecture that will prepare the architect for his or her specialization in the real world.

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.

Written in an unusual style, Bootcamp had immediate appeal. My first reaction as a practicing Architect was that I didn't need a Bootcamp and the material would be too basic. I was pleasantly suprised.

Scattered throughout the book are numerous focus sections written in the style of Essays. I consider some of the material "very basic" but good for novices and a strong wake-up call to long time practicioners about the essentials of being a Software Architect.

The book was co-sponsored by the Worldwide Institute of Software Architects (WWISA, ... ). I urge anyone interested in the developing profession of Software Architect to visit the site.

Bootcamp provides not only useful details on just emerging Software Architecture approaches but places many of these within a historical framework - more than you would gain from a simple survey of the supporting white and academic papers.

Bootcamp is also a decent journeyman's How-To. In my first pass, I jumped around to different sections that gained my interest and was rarely disappointed. From an introductory section on the use of UML to a small section (9.9) labeled Psychological Akido: Guarding your Gourd, I found Bootcamp to speak to our (Software Architects) current needs.

Bootcamp rarely travels into a fuzzy haze. I do believe the authors' zeal for RM-ODP came across a bit too strong - but perhaps they know something I do not know. I am on my second pass through the book and have a better understanding of the goals of the work.

I recommend Bootcamp for novices and experts alike. It is a good starter kit as well as providing comfort to all practicioners that they are not alone.

To be fair, I have not completed reading this book, and probably won't. I have sufficient evidence though to arrive at the above conclusion.

One of the first things I noticed when I began reading this book was the abundance of typos and tortured phraseology. I found myself re-reading sentences several times only to finally realize that a word was missing or tense was incorrectly applied. The sentences were also choppy and not connected well.

Once could argue that these qualities are superficial and we may give the authors a pass on this aspect if the information contained is useful. Well, as I have not read the entire book, I don't really know how much is useful. I do know, however, that the authors have extremely biased and, in my opinion, faulty perceptions about various things, include OO programming and Microsoft technologies.

The authors complain incessantly about the "failures" of OO and the virtues of component-based development. I agree that CBD is a very useful approach. I discount though the fundamental premise of the authors that OO is faulty and CBD is the next Holy Grail. I would argue that, in fact, CBD is merely a natural extension to *good* OO design. Apparently, the authors have never been on a project that adopted rigorous application of fundamental principles of OO, such as design by contract, the open-closed principle, cohesion, low coupling, etc. Indeed, CBD facilitates some of these principles but certainly doesn't supplant them.

The authors' love of CORBA was also annoying. No doubt, CORBA is significant and has a place in any good book on systems architecture. Microsoft technologies, however, were slighted (sometimes subtly, sometimes not) and ridiculed. No mention whatsoever was made, for example, of the very significant .Net initiative (or if there was, I couldn't find one).

Fortunately, I saved my receipt.

Fifty bucks I should have spent in a bar, talking to someone who is a practicing architect. The book has two excellent features: every word is spelled properly and the back cover blurb is captivating.

The problem is, the blurb isn't true. Not a single war story. Precious few examples. Lots of discussion of industry standards. Anything Open is good; anything Microsoft is bad. Rational's UML was the only analysis approach discussed.

It's a shame Prentice-Hall didn't devote an editor to the tome. The series editor was a co-author. He should know that you cannot edit your own work. The language is twisted and incorrect, to the point of unreadability. We're not talking John Milton here. These are errors Word's grammar checker would have found.

The graphics were similarly arcane. The author refers to the circles in figure 3.2. There are no circles in figure 3.2.

The most useful prescriptive delivered was a ten step waterfall development methodology. But that's nothing new.

I'd like to take the title, jacket blurb, and concept and see it done again by a practitioner, not someone who had a three hundred page contract to fulfill.

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.

The book starts out great, talking about the architect role and what an architect should and shouldn't do. After a dozen pages or so, it dives into a prolonged and repetitive discussion of COM+ vs CORBA, mislabeled as "Basic Training". Towards the end of the book, the author returns to relevant subjects and makes many excellent observations on the human factors to consider when doing architecture work.

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.