Boxology

Architecture is important. But there's more to architecture and systems engineering than drawing boxes. Among other things, it means knowing that these are the right boxes. As a rule of thumb, if there are more than 10 boxes, you've probably got the wrong boxes. Beware of diagrams like this one, for the US Navy's Theater Air-ground System (TAGS). The images here are unclassified and available to the general public through Naval Warfare Publication NWP 3-30. 

 

The system itself might be fine, but the diagram gives no confidence in that. It's just too complex. To drive the point home, here is the legend that goes with this diagram:


How much of that complexity is intrinsic and how much is incidental? It's very hard to tell. Undoubtedly, the boxes were drawn at the wrong level of abstraction. Choosing the right level of abstraction is the essence of creating and understanding patterns. That's because the role of abstraction is to:
  1. Eliminate incidental complexity, and
  2. Expose intrinsic complexity. 
In order to do that well, the team building the abstraction needs to recognize the difference between the two different kinds of complexity. Software engineers are supposed to be the experts at abstraction. But sometimes even they get carried away. The example below is a UML class diagram from NASA's Planetary Data System (PDS) program. Too many boxes! The diagram proves that its maker knows how to use CASE software to create UML diagrams, but it doesn't prove that its maker knows how to give a meaningful abstraction of a system that minimizes incidental complexity. 

NASA Planetary Data System v.4