Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [Hardcover]

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.

Some might look at my book collect and think I have hoarding issues. If I had to pick just one Software Architecture book to keep, this would be the one.

This is the second edition of one of the best books written on software systems architecture. If you are in the software development industry, you should read this book. If you are a Software Architect, you must read this book.

This book covers a vast amount of material but it ties it all together in a way that paints a complete picture of what software systems architecture is all about.

The book starts out covering architecture fundamentals. There is a chapter on Software Architecture Concepts, Viewpoints and Views, Architectural Perspectives, and The Role of the Software Architect.

It then presents a process for software architecture and explains all the elements involved with the process. This part of the book contains chapters on The Architecture Definition Process, Concerns, Principles and Decisions, Identifying and Engaging Stakeholders, Identifying and Using Scenarios, Using Styles and Patterns, Producing Architectural Models, and Evaluating the Architecture.

Next is a viewpoint catalog. The part of the book goes into the details of the different viewpoints the authors recommend considering as part of you architectural analysis. The viewpoints include Context, Information, Functional, Concurrency, Information, Development, Deployment, and Operational. Each viewpoint is a separate chapter. This section ends with a chapter that show how to achieve consistency across views.

After the viewpoint catalog the authors present a perspective catalog. Perspectives ensure that quality properties that cross several views are accounted for and analyzed. The perspective catalog includes Security, Performance and Scalability, Availability and Resilience, Evolution, Accessibility, Development Resource, Internationalization, Location, Regulation, and Usability.

The book ends with a chapter that ties everything together and a nice appendix that shows the relationship of the author's Viewpoints and Perspectives to other processes. They include Kruchten 4+1, RM-ODP, Siemens, SEI's Views and Beyond, Garland and Anthony, IAF, Zachman, and TOGAF.

I am lucky they came out with a second edition because my first edition is getting pretty beat up. It has scribbling from tons of different projects in it. The first edition has not left my side since I purchased it and this second edition won't leave my side either.

One of the things I like about this book is that the authors complete the picture. They don't say here is one example of a pitfall, concern, or tactic, they present a nice long list that really helps lead you through the process. Keeping this book handy helps me think of things I am sure to overlook.

Another thing I like about this book is that it is not a reinvention of the wheel. The authors do a great job of incorporating industry best practices that have withstood the test of time, as well as included all the newer elements of software architecture that have come about in recent years.

If you have the first edition, the second edition is worth getting. There is updated information scattered throughout the book as well as a new Context viewpoint. There has been 132 pages added.

I said this about the first version and it still holds true with the second edition... Even if you are not an architect it is a great book to buy so you understand what to expect out of one. I may buy a few extra copies to give out on projects so they understand why I am supposed to be there. Anyone reading this book should have a great and complete understanding of architecture and the value it adds to a project.

This was an exceptional review on the entire practice of Architecture. Throughout this work, the authors provide very detailed (yet easy to read) guidance on every element of view-based architecture. This book provides an enterprise perspective of the practice of architecture and outlines all of the things to watch out for at various stages of system design.

I would recommend this book both as a comprehensive briefing as well as a reference book if you are an architect.