Book Review: The Process of Software Architecting

Software architecture developed as a profession with the increasingly high-level and comprehensive understanding required for OOP paradigm. There is a plethora of definitions available for these two words in different contexts and mentioned in various standards and consulting company documentations.

In the The Process of Software Architecting, the authors start with discussions of the various definitions and terminologies associated th the Software Architecting field and go on to illustrative test cases and project scenarios where the issues and possible solutions are discussed.

The book is divided roughly into three parts. The first part gives briefly the core concepts of architecture, architect and architecting, documenting a software architecture, and reusable architecture assets. The second part provides a guided tour through a typical software development project. The last part brings out how the concepts described in the preceding parts apply to architecting complex systems.

The task of the software architect comes in between the requirements phase and the development phases in a software development project. Initially the architect has to make a logical architecture based on the requirements which have to be made into a logical detailed design in the development phase. Based on the inputs of requirements, logical architecture and logical detailed design, it is the job of the architect to create physical architecture taking the available technology into account.

Some of the architecture related best practices in the industry are the Rational Unified Process, IBM Unified Method Framework, OpenUP, eXtreme Programming(XP), Scrum, etc. In addition to these, one of the standardization initiatives like the Software and Systems Process Engineering Meta-model Specification(SPEM) is also considered for the discussion on method elements.

Few of the other notable aspects of this book is the need for accommodating differing viewpoints through accounting for the political landscape within the respective organization, the necessity to avoid ivory towers by a team of architects too engrossed in discussions to get the feedback from the end-users/management and taking the decision to reuse architecture assets or not based on several factors.

To summarize the review, with a highly condensed text and examples, an experienced software architect would keep coming back to this book to have the improved understanding of principles, best practices as well as avoiding the pitfalls in this developing field. Drawing heavily from the software engineering principles, the book goes beyond finalizing the perfect software architecture document into the evolution stage of software architecting as an art to software architecting as a science.