Boxology

The Boxology paper seems to represent an wonderfully complete reference sheet in case an architect needs to make their design decisions based on the expected flow of data and control. The tables presented in the latter portions of the paper are precisely the sort of resource I would expect to see printed out and tacked up on a cubicle wall to act as a simple reminder for what needs to be done, or perhaps published in a "pocket guide to Architecture". The problem is that the author has done a wonderful job of laying out way to differentiate theoretical systems based on key groupings, but it seems to exist in a sort of bubble that ignores the fact that a reader may be looking for ways to directly apply this to a project. I found myself looking this document over for the architectural equivalent of a code snippet just to see if I was following him correctly. As there doesn't seem to be that, just those charts and a guiding checklist at the end, I feel the author has left the task incomplete. He has provided us a wonderful rubric but no real instruction on how to go and apply it in our real world.

The second biggest complaint I have is that, like many theoretical papers, they seem to assume that all systems are designed both correctly and coherently, with one major way to handle flow of information or control. While I would love if that were the case my time in the professional world has taught me that due to various business concerns: release dates, promotions, loss, various other HR shuffles, and the sheer power of business cases and market segments means that in all likelihood the system we would use these tables to classify may only fall "mostly", or even only "somewhat" into one of these categories.