Visualising your architecture

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.

the ant of performance testing

Much has been made of the recent performance improvements of web browsers – Mozilla, Microsoft, Opera and Google all lining up to show how their browser is the fastest. Similar performance focused shot outs have taken place for databases (Oracle, IBM, Microsoft) or application servers (BEA, Microsoft, IBM, JBoss etc). Probably any software technology has been subjected to some form of performance comparison.

Performance is important – don’t get me wrong – but it is really very subjective and not as objective as the technology vendors imply.

I ran Mozilla’s ant test site with the new firefox 4 beta 7 and the new Google Chrome 8/9. Chrome won hands down. The test ran much faster in Chrome according to the numbers displayed. And the ants do seem to run smoother in Chrome.

But the problem for firefox isn’t its core code implementation, but its integration with the operating system. When Chrome is running the ant test, the window manager ( consumes about 20% of the CPU leaving Chrome to consume the remaining 80%. But Firefox causes the window manager to consume more than 60% leaving only about 40% for the browser itself. Fix the integration and it should in theory be about 40 to 50% faster than Chrome.

But then again, maybe not. Performance projections are very rarely linear, but far more likely to be indeterminable curves riddled with bottlenecks.

The debate will probably die out soon, once we realise that even 100% improvements of a few milliseconds are still just a few milliseconds – but thanks to Google, all browser users win.

You can try the test for yourself here