Author Archives: Andrew

This is a very good, practical book. I found it very readable, with just an appropriate level of textual detail in most cases. It’s the first book I read which tries to tackle the problem of modelling and understanding Enterprise-level system interactions (this predated Tony Britton’s excellent book). If anything, Paul sells it a bit short by tying it to "e-Business", since a lot of the ideas and disciplines can apply to less forward-looking Enterprises who are trying to solve traditional integration problems but who may not identify with the e-Business tag.

The early part of the book discusses the principles of component-based development (CBD), and how this can be combined with process modeling to both help improve the business, and to provide a clear model for the systems needed to support it. Importantly, Paul sees the development of both business processes and systems as something which must happen progressively, so neither has to be the subject of "big bang" changes.

The next section of the book discusses the different types of components, and their role in a typical architecture comprised of both new and legacy systems. Paul then introduces his "CBD Process Framework", a way of defining components and then "provisioning" then by the most appropriate combination of new development, purchasing and re-using existing assets.

The core of the book takes a typical business process (car rental) and develops a worked example of the various business, logical and physical models which are required to define the component architecture. The models are each taken through several stages, corresponding to an evolving e-Business process and a system which is growing incrementally. This is much more realistic than presenting the final model "as is", and allows much better understanding of how the model develops. In many ways this is the part of the book which delivers the greatest real value.

The final part of the book discusses different provisioning and funding strategies for CBD, and how an e-Business team should be structured.  There’s a lot of good stuff here, which may be very useful to someone new to object- and component-based development. However if I’m honest I found this less useful, since there are better specialist books on this subject and it doesn’t hold the interest as well as some of the earlier sections.

As an Appendix, Paul presents descriptions of all the major component technologies, and all the major UML-based modelling techniques. This could be a valuable reference for anyone.

I have one slight reservation on the book’s core – Paul follows a convention in which an "interface" is a collection of types, and says that "by convention" the interface includes access to all the types. This is a bit different to the Microsoft model, for example, and may make it more difficult to establish good navigation around the object model, or to support "stateless" models. However, this is something to be aware of rather than something which should detract from what is otherwise a very useful tutorial.

I like this book. The worked examples of developing the e-Business model are excellent, so much so that I now recommend this book to anyone trying to model such things using UML. 

This is a good book, but with a shorter book trying to get out.

I’ll be honest, I was really was looking for a book called something like "Enterprise Java for an Architect who knows a lot about Microsoft DNA but not much about Java". This is the closest I’ve found. It is a very good presentation of how the different elements of the J2EE stack are meant to
fit together, common problems and patterns which address them.

There are some very good things about this book. It really tries to explain the design forces which lead to good and bad solutions, and does try to put all the different patterns into the context of a "roadmap" so you can see how they link together. One of the best ideas in the book is actually in the epilogue, where the authors introduce the idea of building an architecture via a UML diagram built from stereotypes for the patterns. I can see this being widely adopted as a useful technique.

The big problem with the book is it is dreadfully repetitive. It’s not sure whether it’s a textbook, a reference book or a design tutorial, so it tries to be all three. The same text gets repeated over and over again, not only between sections but even within a section. By attempting to make each pattern, and each
"strategy" within a pattern self-sufficient there’s an awful lot of repeated text, sometimes even on one page. Some patterns almost exact copies of one another and should arguably be strategies for a single pattern. Text is often repeated between the "Problem", "Forces" and other
sections of the same pattern, where a better  trade-off would be references to a single list of more detailed descriptions. At the same time there are too many self-references in the text, even back to the start of the same section!

I found the repetition and overlap between the "design considerations", "bad practices" and "refactoring" sections confusing – it would be better if they all formed part of a single roadmap with the main set of patterns. There’s an established concept of "Anti-patterns", which could easily serve for bad practices and refactoring ideas, and these could also be reflected as part of the "forces" for the  patterns.

Adopting all of these patterns could lead to a very complex layer structure, with a great many classes involved in the simplest task. Several patterns seem to be about wrapping the complexities of J2EE, and you wonder whether there ought to be a more systematic solution to this. The book doesn’t discuss
"managing complexity in the design", but if it did it might come up with some simplifications.

While I’m not aware of an equivalent book with a Microsoft focus, with a little effort you could also apply many of these patterns in the Microsoft world. However, there are some good Visual Basic patterns books which show how this should have been written. A provocative idea – does the difference between this and equivalent VB books reflect the difference in productivity of the languages?

My advice? If you need a good J2EE design pattern reference buy this book, but don’t try to read it cover to cover.

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.