Last year I attended the first edition of the GSAS conference. The speaker roster was impressive and included George Fairbanks. Was because of it that I decided to read Just Enough Software Architecture, a risk-driven approach.
The outcome of the conference didn't live up to my expectations. The tone felt distant and somehow settling a differentiation between architects and developers, some kind of elitist barrier (and here for sure I am failing to describe precisely my impressions due to lack of English vocabulary). That was weird because most of the talks, the one from Fairbanks included, were not explicitly suggesting it at all.
Turns out I got a similar impression from the book. There is valuable information on it, that's for sure, but the tone and a big part of it feel distant, maybe too academic, despite of Fairbanks efforts to provide meaningful examples and an informal tone.
The book is structured in two main blocks. The first one introduces Risk-Driven Software Architecture, its main highlight and indeed an interesting approach. How you should architect your application based on the risks and quality attributes you know it requires, doing the right trade-offs to find a balance between deliverability and engineering. For instance, do not build an astonishingly scalable system if none of your quality attributes is performance. The way Fairbanks introduces this technique is enjoyable and well-illustrated, with solid examples for all of the standpoints.
The second block, though, is composed of thoroug descriptions of ways of representing models of the architecture, at different levels and with different techniques. This translates to, and I know I am oversimplifying here, diagrams.
Almost two-thirds of the book revolves around levels of detail, types of architecture representations, and the relations between them. The amount of theory and detail is noticeable and it is hard to relate big chunks of content to what I currently need as a software developer ( which might mean this disappointment is caused by a mix of expectations and momentum in my career). It took me a lot of time to finish the book because of the low engagement with this second block, especially after a first one way more practical and concise.
Coming back to the conference perception, there is good stuff in the book and some things I will definitely take into account in my current and future projects. But at the same time, there is something hard to describe about it that made the reading not satisfactory. A contradiction between an approach to architecture encouraging doing just the necessary, and a tour about theoretical aspects of model representations that feel like way more than the necessary.
A first part that relates to software developers and a second part that relates to architects.