“Just Enough Software Architecture” is book that provides guidelines and models on how to include just enough software architecture in your software development activities, following an Agile approach and using risk as the main criteria on how much architecture to include in your current software development activity.
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 book uses the Unified Modeling Language (UML) notation. UML is considered as a ubiquitous language and the addition of architectural notation that have been included in UML 2.0 make it visually closer to special purpose system and software architecture languages.
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
Quote
“This book’s pragmatic advice is to use UML for architecture models unless there are strong arguments against it. Unlike other ADLs, UML has modern tool support from many vendors and the biggest base of developers who know how to read it. It is not without problems, but it works well enough and there is plenty of advice on how to use it effectively. While there is likely an ADL out there that better suits your needs, it will have tool support from a single vendor at most, and few developers will know how to read your models. UML has the additional benefit that it works for domain, design, and code models, so you will not have to switch languages.”
“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.”