Where To Start?
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra
With Edsger’s delicious quote in mind, let’s explore seven levels of abstraction that can be used to reason about big, distributed, systems:
At level zero, we have the finest grained, most concrete unit of design, a single puny line of “source code“. At level seven, we have the coarsest grained, most abstract unit of design, the mysterious and scary “system” level. A line of code is simple to reason about, but a “system” is not. Just when you think you understand what a system does, BAM! It exhibits some weird, perhaps dangerous, behavior that is counter-intuitive and totally unexpected – especially when humans are the key processing “nodes” in the beast.
Here are some questions to ponder regarding the seven level stack: Given that you’re hired to build a big, distributed system, at what level would you start your development effort? Would you start immediately coding up classes using the much revered TDD “best practice” and let all the upper levels of abstraction serendipitously “emerge”? Relatively speaking, how much time “up front” should you spend specifying, designing, recording, communicating the structures and behaviors of the top 3 levels of the stack? Again, relatively speaking, how much time should be allocated to the unit, integration, functional, and system levels of testing?
As always, your pieces are “far-out” !
I wonder whe infrastrutures and superstructures are in you diagram or how can we link to them. (NOTE the “s”, the plural of the “extra” – structures ! ) see: benking.de/systems/encyclopedia/ I wonder also if you are aware of “my” Cognitive Panorama. http://www.benking.de/systems/encyclopedia/newterms/ good day & good luck ! HEiner
Ooops I meant the link http://www.benking.de/sysrems/codata and there the MIST conference. Sorry !
Sorry my typos on a mobile in a train. Type syTems with “t” above….
Typically, I consider the top 4 levels to be my territory (all five when I’m not only architect but designer & coder as well). Jeff Sussna put together an excellent post that talks about a holistic style (http://blog.ingineering.it/post/70423583524/lean-architecture-and-holographic-design) that moves back and forth between those levels rather than trying to trying to start at one and then complete it before moving on.
For my own $.02, I’d say that having a good handle on the architecture of the problem is critical before moving on to the architecture of the solution. Otherwise you risk building a pickup when you need a sports car (or vice-versa).