Why did I choose the napkin to promote as a canvas for software architectural drawings? To be honest, except for my general belief in the virtues of simplicity it´s also somewhat a hommage to a book I recently read: The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.
Dan Roam impressed me with his creativity and his ability to depict the essence of all sorts of stuff in clear and simple pictures - all fitting on the back of a napkin. Before I´ve read his book I either did not give size of architectural images much thought or I complained about the limited size of displays compared to the huge blueprint tables for building architects.
I always envied them for their large sheets of paper filled with all those symbols describing a whole world to be built and lived in. The overview such blueprints provide seemed important to me. In comparison to that, looking at an UML diagram on a 1280×800 screen felt awkward.
That has changed, though, thanks to Dan Roam! I no longer feel hindered in my creativity and expression by a small display. Right to the contrary! I think limited display size or a consciously chosen small canvas help architecting software. Why? Because a small canvas naturally limits the number of “things” you can depict at the same time. A small canvas thus constrains the complexity of the design you can draw. And that´s a good thing!
Traditional building architecture might not need such constraints, since it´s dealing with static objects. But software is a different beast. It´s not static at all, it´s highly volatile, constantly evolving, never finished. That´s why I recommend, to keep depictions of it small.
You probably think drawings like this
source: http://openalchemy.org/index.php/OpenAlchemy_Wizard_Tour
or this
source: http://www.roxsoftware.com/ug/
are the norm and why should it be different. But from the point of view of someone trying to understand (!) what they show they are, well, hard to grasp. Whoever draws a diagram does not have much of a problem with its size. He understands the content perfectly well - otherwise he wouldn´t be drawing it. But once you switch sides and need to understand such depictions, the situation changes. Hours upon hours of valuable time are invested into understanding such drawings - whereas much effort could have been saved, if the drawings were kept smaller and simpler.
If you´re an expert in fuel injection pumps the drawing on the right might be easy to read. But there are always less experts than novices, people who first need to learn about a technical system. They are easily (and unnecessarily) overwhelmed by such images.
That´s why I´m saying: Don´t try to impress anybody by putting everything you know about a software system into just one big picture. Try to walk in the shoes of the many (occaissonal) viewers of it who don´t have much time make sense of a ton of boxes and arrows.
Of course the capacity of the human visual system is mind boggling. We can spot a familiar face in a crowd and scan thousands of images in a folder or on a light table. But that´s “simple” pattern recognition.
Understanding (!) a software architecture on any level of abstraction is different. There might be patterns to recognize, but before that the meaning of the structural elements and their relationships needs to be clarified. And that´s what costs so much time. And that´s what benefits from consciously limiting the size of software architectural drawings.
At times larger drawings for overview might be ok. But mostly you should think “small is beautiful” 
Focus yourself on whatever fits on the back of a napkin. You can use more than one. Help yourself…
Why did I choose the napkin to promote as a canvas for software architectural drawings? To be honest, except for my general belief in the virtues of simplicity it´s also somewhat a hommage to a book I recently read: The Back of the Napkin: Solving Problems and Selling Ideas with Pictures. Dan Roam impressed me with his creativity and his ability to depict the essence of all sorts of stuff in clear and simple pictures - all fitting on the back ... Read More
