Introduction
Several years ago, a colleague and I prepared an
impressive PowerPoint deck (so we thought) on architecture
blueprinting to share with an executive. As you can imagine,
we barely got through three pages of the deck at the meeting
and didn’t effectively communicate our message or its
relevance.
Fortunately, we were given a second chance. The next time
we met, I vowed to try something different. Rather than
trying to present information from an 80 page deck, I
condensed the information relevant to this executive into a
one page thumbnail of the overall blueprinting process with
sample content from his automation portfolio. The approach I
chose was to use this simple handout on legal size paper to
facilitate a meaningful conversation.
It worked. The executive was intrigued by the one page
hand out and directed the conversation so he could
understand the overall approach, the relevant detail, and
insights gained. We conveyed all of the information we
wanted within the hour meeting (and then some). We were even
able to point out some of the supporting detail from the 80
page deck now that we had set the overall context.
I stumbled upon a successful approach, but didn’t know
precisely why until I attended a seminar on Presenting Data
and Information by Edward Tufte a few months later. I sat in
awe at the seminar as Tufte presented time proven principles
of analytical design and patterns for effectively presenting
data and information.
I’m sure you have had experiences similar to mine; some
positive and some where you wish you could press the rewind
button and start over again. In this article I would like to
share ten tips for effective presentation of architectural
information I’ve learned from Tufte and others (sometimes
the hard way) which have helped me and will hopefully help
you become a better software architect.
The top ten tips we will examine are:
- Know Your Audience
- Carefully Choose Your Approach
- Set the Context
- Increase the Information Resolution
- Show Data on a Universal Grid
- Use Small Multiples
- Recognize that Content is King
- Leverage Industry Standard Notation Techniques
- Incorporate Relevant Facts and Figures
- Follow the Particular, General, Particular Pattern
1. Know Your Audience
The first tip for effectively communicating architectural
information is to know your audience.
When I met with the executive on blueprinting, I knew he
was extremely intelligent, had very little time, and
sometimes very little patience. I also knew he was very
interested in an objective assessment of his automation
portfolio and wanted a road map for addressing shortcomings
and risks. The simple one page document addressed the
questions he had on his mind, engaged his intellect and let
him use his precious time the way he wanted by letting him
drive the conversation.
Essentially, what you must do is ask “What’s In It For
Me?” or WIIFM from the perspective of the audience. This
enables you to communicate your message in a way that will
best engage and resonate with the receiver.
WIIFM is the first thing I do when writing for IT
professionals. You might notice in the lead to the article I
always pose questions that I believe are relevant to the
architects, developers and project managers who are reading
them. Once I’ve posed a question in the readers mind, I’ve
started to engage his thought process and it is my hope that
he will be motivated to read on if these questions are
relevant. Most IT professionals are pressed for time, so I
try to make the information as consumable and digestible as
possible. My goal is to provide something practical the
reader can apply right away by the end of the article so he
doesn’t feel he wasted the time invested in reading it.
2. Carefully Choose Your Approach
The second tip is to carefully choose the approach to
most effectively communicate architecture information to
your audience.
There are many different mediums for communicating your
message. For example, the best method to convey information
in a given situation might be white boarding, writing a
white paper, creating slides, giving a speech (with or
without slides) or even simply having a conversation. You
should tailor the approach to the type of information being
presented and the audience being presented to.
On many occasions, I’ve found that white boarding best
engages the audience. White boarding causes you to withhold
information that the audience is eager to understand. You
slowly reveal this information as you draw and explain the
diagram. When the audience asks questions, it is very easy
in real time to address them by annotating or expanding the
drawing.
Other times a short white paper is best. This can be
circulated among a large group of stakeholders. It can be
used for independent reading, small group meetings or for
presentations to a large group. It can also be used to track
revisions and gain sign off by key stakeholders.
I often see colleagues jump to crafting slides before
they have considered the audience, purpose or approach. This
is a case of “if the only tool you have is a hammer, then
every problem becomes a nail”. As you can see, there are
many other tools to consider for the communication problem
at hand and slides are only one of many tools.
That being said, sometimes slides will be the best means
for presenting architectural information to your audience.
But don’t jump there without considering other approaches
first. When you do choose to create slides, many of the
patterns and principles below will help them to be more
effective.
3. Set the Context
The third tip is to set the context for the information being presented to your audience using the chosen approach.
When you are given a window of opportunity to present architecture information, you have to remember that the audience has not been fully immersed in the problem space you are in. Even though you may have met with them in the past, they may not immediately recall each occasion, what was discussed, the decisions made or the follow up items promised. It is your duty to remind them. I’ve seen so many meetings go awry because the meeting context wasn’t established at the beginning. This often results in a déjà vu meeting. When meeting with the executive on blueprinting the second time, we reminded him of what he asked for, humbly admitted our past failing in addressing what he needed and our response.
Context also needs to be established for the information being presented. In writing or developing slides, it is helpful to show how your material relates to a continuum of time, industry benchmarks, trends and the like. This enables the audience to make comparisons and put things in the proper frame of reference.
A pattern which is often used to establish context is the master-detail pattern. The master view might be presented up front as an overall diagram, providing the context for the information and the detail areas to be examined. The consumer of the information will understand up front the areas to be discussed, the sequence that they will be discussed, and during the discussion which area of detail is being examined. This often helps the audience better consume the content being presented through a meeting, slides, or paper because they understand the bigger picture up front. The list of ten tips in the introduction to this article is an example of the master-detail pattern although a diagram was not used.
4. Increase the Information Resolution
The fourth tip is to increase the information resolution of the presentation materials. Information resolution is the amount of information conveyed on a given page. When increasing the resolution, it should be done using the least amount of ink possible.
One of the humorous portions of attending a seminar by Edward Tufte is his example of what Lincoln’s Gettysburg Address would have been like if he used the PowerPoint wizard. This is an excellent case of an anti-pattern for presenting data and information and in decreasing information resolution. The reason why this approach fails is because the human mind can absorb vastly more information than is communicated on a typical PowerPoint page with six bullets per page and cheesy graphics which Tufte calls chart junk.
One of the reasons my one page summary on legal size paper worked was the executive quickly grasped the essential information and was hungry to learn more about the additional detail behind it. The handout itself provided the overall context of the blueprinting process we developed as well as much relevant detail. Although I didn’t know it at the time, I dramatically increased the information resolution through this hand out as compared to the 80 page deck.
Initially, I stumbled upon this one page summary format. Now it has become a reusable pattern I’ve used to communicate architecture viewpoints, reference architecture, roles and responsibilities, solution continuum, etc. If you visit my office, you will see many such diagrams I’ve used to present architectural information. Each diagram is different, but tells a story by creating a scaled down thumbnail of relevant architecture artifacts and incorporating the graphics with text, thereby increasing the information resolution for the audience.
5. Show Data on a Universal Grid
The fifth tip I’ve learned is to show data on a universal grid. If the intended audience needs to repeatedly consume similar information, it is important to help them parse this information as easily as possible.
A universal grid pattern I regularly use is to show the conceptual diagram for an n-tier architecture with the same layers and background colors. Once the audience is familiar with the presentation, service, component and resource layers, it is easier for them to understand the application being depicted and how it is being modified. After the first presentation, they understand the layers and architecture principles behind depicting an application in this way. The one page diagram on architecture blueprinting included two scaled down n-tier layered diagrams. The executive quickly grasped what was being shown here.
Figure 1 – N-Tier Layered Universal Grid Example
Some might say that depicting particular types of architecture diagrams across a universal grid stifles the creativity of the architect. I don’t share this view. I would rather the architect channel their creativity into coming up with the best overall solution to meet short and long term business needs than to be fiddling with colors and diagram formats. That being said, sometimes the so called “universal” diagram doesn’t depict the problem space or solution particularly well. In that case, it is perfectly acceptable to use another format.
6. Use Small Multiples
The sixth tip I’ve learned is to use small multiples. Small multiples are a series of small pictures, usually on one page, which graphically illustrate changes to an object or set of objects.
Part of the job of an architect is to develop a thoughtful plan for how a system will evolve over time. This presents a particular problem. When you add the dimension of time, it becomes difficult to show architecture diagrams in a way that the audience will understand the evolutionary steps.
Small multiples solve this problem. When I do architecture blueprinting, I need to show the current state, future state and transition plan of a system. I use the n- tier layered universal grid mentioned above to show each point in time view. Then I scale these diagrams down so the proposed transition can easily be understood on a single page.
Figure 2 – Small Multiple Architecture Transition Plan Example
At the time I was speaking with the executive on blueprinting, I hadn’t yet learned about small multiples nor how to apply them in a software architecture context. We walked him through pages of transition plan scenarios in the 80 page deck. I’ve recently started using small multiples for showing architectural transition plans on a single page. The insight that this provided the business and IT stakeholders was astounding, particularly because you could visually see the transition over time on one page and understand how systems targeted for sunset were being phased out as projects were being executed.
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 eighth tip is to leverage industry standard notation techniques when presenting architecture information.
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.
Summary
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!
Recommended Resources
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. |
