The Process of Software Architecting Book Review

About a year ago I finished up putting together a new Software Engineering Process for the state of PA. It included the best of the best, from those that gave us permission to use their content. You can check out the resources here. A lot of the content was related to architecture. I would have loved to have had this book back then to refer people too as an educational resource. This book puts the process of Software Architecting into a very understandable format and does a great job of explaining process fundamentals. It is hard to train people in Software Architecture, and then add a ton of Software Process Engineering concepts to it and you really begin to lose people. We had very little success in finding anyone who wanted to go through the learning exercise. Only our team used the process for the most part. This book starts out with a great overview of Software Architecture, the Architect, and Architecting. Even if you are familiar with these concepts, they are a good read and they get the context laid for the rest of the book from the perspective the authors take on the concepts. Next the authors give a great introduction to method fundamentals. They pull from the industry’s best practices which include the RUP, OpenUP, XP, SCRUM, FDD, and use the SPEM to do their process diagrams. The do a great job of pulling out the important information that relates to software process engineering and putting it into a very organized and easy to understand format. The chapter is short and to the point. The authors then cover documenting software architectures. In this chapter they outline an architectural description framework based on Rozanski and Woods viewpoints and perspectives, the Zachman Framework, and the 4 +1 view model. The next chapter on reusable architecture assets provides an architecture asset metamodel for development –time assets and one for run-time assets. The rest of the book is a detailed, real world, case study that puts the architecture method to use. The book ends with appendixes, Software Architecture Metamodel, Viewpoint Catalog, Method Summary, and Architectural Requirement Checklist. PROS: Two guys from IBM authored a non IBM centric book. Although he authors both work for IBM they didn’t include or use tools from IBM. The book stays within the scope of process engineering as related to software architecture, which produced a more effective book than if they had not. For example, if they would have tried to provide a treatment of tactics instead of referring us to the best resources available on tactics. The book stays process focused. The appendixes are very valuable references. They use industry standard best practices for all their content. They are not inventing any new wheels here, or trying to sell a new silver bullet. They are simply picking out the best of what has worked in the industry and putting it into a very organized and usable format. I like that they include the requirements gathering phase as part of the architecture process. You usually find the requirements discipline treated as though the architecture team has nothing to do with it. That is just not the case in a healthy process. CONS: I really do not have any. The only thing I would like to see is the process content in the book put into the Eclipse Process Framework Composer. That way it could be offered as a plug-in and we could include it in our process configurations. Overall If you are involved in software development in anyway, you should read this book. It is the story of how it is supposed to be.