Top positive review
32 people found this helpful
My new standard architecture framework
on February 6, 2012
I want to start by countering the negative review that is currently viewed as the most helpful here on Amazon. The reviewer did not like that the book did not seem to address most directly what would be needed by "project managers, team leads and most importantly developers."
I'm going to suggest that the reviewer started reading the book with a preconceived notion of what a software architect is, and what software architecture is about. It's no surprise. I'm reading several books on software architecture; all of them confront and try to address what might be a common definition, given that there are so many ambiguous definitions throughout the world.
The authors of this book make clear that ALL of the stakeholders in a software project must be appropriately addressed. That's a huge challenge! From business executives to analysts to even project managers, team leads, and developer, all of them must share a common understanding of the entire system and what will be changed. If the architect is primarily thinking about how to communicate with the development team, then that architect should have her title changed to development lead or chief engineer.
It was by reading this book for the main purpose of understanding what a software architect really is responsible for, that I can now easily distinguish the software architect role from other roles. The responsibility is to everybody that has a material interest in the project.
And how can one possibly communicate appropriately to people whose interest and technical acumen will range as wide as is possible throughout a business? That's exactly what this book explain precisely how to do, in a way that will make sense to the developers, the project managers, the executives, the project managers, the operations staff, the security team... everyone.
It does not (nor does it claim to) teach how to apply software development design patterns to construct a component, nor how to correlate a sequence diagram of a system with its structural diagram, or any of the other concerns that are probably best left to the development leads.
It does, however, consistently encourage and recommends strategies and tactics for keeping the level of abstraction at the right level for the stakeholders to which you are attempting to share that one software system solution. Architecture is not about the world of details (where developers live) -- it's about the world of models which, as a necessity, must remove details that are not necessary for all stakeholders. The model must be correct, but it must also be shared by all. That's the responsibility of the architect.
This book is definitely worth reading if you already believe that software architecture is your field, and feel overwhelmed at trying to grasp the scope of your responsibilities and the ever-changing nature of what an architect's value should be. It has a permanent place on my bookshelf, and I'll be referring to it quite often over my career.