Shneiderman's mantra

I attended a fantastic talk about big data visualisation at the YOW! 2014 conference in Sydney last month (slides), where Doug Talbott talked about how to understand and visualise large quantities of data. One of the things he mentioned was Shneiderman's mantra:

Overview first, zoom and filter, then details-on-demand

Leaving aside the thorny issue of how teams structure their software systems as code, one of the major problems I see teams having with software architecture is how to think about their systems. There are various ways to do this, including a number of view catalogs (e.g. logical view, design view, development view, etc) and I have my C4 model that focuses on the static structure of a software system. If you inherit an existing codebase and are asked to create a software architecture model though, where do you start? And how to people start understanding the model as quickly as possible so they can get on with their job?

Shneiderman's mantra fits really nicely with the C4 model because it's hierarchical.

Shneiderman's mantra and the C4 software architecture model

Overview first (context and container diagrams)

My starting point for understanding any software system is to draw a system context diagram. This helps me to understand the scope of the system, who is using it and what the key system dependencies are. It's usually quick to draw and quick to understand.

Next I'll open up the system and draw a diagram showing the containers (web applications, mobile apps, standalone applications, databases, file systems, message buses, etc) that make up the system. This shows the overall shape of the software system, how responsibilities have been distributed and the key technology choices that have been made.

Zoom and filter (component diagrams)

As developers, we often need more detail, so I'll then zoom into each (interesting) container in turn and show the "components" inside it. This is where I show how each application has been decomposed into components, services, modules, layers, etc, along with a brief note about key responsibilities and technology choices. If you're hand-drawing the diagrams, this part can get a little tedious, which is why I'm focussing on creating a software architecture model as code, and automating as much of this as possible.

Details on demand (class diagrams)

Optionally, I might progress deeper into the hierarchy to show the classes* that make up a particular component, service, module, layer, etc. Ultimately though, this detail resides in the code and, as software developers, we can get that on demand.

Understanding a large and/or complex software system

Next time you're asked to create an architecture model, understand an existing system, present an system overview, do some software archaeology, etc, my advice is to keep Shneiderman's mantra in mind. Start at the top and work into the detail, creating a story that gets deeper into the detail as it progresses. The C4 model is a great way to do this and if you'd like an introduction to it (with example diagrams), you can take a look at Simple Sketches for Diagramming Your Software Architecture on the new Voxxed website.

* this assumes an OO language like Java or C#, for example

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: Shneiderman's mantra

Hi Simon, Let me start my congratulating you on the amazing work that you are doing. You are spot on with respect to 'the disconnect between the architecture sketches and the code' and the 'confusion around terminologies in different architecture frameworks'. I'm going to start experimenting with the C4 model to communicate with different stakeholders. Having said that, I'm facing a few challenges with this framework. Would love to hear your ideas on these. A System may be composed of big components/sub-systems that span multiple containers. For example, a recommendation sub-system might compose of a web-application, a stand alone Hadoop process, a few FTP files, some RDBMS tables etc. And the system in question might be composed of many such sub-systems. So does it make sense to delve directly into the containers and ignoring the higher abstraction of sub-systems ? How do we depict the fact that the above 3 containers for example belong to a bigger sub-system ? Regards, Ravi

Re: Shneiderman's mantra

Thanks for the kind words, Ravi. :-)

There are a couple of options that spring to mind. The first is to draw the container diagram and simply use colour coding or notation to signify the containers that make up a sub-system. For example, "all red containers are part of the recommendation sub-system". Another option is to create a separate C4 model for each sub-system so that you only focus on one sub-system at a time. In other words, you would draw context, container and component diagrams for each sub-system. For example, the container diagram for the recommendation engine would show the containers for the recommendations engine, and all other sub-system interactions as black-box interactions. Hope that helps!

Add a comment Send a TrackBack