Whiteboard visualization of your it architecture

Question

Hi,

once in a while you have to draw a picture of your (planned) IT architecture/infrastructure on a whiteboard. Sometimes there are only IT people in the room, sometimes not. But anyhow, usually you just want to depict your IT systems or architecture more or less as a sketch and not in full detail.

What I want to ask now is, which stencils, diagram artifacts, etc. do you use when you want to describe your architectural thoughts, e.g. a systems which incorporates excel import, xml export, an esb in the middle, 3 different databases in different locations, a web and a stand alone gui? I guess few people will come up with a detailed UML class diagram, which in this case won't serve well. Sequence or activity diagrams are good for the information flow depiction, but not for the greater picture of the system.

So maybe we can collect some thoughts on that, similar to this thread.

Best regards,

Andi

PS: I thought this might be good place to discuss this, but if it's too off-topic please let me know and I'll close it or move to a more adequate place.

Answer 1

The short answer is - whatever works. The most relevant point is that you have to communicate in a way / language that the audience understands.

I've a couple of examples here that just happen to be very tidy - if it's a free flowing discussion they won't be - nor do they have to be. FYI I work as a solution architect - so boxes serve me well; I'm mostly talking about systems context - where things fit in an existing landscape.

To address some of your specifics:

• I tend to use stick figures for roles and specific user groups - although business groups can be boxes to. Boxes are also good for putting things inside.
• Data repositories (especially databases) work well as a drum.
• Almost everything else is a box (if it's a significant element in the scope of the diagram).
• Adding visual context for people is important - so drawing little boxes with lines to represent documents is good - maybe like a table for a set of data.
• Arrows - mostly solid as that's quicker, sometimes dashed to indicate something that's indirect or asynchronous.

I agree with your comment regarding UML: UML is very formal - when you're discussing stuff in front of a whiteboard it's usually anything but.

Other things:

• Use of color can really help, so don't be afraid to use it when appropriate.
• The order in which the diagram takes shape is relevant to the story it's telling, don't be afraid to annote it for later use when you...
• Take photos of stuff that's put on a whiteboard - most mobilephones these days have cameras built in - use it.

(Full size copy here)

(Full Size copy here)

(Full size copy here)