Software Architecture: Foundations, Theory, and Practice is a landmark text that will become an essental introduction to the discipline of software systems architecture. If you are a student, tester, manager, methodologist, developer, or simply an architect, and want a holistic understanding of what real software architects think software architecture is and why it matters, this is the place to start.
I bought this after Roy Fielding (of REST and HTTP fame) mentioned it on the rest-discuss mailing list. Roy is one of the industry's top architects, and I wasn't disappointed. The book is timely - architecture is coming to be accepted as an important activity, especially for distributed, and large scale systems. What many people don't realize is that drawing pictures, writing documents no-one reads, meta-modeling, and pontificating on "concerns" are not software architecture. Software architecture is about introducing constraints via principled, objective design to achieve particular system properties. Architecture is difficult and exhausting work, but done well can offer immense value to users and stakeholders. This book, along with Rozanski and Woods' "Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives" makes that explicit.
The book is unapologetic about software architecture's standing in the industry. SAFTAP positions architecture as the primary design activity for software - not development, not requirements analysis, not testing, not methodology, but architecture. That will make for interesting debate.
My single criticism of this book is that it does not do enough to treat user experience (Ux) and informatics as architecturally significant, but not enough to take away a star. I'm hoping a future edition will rectify that.
Some noteworthy chapters in the book (there are 17 chapters in all):
* The Big Idea: explains what architecture is and why it matters. The building metaphor (often heavily criticised in the industry, see the excellent "Software is not Bricks" by Raganwald) is dealt with calmly and then put to one side.
* Architecture in Context: explains how architecture fits into the overall lifecycle and process of software systems.
* Connectors: this is one of my favourite chapters. The concept of a connector is vital to a software system, but is rarely if ever discussed in programming or engineering texts.
* Modeling: probably not what you think. This chapter emphasizes communication, clarity and disambiguation over notations and diagrams.
* Implementation: programmers hate the quip "implementation detail", but in truth many things in a system are just that and it does not mean they are unimportant. This chapter covers those details and why they matter.
* Deployment and Mobility: good architects understand that a systems have a life well beyond initial delivery, which is where most developers, managers and stakeholders tend to focus attention. This was one of favorite sections as the running system simply doesn't get enough attention in most projects today.
* Applied architecture and Styles: covers some examples of architectural styles, notably REST and SOA, which are certainly the best known architectures in my part of the industry.
* Designing for non-functional properties: many non-functional concerns don't start to matter until the system is deployed and there isn't always agreement among technical specialists over what's truly important. If you are technical specialist this should help you articulate the cost/benefit of looking at the "unfeatures" of a system.
* Security and Trust: software is increasingly distributed, and increasingly a super-system of components interacting over the Internet and Mobile Networks. So it's good to see a text that makes security a first order concern and not just a non-functional ones.
* Domain Specific Software Engineering: I'm trained as an industrial designer where the notion of common modular components with standard interfaces acting as a platform for product development is a known Good Thing in domains such as the automotive and consumer electronics industries. This chapter gives a good overview of modular design focusing on the software product lines approach. The example given is from Philips, but it could as easily have been from Toyota.
* People, Roles and Teams: software architecture, like other architecture disciplines, has a strong social dimension. This chapter explains how the architect role fits into an organisation and where they can add value and exert influence.