If just like me, you lost faith in models and model-driven engineering (MDE) a long time ago, this book might help. It shows how to reconcile architecture and modelling with agility and maintaining real software.
Just enough software architecture advocates modelling software until we feel confident enough to proceed with writing code. That is, if some technical risks (availability, maintainability, etc.) are not yet under control, then we should (re-)think how architectural decisions that could help. G. Fairbanks answers many questions: Which models to use? For what purpose? What to model, and to what extent? And, how to reduce the model-code gap?
George Fairbanks has strong credentials. He holds a PhD in Software engineering (Carnegie Mellon University) and has been involved both with Industry and Academia. George focuses on software architecture and software engineering in general. He joins (and speaks something) at both academics and industrial event on software architecture.
Just enough software architecture covers a lot of ground. The first part describes how to risk-drive software architecture. It introduces software architecture and explains how this helps mitigate technical risks such as high availability, maintainability, portability and other “ilities”. Tradeoffs are critical here because many of these quality attributes inherently conflict with one another. Part II focuses on how to model software architecture and overviews its core concepts, such as components, connectors, views, constraints, relationships, patterns, styles, etc. Besides, the various references to books and academic articles give an interesting historical perspective.
It is several years since I had read anything about modelling and software architecture. I think this book is an excellent entry. I like the writing style, and I find the examples relevant without being overly complicated. I definitely recommend it to beginners: It’s full of pointers and covers a broad range of topics.
But seasoned architects might also like it. I like George nuanced approach to modelling (and BDUF), as opposed to agile. His risk-driven idea makes it problem-specific. I do not model for the sake of it, and I am regularly punished for jumping at my keyboard too eagerly.
I also like the discussion of the model-code gap: Some insights and architectural decisions (especially rationales) cannot show up in the code. While the advocated architecture-in-code idea seems a step forward, it only partially addresses this gap. I am curious to see what other solutions have been tried and tested.
Eventually, I give it 3.5 stars. I think it is an accurate introduction to software architecture, in practice, but, even though I am not an expert, there was a lot I already knew.