Recently, I came across this one in an older blog entry on MSDN:
Aoccdrnig to rscheearch at Cmabrigde uinervtisy, it deosn’t mttaer waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteres are at the rghit pclae. The rset can be a tatol mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe.
Remember that one? It is interesting how relatively easy, it is to read the text despite all of the spelling mistakes. But as the blog points out, the reason we are able to read the text is not (as claimed above) because of the first and last letter, but because we recognise the shape of the word.
Apart from being curiously interesting, it also reminded me about how important it is for architects to be able to visualise the architecture. The above example illustrates not only how fundamental our ability to recognise shapes, but also how we associate concepts or meanings to individual shapes.
An interpretation of this for software architecture descriptions would be:
- Illustrations and diagrams have the leading roles, and text is in a supporting role. Your architecture document should be able to tell the main ‘story’ through its pictures. You can test this by lifting your diagrams out of the document and into a presentation, and then see if you are able to present your architecture.
- If your illustrations are too complex to fit onto a single slide, then the chances are your ‘sentence’ is too long. Break it down into to one or two ‘views‘, and relate them through appropriate ‘styles’. A context diagram is also a good idea to ‘set the scene’.
- Be aware of the associated meanings of the shapes you choose to illustrate your software elements and their relationships. It confuses the audience, if you talk about a software component illustrated by a server (hardware) icon.
- Be consistent in your illustration choices – and don’t use the same one for different things even if the context is different. And do include a legend.
‘Documenting Software Architectures: Views and Beyond‘ is a good reference for further information of how to best document your architecture.