Top Ten Tips for Presenting Architecture Information
7. Recognize that Content is King
The seventh tip is that content is king. If you don't have good content, the other tips don't really matter.
Your audience has a responsibility to be a good consumer of information. As they ask questions, check your references and look for supporting detail, if they find contradictions and unsupported conclusions, your message loses credibility and you lose your integrity. It is better to have good content and an unrefined presentation than to have poor content with what at the surface appears to be spit and polish.
8. Leverage Industry Standard Notation Techniques
The Unified Modeling Language or UML includes a set of graphical notation techniques for representing software systems. Use case, class, sequence, component, deployment and other UML diagrams are commonly used from white board sketches to sophisticated tools. Although some of the notations are for object oriented analysis and design, to a large degree the notations are technology agnostic and can be used for analysis, design and documentation of mainframe, client server and net centric architectures.
If you find yourself using a homegrown notation, you should ask yourself why you are not using an industry standard one. You are forcing your audience to both learn a new notation, and to understand your content. It would be much easier for them to take the notation for granted and simply focus on the content.
An anti-pattern I see very often is diagrams which attempt to show dynamic behavior, but are ambiguous and subject to misinterpretation. On the other hand, UML sequence or collaboration diagrams are time proven, clearly illustrate system behavior and can be understood by a wide audience.
You would think that UML would only be effective with an IT audience familiar with the notation. This is generally true because it is a common language IT professionals speak. However, on occasion, I've found that even business partners have been interested in sequence and deployment diagrams when they wanted to understand a particular problem. Although they had to learn both the notation and the content, the time proven notation could be picked up quickly.
9. Incorporate Relevant Facts and Figures
The ninth tip is to incorporate relevant facts and figures into your presentation. The data presented should be key evidence supporting your conclusions.
Choosing the right facts to focus on can be both an art and a science. There may be standard metrics which are relevant such as transactions per second in a performance test, average handle time in a contact center optimization project or the number of applications in a software portfolio for architecture blueprinting.
When standard metrics aren't available, you will have to use your creativity to find the right metrics for your message. One of my favorite examples is a project some years back where the customer had more typewriters than terminals and more filing cabinet storage than databases. Building a business case to bring this profitable business out of the stone age was easy once these precise facts were known by key stakeholders.
All facts must be thoroughly checked and there should be supporting detail which you can point the audience to. Otherwise, the lack of evidence supporting your conclusions will fail to inform, persuade or convince your audience.
10. Follow the Particular, General, Particular Pattern
The final tip is to follow the particular, general, particular pattern for presenting complex information. This pattern begins with a specific, particular, concrete example. From this example, you then make general observations. Finally, you conclude with another particular example to reinforce your point.
If you begin presenting technical information with general observations, it can come across as ideological and irrelevant to the audience. If you first begin with a specific situation that the audience can relate to, it will draw them in. Then they will understand and relate to the general observations made. A final specific situation at the end will provide the repetition of the points and help the audience understand the relevance.
In some sense, this article used the Particular, General, Particular pattern. The specific example of my failed and later successful attempt at communicating architectural information with an executive was used to convey ten general tips I'm learning to put to use. Other particular examples were used in the principles and patterns reviewed in the ten tips.
A successful software architect must learn how to effectively communicate technical information to stakeholders. Every architect will struggle at times in finding the best way to convey important information to peers, partners and decision makers.
Experience is the best teacher and the best way to learn is to do. It is also helpful to look over the shoulder of colleagues and to learn from their failures and successes. As a fellow architect, I've presented some of the principles and patterns I've learned to apply, sometimes the hard way.
We reviewed ten top tips to get you started including knowing your audience, choosing your approach, setting the context, increasing the information resolution and so on. This is a good starter list for improving your technical communications. It is by no means exhaustive. At the end of the article you will find recommended resources to learn from a true master at presenting data and information, Edward Tufte.
Have you ever struggled to communicate architectural information with stakeholders? Do you recognize that presenting architectural information is a core competency of an architect? As you leverage architecture design patterns and principles to craft a solution, have you considered the proven patterns and principles for presenting this solution to stakeholders?
If your answer is no to any of these questions, consider using the top ten tips to help you the next time you need to present architectural information to stakeholders. The rest is up to you!
Anyone wanting to learn more about principles and patterns for presenting data and information would do well to study the work of Edward Tufte. His website, http://www.edwardtufte .com, provides information about his books, essays and seminars.
About the Author
|Jeff Ryan is an enterprise architect with over twenty five years experience architecting and implementing thoughtful solutions to business problems. Jeff has studied the work of Edward Tufte and is learning how to apply his timeless principles of presenting data and information in a software architecture context. This article reflects Jeff's experience in applying Tufte concepts and principles. Click here to browse Jeff's catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML and XSLT.|
Page 3 of 3