Many software developers have a notion of the software architecting process, but I would guess that few of them have a text that adequately describes it in a readable style with effective practices.

The Process of Software Architecting delivers that text. In my experience, many software problems arise because of a poor or misunderstood process rather than any individual people's errors. A book is an effective means of communicating processes, and organizations can use this one as a baseline that they can then adapt to their immediate needs.

Authors Peter Eeles and Peter Cripps bring significant industry experience to the practical discussion of software architecting in their book. They begin by outlining the book's organization and objectives and proceed to fulfill both endeavors, much as an architecture might do. They define useful terms and vocabulary to help communicate the architecture. They discuss architecting basics and later go beyond them in a realistic case study, but I particularly liked their work securing the basics before moving forward. They discuss both logical and physical architectures and identify the tasks to create them.

This is definitely a hands-on book that present a process ready to use. As a software designer and developer, I tend to like diagrams to communicate processes. This book is full of them. The authors do a great job of augmenting their process discussions with easy-to-follow diagrams and task descriptions. They use the Software Process Engineering Metamodel (SPEM) for diagrams and identify SPEM icons so that newcomers to them won't be confused.

With so much industry competition encouraging the use of proprietary technology, I especially appreciated the book's generic presentation. Both authors have significant IBM experience, but their process doesn't reflect using IBM-centric tools.

Software architects and developers alike would do well to get this book. Requirements might be what drives an implementation, but architecture is a critical step in the software design life cycle. If the software architecture isn't appropriate or if it's missing key features, the requirements can end up in an implementation that's neither easily understood or maintained. This book leads organizations to a process that will capture key features and adequately document them.

Everyone from entry-level developers to experienced architects can benefit from this book, even if it's simply to confirm notions that they have an effective software architecture process. The book has an accompanying website with additional information and author contact information. I really enjoy this additional resource when a book provides it.

After reading this book, I can see ways to refine the software architecture process I've come to know. I plan to take use this information to better fulfill the architecting role in my projects. I hope this book does the same for you.

Scott Brookhart is a software engineer. Contact him at sbrookhart@alumni.utexas.net.