The Architect´s Napkin

Before I bore you with some theory let me quickly show you, how I think you can fill any (!) empty napkin in a minute with a meaningful sketch of a software system, be it completely new or already 30 years old, whether it´s object oriented or all assembler code, and regardless of its size.

Imagine your boss calling you in to talk to you about a new software project. He explains to you his grand vision of a one-size-fits-all "Hello, world!" program. And you can´t hold back your excitement. What a great opportunity for you to show off your skills as a software architect! You go through the requirements with him and make sure you understand every detail. Then you impress your boss with your first architectural sketch. It´s rough, yes, but at least you can show him something right away. You don´t fear an empty sheet of paper (or Visio drawing canvas). Right to the contrary! You love napkins when they are empty!

Here´s what you draw for your boss on the back of a napkin you happen to have brought with you:

That´s it. Plain simple, and enough to convey your understanding of his amazing idea.

And what is it you depicted? It´s the whole application, all that you have to develop and don´t know yet how to implement. All the intricacies and complexities of the application are represented by, well, just one "software cell" - the circle with the dot in the middle:

I call it a software cell, because it looks like a biological cell with a membrane and a core:

source: http://www.schule.at/index.php?url=kategorien&kthid=6191

And like a biological cell a software cell encapsulates complex processes and shields them from the outside world. By drawing a software cell you thus distinguish an inside from an outside, a system from its environment.

That´s not difficult, isn´t it? But it´s an important first step, since it draws a line in the sand separating what you have to implement from what you don´t have to implement. And it´s important because it starts software development on a level of abstraction your boss is still comfortable with. He´s an important stakeholder of the whole effort, so you want him to feel comfortable and confident and understanding as long as possible. How better to do that than by drawing pictures even he understands?

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 1280x800 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...