I have a passion for finding clear and concise ways of documenting architectures. Doesn’t it feel enlightening when you find a way to fit what would easily be a couple of pages of narrative into a fairly simple diagram. I’m a big fan of the book Documenting Software Architectures: Views and Beyond by Paul Clements et al not only because it provides some theoretic underpinnings of architecture descriptions (in fact, a slightly extended version of common sense ISO 42010), but mostly since it has extensive catalogue of techniques and notations spiced by wide variety of examples. Too bad it only aims towards software architecture, I’ll definitely buy an enterprise version, but I’m afraid a comprehensive coverage of the subject would easily fill dozen of volumes.

I heard about N² diagrams (pronounced as N-squared) diagrams a while ago. I believe it was NASA Systems Engineering Handbook. It is sold as a way of managing component interfaces of various kinds, e.g. structural, optical, energy. I haven’t bought into the idea at that time since I never thought about managing structural interfaces. To be honest I still can’t wrap my head around the idea. Anyway, what is the contract of I-beam girder or how are you going to create forward compatible suspension system — that’s what interface management is about, right? So I never tried using this sort of diagrams. How wrong I was!

Couple of months ago Randall C Iliff of INCOSE made a webinar (members only, sorry) about practical use of this kind of diagrams. What I’ve found is that it is much more than just a way of describing interfaces. An interface is just a special case of relationship, but the diagram is good in representing any kind of (binary) relationship. More than that, it is amazingly rich, flexible and yet concise way of representing relationships between entities in arbitrary domain. And I immediately became a new convert. Since that I found so many uses of the diagram that I can’t even remember how I managed to represent all of these in any other way.

What is N² diagram? The idea is quite simple if you look at the picture.

First, you take a coarsely squared sheet of paper and put all your entities one by one on the diagonal. Second, you fill each cell above the diagonal with information about a relationship between an entity to the left and an entity below (clockwise). Then you do the same for each cell beneath the diagram, but for en entity to the right and above respectively (clockwise again). And finally, you add external inputs and outputs on margins as demonstrated.

So far it may look simplistic. But imagine that you have a work with something that looks like the following picture.

Scary, huh? That’s what your average enterprise IT landscape tends to become, so you have to manage it. Let’s say you need to say something meaningful about each line. Can you imagine such a diagram? Have you seen something like that? I have, don’t want any more.

N-Squared version of the diagram above is much much simpler. You only have 11 elements on a diagonal and 110 empty cells, each of which provide an appropriate place to put any additional information related to a particular link. No overlapping lines, no pixel-hunting while trying to lay out your labels. And as a bonus you don’t need anything other than good old Excel to author such diagrams, so even your average end user can contribute sensibly.

That is nice, there are lots of applications for diagrams with elements of a particular kind represented on the diagonal, e.g. causality analysis, impact analysis, discovery of dependencies, etc. However, N² diagrams shine even more when you have elements of different kinds mixed on the diagonal. The possibilities are endless. Elements can be anything you care to examine. Just few ideas partly from the webinar itself, partly from my own experience.

  1. Product and technology road-mapping. “Road-maps are just interaction sets that arise from time phased baseline changes”, so put products, technologies and critical milestones on a single diagram. Explore independence, backward- and forward-compatibility dependencies by looking at each cell. Then move few items up and down the diagonal to create useful clusters that will become your deliverables.
  2. Project management. An specific instance of the above. Put everything that needs to be done and your resources on the diagonal, and explore dependencies and constraints. Convenient when you need to explore the impact of certain even.
  3. Problem space investigation. Put everything you care about in the problem space and explore interdependencies. If you find a ternary relationship or an important causality between relationships you can always reify one into another element on the diagonal. I’ve found that domain experts are much more comfortable with this notation when compared to ER Diagrams or UML Class Diagrams
  4. Understand complex workflows. You know, that kind of workflows where it seems that you can go from any step to any step depending on a situation so traditional process diagram becomes cluttered beyond any comprehensibility. Put wait states and activities on the diagonal and ask the end user about likelihood and conditions of each possible transition.

As a summary, N² diagrams are quite useful and sometimes underestimated. Love them. Main benefits are:

  • Easy to learn, impossible to forget
  • Effective representation when relations are in focus and there are many of them
  • Needs only low-end tools such as Microsoft Excel or equivalent
  • Possibilities are endless, especially if you consider putting items of various kinds on the diagonal.