on 24 February 2003
With this book, Paulish describes how a software system's architecture is not only a separate "high-level design" phase. Rather, he argues that the architecture of a system being built can be used for virtually all activities related to the development project - and should be used. He elaborates on how an architectural description can be an input to the project activities, and how it in its turn is affected by these. For example, he stresses that resource planning cannot accurately be done unless there is an architecture to divide work from - and argues that this is a reason why so many software projects overrun their budget and schedule. Although the concept of software architecture has been around for a while (see e.g. other books in the SEI series), this book takes it from the product level to the project level. And does so very well.
To his credit, Paulish does all this without describing an "ultimate" or "complete" method. Rather, he discusses how project activities in existing project schedules can be improved by focusing more on the architecture of the software being built. Nevertheless, this of course requires conscious modifications of the work in a project.
To my personal great sorrow, the book explicitly "does not focus on project management practices for software products that are mostly being maintained rather than developed". I believe the activities of maintaining, evolving, and integrating legacy systems would benefit from being "architecture-centric" as well, and so I look forward to forthcoming books dealing with that area. This said, the book is not less useful for the area it does deal with: architecture-centric software development projects.