Style on top of substance...

The term "Powerpoint architect" is often used in a derogatory sense, typically being used to refer to a hands-off, hand-waving, responsibility-free "architect". Unfortunately this seems to result in the use of presentation being somewhat stigmatised.

We associate presentation, particularly ones where some effort has been involved, more with business and marketing than we do with technical disciplines. This seems a wasted opportunity when it can be such a powerful, down-to-earth and two-way form of communication.

Thanks in part to Garr Reynolds' Presentation Zen website and book I've found a renewed interest in sharing architectures by presentation.

I believe that some degree of understanding of the architectural principles and the reasoning behind the decisions that have been made is important in ensuring that the software continues to evolve consistently and with due consideration of requirements and constraints. These broad concerns, which are often subjective, are probably better suited to a broader, more personal, medium than simply capturing it in the software architecture document. We acknowledge that conversation is crucial to agile projects but part of the architect's role lies at the interface between the "development team" and other stakeholders.

Presentation can fill that gap, particularly if it concerns itself with the more emotive aspects of the architectural process - the stories and history that shaped the architecture. By sharing these stories we also help to close the gap with the development team by helping make them more architecturally aware.

Conversely, we should also sieze the opportunity to make other stakeholders aware of the architecturally significant decisions -- actively promoting our work and our team rather than waiting for a summons. Again, by focusing on ideas and stories we can help improve understanding between the disparate factions that our role requires us to reconcile. Expecting to impress a non-technical audience with the depth of your technical skills or grasp of jargon is at best hopeful but most probably hubris.

Sounds like a job for Synth
Perhaps a bit offbeat for some audiences but there's no need to stick to boxes and arrows when presenting the technical, especially to a non-technical audience.

Rather than repeat the advice from Presentation Zen I'm simply going to advise that you have a look at the site, particularly this entry about high concept thinking. It's easy to dismiss it as high on style and low on substance, but that's really the point. Sure there are various media well suited to capturing the more substantive elements of architecture, such as the SAD, but that's only part of the puzzle. Rather than style over substance, why not aim for style on top of substance and inform people in ways that the SAD can't?

About the author

Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan developing front-office trading solutions.

While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).

E-mail : kevin.seal at

Add a comment Send a TrackBack