Review

Eeles, Peter and Cripps, Peter
Addison-Wesley, 2010

As its title suggests, this is a book about process. It devotes an entire chapter to teasing apart the differences between architect, architecting, and architecture. (I struggle to recall ever needing the present participle "architecting" in conversation or writing.) And yet—​somewhere in its precision, the bigger picture is lost.

One challenge is purely temporal. The authors have pinned their descriptions to an early 2000s Enterprise Java and Object Management Group world view that no longer exists. This is a book that, while published in 2010, mentions COBOL but not cloud computing. They write somewhat narrowly from an enterprise and information technology perspective, without acknowledging the different roles and rhythms of commercial product development. While "back office" systems and commercial software development overlap significantly today, it was already true when this book was written. It feels an akward oversight.

The other challenge is, I think, one of perspective. The book presents an almost scientific description of software development processes before describing a "process for architecting", explaining that a process consists of tasks, roles, work products, and phases. These tasks, roles, and so on have a distinctly enterprise-architecture oriented viewpoint. Architecture roles are consistently lead, application, infrastructure, and data. On the one hand the authors acknowledge that these roles might be taken on by just one individual, but no where do they acknowledge that different projects might call for different specializations. This taxonomy seems to rely on a specific architectural approach that—​as noted earlier—​has gone out of style. A discussion of the reasoning behind role specialization would have been more informative.

On a related note, many straightforward concepts are meticulously diagrammed in Universal Modeling Language (UML) diagrams that mostly serve to illustrate how prose is often better.

Even understood as an IT-oriented process for developing software in the early 2000s, I don’t know that it’s all sound advice. In the chapter on requirements definition, the authors assert: "As a result [of architectural tradeoffs], feedback goes from the architect ot the Business Analyst so that the requirements can be adjusted as necessary." That should never happen, and reflects a fundamental misunderstanding of the relationship between requirements and design. A design may not satisfy all stated requirements, but its inability to do so doesn’t change the requirements. And maintaining the actual requirements—​not a corrupted version of them—​is essential to rectifying the situation as the system evolves.

The book contains a few better points. It makes good use of IEE 1471 terminology, and sets a good example in doing so. It makes nuanced points about the differences between constraints and quality attributes in the design process. It does well when discussing the use of views and models for communication. Sadly, these are buried in too much text (and too many diagrams) that become tedious to wade through.

The best professional development books distill essential lessons that persist as technology changes. In that way, they share lessons broader than the narrower circumstances in which they were learned. This book fails that test. It captures the zeitgeist of its time and place too well, reducing its impact over time.