ISBN:0131412272From the Inside Flap
Preface
Software architecture is an emerging discipline and an exciting career path for software professionals. We encourage both new and experienced practitioners to read this book as an aid to becoming better software architects. You may have noticed that most software books today do not say much about software architecture. Here, in this volume, we've concentrated the knowledge that you need to be the most effective architect possible.
As co-authors, we have lived through the experience of graduating from "member of technical staff" developers to becoming practicing software architects at the most senior levels of our respective companies. We are technical people, not managers, and we enjoy the technical nature of our work. We enjoy parity of salary and benefits with the senior managers at our respective firms. In other words, we are none-the-worse-for-wear as a consequence of choosing a software architecture career. We think that many of our readers would like to gain from our experience. Hence this book.
This is more than a book about software architecture. It is a field manual that can train you. We choose the pseudomilitary style, because it embodies an essential attitude. As a software architect, you need many survival skills—some technical, some political, some personal. While neither author has military experience, we have seen software architecture become a battleground in many ways. It is a battleground of ideas, as developers compete to forward their own comcepts. It is a battle ground for control of key design decisions that may be overruled by managers or developers, perhaps covertly. It is a battleground with many risks, since architects are responsible for a much wider range of technical and process risks than most managers or individual developers.
If you are a practicing software architect, we know that you are a busy professional. After buying this book, we would suggest that you peruse the table of contents and the index for topics that are new to you. Focus on those sections first. When you have time, we suggest that you attempt a cover-to-cover read-through, to familiarize yourself with all of the covered topics and terminology.
If you are new to architecture and want to become a software architect, we suggest that you do a cover-to-cover read-through beginning with the first chapter. Work the exercises provided, which will add an experiential learning element to your experience base.Raphael Malveau
Thomas J. Mowbray, Ph.D.
McLean, Virginia, U.S.A. /p>
Reviews From AMAZON.COM
Inappropriate analogies for software development
While I admit to occasionally using the phrase "in the trenches" to describe software development, I generally consider military analogies to be inappropriate descriptors of how software is created. A military organization is composed of a rigid command hierarchy where orders are not to be questioned. No software development shop could ever be run in this manner. Military subordinates can be screamed at, ridiculed and within general guidelines that are sometimes exceeded, abused. Once again, that strategy does not work in the business world.
The worst military analogy offense in the book is chapter ten, "Psychological Warfare." While keeping a team functional using psychological techniques is a well-known tactic, the means of psychological warfare are completely different. The authors admit this when in the chapter they utter the sentence; "Mastery of these techniques should provide tools for effective persuasion in both group situations and face-to-face interactions." There are many problems in that sentence. An argument that techniques used to psychologically weaken an enemy in warfare will prove effective in working with team members in a business setting is absurd. Also, there is the key word "should", a weak word indicating that the authors are not convinced that these tactics will work.
This absurdity also appears on the back cover in the form of the blurb, "With hands-on exercises, real-life war stories and a take-no-prisoners attitude, `Software Architect Bootcamp, Second Edition', won't just help . . . " I have no idea how the authors of this book conduct their businesses, but in the development teams I have worked with, that kind of tactic destroys the consensus necessary for people to work together effectively. In fact, I have no idea what a "take-no-prisoners attitude" is supposed to mean in a software development environment.
While I found the military wording to be an unnecessary distraction, there is some good advice in the book. Using architecture in the same sentence as software is a relatively new phenomenon. Recently, the complexity of applications has grown to the point where developers have split into different areas. There are still people who write the code, but now there are others whose fulltime job is to develop and manage the overall structure of the application. These people, commonly called software architects, need to be trained in ways completely different from the code writers. While they need to learn how to put software components together, they also need to be trained in how to articulate their vision and convince people by rational argument. The authors cover the different aspects of software architecture and end each chapter with a set of essay questions that are partially answered.
I really have ambivalent feelings about this book; it does contain a great deal of useful information regarding software architecture. However, the absurd analogies weaken it when compared to others, so that is why I only give it two stars. I would not use it to train software architects.
Very uneven
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.