Full disclosure
Firstly, I should state that I worked as a consultant to a project for Eoin Woods on a project for four months at the end of 2005.  Should you want a second opinion, then there's plenty of reviews on Amazon and I didn't write all of them ;)

So.  You've been working on your project/application for a while now.  Gradually, the more senior members of the team have left or have been pulled onto different activities and more questions around how to enhance the system have been heading your way.  You've read all the patterns books and you're pretty sure you know good and bad design when you see it. You're the lead developer.  Next stop, architect.  That is, once you've figured out what one is actually supposed to do...

So, can this book help?

The back cover of the book says:

Software Systems Architecture is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices. It shows why the role of the architect is central to any successful information-systems development project, and, by presenting a set of architectural viewpoints and perspectives, provides specific direction for improving your own and your organization's approach to software systems architecture.

Without even opening the book, the idea of viewpoints and perspectives really struck a chord with me.  Separation of concerns is a well documented and understood principle in application design but how to apply the same principle in architecture seems to get less coverage.  With so many aspects to consider, most of which are inter-dependent, and no shortage of options for presenting the information I was intrigued to see if the authors had managed to set out a robust approach.

One of the key differences between the designer and architect roles is that the architect spends less time trying to persuade a compiler to do what they want and more time using 'soft' skills to engage with the various system stakeholders and find the best balance between their requirements.  The book offers valuable guidance on how to identify the various stakeholders and engage with them to ensure that there are no nasty surprises late in the project.

The book takes a technology-neutral standpoint and is independent of any development lifecycle.  It covers an exhaustive variety of topics from identifying stakeholders and using scenarios to test your architecture to whether or not you should assign explicit priorities to threads.  It also includes a number of helpful real-world anecdotes and examples.

I've definitely been guilty in the past of starting out with a clean, focused diagram and then gradually cluttering it with notes and concerns that should really be on a separate diagram, or not in a diagram at all but in a table.  One of the especially useful features of this book is the advice on the best format to present each type of information, e.g. component design, deployment, data ownership, security threats complete with examples.  This is one of the many areas where this book provides practical help based on years of experience.  The book also crucially recognises that you're unlikely to have time to do everything, so it helps you identify which are probably the most important artefacts and which aspects you really can't afford to ignore.

Pushing myself to find any areas where I think the book could be improved, I came up with the limp suggestion of including a quick reference overview diagram or two inside the inside the from and back covers.  Just a summary of the viewpoints and perspectives, their relationships and the most interested stakeholders would be a useful addition.  What would be even better would be a companion CD with example artefacts and document templates to present to stakeholders as I do believe that this book could provide the basis for a standard architectural design process.

This is a book that I wish I'd been able to read years ago because it widens the reader's horizon to include aspects of getting a system designed and built that as a developer you take for granted.  That said, it's a book that particularly resonates once you've had some experience in an architectural role and had an opportunity to make some of the mistakes identified in the especially useful 'Problems and Pitfalls' section in each chapter.  It's well written, concise (despite being over 500 pages) and compelling to read for those interested in what being a software architect really involves.  Very highly recommended.

More information and sample content from the book can be found here: www.viewpoints-and-perspectives.info