Is there a middle way between the traditional Big Architecture Upfront and the Natural Architecture Emergence proposed by some Agile developers? This is the goal of this book that tries to provide guidelines and models on how to include just enough architecture in your software development activities. George Fairbanks proposes to use the risks faced by the project as the main criteria for this approach.
The first part of the book is mainly focused on presenting the risk driven model. The goal is to answer two questions: how much software architecture work should you do, and which techniques should you use? The second part explains how to build architecture models or what to include in them. From a developer point of view, my favorite section is the chapter that deals with decomposition strategies. The book is well written with a good chunk of practice-oriented material and many “further readings” pointers.
At the beginning, George Fairbanks declares that this book is different from other books about software architecture because it teaches risk-driven architecting, it democratizes architecture, it cultivates declarative knowledge, it emphasizes the engineering and it provides practical advice. I am not an expert in software architecture books, but I would say that these objectives are fairly achieved. I will recommend this book to every software developer that is conscious that architecture and design decisions have a long term impact on their application health.
Reference: “Just Enough Software Architecture – A Risk-Driven Approach”, George Fairbanks, Marshall & Brainerd, 360 pages, ISBN 978-0-9846181-0-1
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
“Different developers have had success with different processes. Some succeeded with agile processes that have little or no up-front work. Others succeeded with detailed up-front design work. Which should you choose? Ideally, you would have a guiding principle that would help you choose appropriately. This book suggests using risk to decide how much architecture work to do..”
“Question first and model second. Different models are good for different things. A model that helps you predict response time will probably not help you find security holes. So it is best to follow this simple rule: question first and model second. That is, know what questions you want the model to answer before you build it. That way you will have an easier time choosing its abstraction level and what details it includes. This is one of those rules that looks straightforward but it is easy to violate. If you have ever done any work around your house, you may have heard a similar rule: measure twice and cut once. I have broken that rule many times, and each time I find myself muttering the rule under my breath. I am also a fan of its corollary, told to me by an old friend, “No matter how many times I cut it, it doesn’t get any longer!” You may get lucky and cut it the right length, but why not just measure it again? Similarly, you may get lucky and build a model that does what you want, but why not decide what questions it should answer first? That way the model will be sure to help you.”
“This book advocates attacking complexity and scale by building models. This is the long way around the commuting diagram, but it should help you solve problems that you cannot solve directly. You should always remember, however, that the goal is to build a system that solves a problem, not to build models. Models are not running systems and you cannot eat a picture of a sandwich. It is possible that your temperament may incline you to believe the problem is solved when the software is designed, but ensure that you validate your model by building a prototype or demonstrating it in the real system.”