Software Architecture Organizational Principles and Patterns

This book is about how to make architectural changes across an organisation. It’s very much about the softer aspects of selling ideas, getting buy-in, and then seeing changes through. It has wider applicability than the title and very focused text might suggest: although it’s written in terms of "architecture", "architects" and "product lines" it could equally easily apply to "strategy", "strategists" and "portfolio".

This is a practical book, who’s authors have realised that software architecture is about people and processes, not standards or definitions. Maybe it reflects the growing maturity of the field, but this book gets down to the meat in a way that most earlier books didn’t. The book includes some useful material for any architect trying to sell his efforts, particularly real business examples where major businesses succeeded or failed because of the quality and timing of architectural investments.

The book centres on the "VRAPS" model, five central principles which the authors believe are essential to achieving buy-in to an architectural or strategic initiative:

1. Vision: the creation of a clear view of future value, goals, structures and architectural constraints,
2. Rhythm: the idea of recurring and predictable exchange of architectural/strategic deliverables, 
3. Anticipation: the idea of predicting future change, and then validating and adapting the architecture as changes occur, 
4. Partnering: the creation and maintenance of clear cooperative roles, understanding and maximising the value ach receives and delivers, 
5. Simplification: the intelligent clarification and minimisation of both the architecture and the organisation.

The book presents the model in overview, and then in more detail. I particularly like the structure of the five central chapters: each describes one of the VRAPS principles in more detail, with three criteria for an organisation following the principle, three antipatterns which indicate common problems, and three patterns which support the criteria. This makes the book both readable and a good reference source, as it also includes references to other patterns and antipatterns in the same area.

Along the way, the book brings out some very important principles. For example, how organisation and architecture tend to reflect one another. A fragmented, political organisation will generate a diverse, complex architecture, and vice-versa. If you want to simplify your architecture then you need to pay attention to the complexity of the organisation behind it.

The book finishes up with an interesting "case study" of how the principles applied at Allaire, the Internet tools company, followed by the description of a "benchmarking" process where the authors explored architecture and organisation issues at other companies. This includes some very
useful templates, but you are left with the feeling that the sample size was very small, and (although the participants aren’t listed) was restricted to a few close business partners of Allaire. Whether the results of a wider survey would be similar is not discussed.

This is a very good book, easy to read, with a structure and reference sections which will make it easy to go back and re-read relevant information to a specific problem. It is a little specific to "product line" software architecture, and some of the advice needs translation into other contexts, but if you are involved with either software architecture or IT Strategy you will be well rewarded for reading it, and I would recommend it strongly.