Part of the software architecture training course that we run is focussed on helping people produce effective architecture sketches. You can see some examples of what we do from the photos that I took during the recent Software Architect 2012 conference in London and XP Days 2012 conference in Kiev. In a nutshell, we introduce some simple organisational ideas, concepts and abstractions that enable people to draw structured diagrams (sketches, rather than UML). We run the exercise across 2 iterations.
In terms of the process that we follow, small groups are given some requirements and are asked to design a solution, illustrating it with one or more large diagrams (e.g. on flip chart paper). We then rotate the groups and ask them to review the diagrams produced by another group. When listening in on the discussions, much of the conversation unsurprisingly focusses on the actual diagrams themselves. For example, you often hear comments such as, "what is this box?" or "this diagram has so many boxes and lines that I don't know where to start". There's always lots of conversation, but much of it relates to the presentation of the ideas rather than the solution itself.
Iteration 2 starts by summarising the feedback and providing some guidance on how to draw effective architecture sketches, before asking the groups to re-illustrate their solutions. When finished, we again review the diagrams. Some discussion of the presentation remains, but the conversation usually switches fairly rapidly to the solution itself. I'm running the course this week and today I heard the following types of comments during the second round of reviews: "why doesn't that component talk directly to the database" and "this solution won't work if X happens". Both of these technical details were almost impossible to see by looking at the initial set of diagrams.
For me, this is exactly the reason why drawing good architecture sketches is a good skill to have. If you can communicate your software system in an effective and efficient way, you'll shortcut all of the conversation about what the pictures mean from a syntactic point of view and start to focus on the technical aspects of the solution. In other words, you'll start to have more meaningful conversations focussed on what's really important.
Modern software development approaches are often about moving fast, and moving fast requires good communication. Is communication slowing *your* team down?