Deliberate practice, effective sketches

Creating a collection of simple diagrams to communicate your vision

In Where are the software architects of tomorrow?, I talked about how most software developers don't get to take a blank sheet of paper and design software from scratch all that frequently. Related to this is the process of communicating those designs, either during (e.g. when collaborating) or after (e.g. when documenting) the architecture process. In concert with just enough architecture, my preference is for effective sketching rather than comprehensive UML models.

An initial set of sketches

Back at the start of March, I ran a tutorial at the QCon London 2011 conference entitled "Designing software, drawing pictures". After a short presentation to ensure a common starting point, everybody that came along was split into small groups and asked to design a software system given a brief set of requirements. Pretty much no guidance was given to the groups other than "choose some technology, design some software and draw some pictures to portray your vision". Here are the sort of pictures that were drawn.


You've probably seen pictures like this before. They're okay if you're explaining while you're drawing but they tend to show too much detail, mix abstractions and leave some things to your imagination.

A second attempt

To counter this, I tend to use a collection of simple diagrams, each of which focusses on a specific level of abstraction ... context, containers, components and classes. Back to the QCon tutorial and, after some additional guidance, the groups were asked to revise their diagrams. A short amount of time later and here are the sort of pictures created second time around.



Much better! Even without knowing anything about the software being designed the pictures look simpler, less cluttered and clearer. When you do know something about the software though, the new pictures allow you to get a feel for what's going on and understand the vision behind the design much more easily because each picture only shows a single level of abstraction.

You can see some more photos at and my book provides more information on the type of pictures that I draw. If you want to practice drawing effective sketches yourself, I'll be running a similar session at the GOTO conference in Copenhagen and we cover it on our Software Architecture for Developers training course.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Deliberate practice, effective sketches

Thanks for a great post on how to effectively diagram up an application's architecture. Should the context diagram try to limit or possibly avoid entirely the mention of specific technologies so that the best technology can be chosen once the context is fully understood?

Re: Deliberate practice, effective sketches

Thanks. :-)

There's no "right" answer, but most of my context diagrams tend to exclude technology and are diagrams that anybody can understand, even if they know nothing about the technical nitty gritty of software development. That's what the containers diagram is for.

Add a comment Send a TrackBack