Author Archives: Andrew

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.

This is one of those influential books which may make you start to think about problems in a different way. 

A lot of books about architecture concentrate on simple examples and small-scale problems, and you get the feeling that’s all the authors know about. Many books which do address large systems assume that you are building on a greenfield site, or can somehow ignore the legacies if you are adopting more modern tools for your new systems.

By contrast this is a book about the reality of mixed legacy and new technology environments, written by someone who clearly has real experience of large server farms, big databases, high transaction rates and, perhaps most importantly, important legacy systems with hundreds of thousands of lines of code written in COBOL . 

The book starts by discussing typical problems – things like adding new e-Business presentation layers to existing transactional legacy systems, and briefly summarises how a combination of good architectural practices and appropriate technologies can  address them.

The following chapters present a brief history of large system architectures, including transaction monitors, message queuing and client-server approaches before moving on to object middleware with a discussion on CORBA, Enterprise Java and COM and its relatives. This is followed by a more detailed discussion of how different parts of systems can communicate, and how middleware can be classified. A great strength of the book throughout is that Tony is not obviously partial in the Java vs. Microsoft debate, and instead concentrates on their similarities and on strategies which should be able to work in both cases.

The core of the book starts with a discussion on the different types of "transaction" between a system and its clients (users and other systems), and how these relate to business processes. The following chapters then look at three key issues within this context: resilience; performance and scalability; and security and systems management. In each case there is a clear statement of the problems and objectives, followed by an assessment of the relative merits of various possible architectural solutions.

The final part of the book presents a process which should lead to system architectures better able to meet their non-functional requirements. Tony believes the core of the process is development of a good business process model, which then leads quite directly to an understanding of the system’s components and their interactions. There’s some very good advice on practical implementation approaches, and why process modelling gives better results than
traditional functional analysis.

The final chapters also address key issues such as how to ensure data integrity and accessibility, and how to manage change through integration and designing for flexibility, before revisiting the process issues and summarising how the architecture should develop.

Published in 2000, this pre-dates Microsoft’s .NET initiative, the emergence of vendor-neutral messaging standards and the real advent of web services. Each of these will have a major impact on the sort of systems and issues discussed in this book, and you may therefore also  need to read some material more focused on these technologies and others, but that shouldn’t detract from this book’s value.

Overall this is an excellent book, and I strongly recommend it to anyone trying to understand the nature of large, integrated systems and their architecture.