In Praise of Context Diagrams

The context diagram is probably the most neglected part of a BA’s bag of tricks. Nothing gives you the ability to collaborate with people so easily on a solution. A single slide with a good context diagram neatly summarises exactly what some functional component does, and who it serves. Whether it’s for a whole company, a system, or a software component, the context diagram applies just as well.

There’s lots of fancier ways of doing the same thing that give you a lot more information on context, aims, implementation, and scope – but none of them are so useful as tools to collaborate.

The beauty is that all you have to do is sit people down in a room, draw a circle in the centre of a white board and ask people who uses it. You then draw the users around in an arc in the top half of the board. Then ask what systems we rely on, draw those in an arc in the bottom half. Now ask what each user/system does with the solution and draw these requests and responses in as the arrows between external participants and the system.

It’s not fancy, there’s no certification course, but it can be the most useful meeting you have the whole project if you get it right.

Also, if you’re an external provider you can make these diagrams look very slick as you’re not restricted by a particular notation or layout. These give you a great way to advertise your competence, while displaying that you’ve understood the context.

Now – tricks!

• If you’re scope doesn’t cover the whole diagram you can use highlighted areas of the diagram to show in/out of scope, or multiple stages.
•  The MS Visio shapes for work flow diagrams and departments are a great source of icons for actors
• Minimise the number of systems you show, it should be mainly about users, systems are only their if they’re really significant.
• Maximum of four lines between any one user and the solution
• The “solution” in the centre of the diagram doesn’t have to be a system; it can be an organisational function, group, process, physical object, or anything really.
• If it helps – think of it as a top-level data-flow-diagram. But I don’t even know if they teach structured design in IT courses any more so that may not help you.
• Each arrow from users/systems to the solution could end up as one or more use cases or as a story grouping.
• Arrows going between users/systems to the solution can be verbs to capture actions, or nouns to capture data transfer. If you can stay consistent that’s nice, but it’s not %100 necessary.

P.S. In fact now I come to think of it most of what I learn in Structured System Design is generally under-used by the larger community. Perhaps because there’s no industry consortiums or consulting houses to push the method like there is for UML, BPMN, RUP, Agile, and all the other usual suspects?