This is part two of a three part series on free form diagramming for IT projects. This entry reviews free form diagramming in practice. Part one talked about the tension between rigor and expression in diagramming for analysis and design, and how more precise diagrams can hinder rather than help communications with business people. Part three will provide a few simple guidelines for getting it right.
Some current development tools and methods do include the free form diagram in their toolbox. For example, Scott Ambler’s Agile Modeling site includes a page on free form diagrams (http://www.agilemodeling.com/artifacts/freeForm.htm), and the IBM tool XDE has provided an integrated free form diagram (http://www-128.ibm.com/developerworks/rational/library/915.html).
Free form diagrams can be especially useful in illustrating the overall scope of an IT development effort. For example, XDE product literature cites the free form diagram’s “capabilities to communicate broad ideas about the direction of [a] solution”. IT software product marketers frequently bear out this advantage over structured modeling with attractive diagrams describing their products and services, as in the diagram above. Such diagrams enable companies to “level set” the terms of a conversation, providing a reference point for providing more detailed information about the product.
A similar diagram can provide a reference for IT project participants. One, produced jointly early on in custom development of a financial system by the primary business contact and project architect, helped build consensus with designers, database administrators, programmers, and business people. Some on the project considered this shared vision of the planned system one key to the project’s success.
Both of these examples illustrate the most common use of the free form diagram: to depict “the fundamental organization of a system [or business function], embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” (http://en.wikipedia.org/wiki/System_architecture).
Because the free form diagram can seem more concrete than other, more abstract, models, a well-constructed free form diagram is a great way to communicate complexity to an audience of both technical and non-technical participants.
The free form diagram is also useful in other situations. Sometimes a requirements team works with business users who have a diagram describing their current process. In that case the team might use the same format to describe the new process. In other cases it might be useful to improve readability by drawing a process flow on a map of the shop floor, or using icons representing real objects and events rather than class symbols on a class model. The point is to create a medium that precisely matches the audience with the message.
Part 3 of the Free Form Diagrams series provides a few simple guidelines for success with this technique.