One effective way of communicating complexity, especially in the overall architecture of a system, is the free form diagram. A free form diagram can directly address unique characteristics of a system in a way that business people can understand.
Out on a walk some years ago I met an acquaintance who happened to be a professor of Computer Science. We talked shop (I worked in the IT department of the local electric utility) and he asked me what methods we used for mathematically proving program correctness. I confess I laughed. My team was struggling to figure out just what the business really wanted – forget mathematical proofs!
Our conversation highlights the tension between rigor and expression in diagramming to support IT projects. Developers need precise diagrams rigorous enough to accurately reflect complex processes. However, that precision and detail can make the diagrams at best boring and at worst intimidating to business people. Often they don’t have the time or patience required to sit through the explanations needed to understand such diagrams. Requirements meetings frequently end early with business participants walking off grumbling about IT non-alignment.
UML is today’s de facto analysis and design diagramming standard. To the OO professional UML provides a rich, expressive, and consistent set of conceptual tools that continue to evolve. Work is underway to improve the accuracy and precision of UML with respect to the target code. (http://www.omg.org/docs/ad/00-01-07.pdf).
The problem is that more precision will make the UML diagrams more complex and less understandable to non-coders, making the diagrams even less useful in communication with business people.
For project success business people need to be able to communicate their needs freely and completely. Requirements analysts need to capture, record, and replay business needs for confirmation, and let the business expert return to other work as quickly as possible. These communications often work best with pictures rather than words, and of course when everyone understands the picture the same way. Asking a busy floor supervisor to review a formal class model is literally having him or her review specifications in a foreign language.
One solution is for developers to communicate with business people using free form diagrams, expressive yet rigorous diagrams with drawing conventions tailored to the audience.
More to come in parts two and three of this series. Part 2 talks about using free form diagrams in practices, and Part 3 provides some simple guidelines for successfully using free form diagrams.