Why Animate?

Whether the stakeholders of the system you are describing are sponsoring, approving, building, using, managing or maintaining the system of interest, you are usually required to communicate to them that you have addressed their concerns. That's the purpose behind developing an architectural description.

Sketching using simple drawings is adequate when you are defining structure but animation is an excellent way of sketching the system's behaviour. So this is my way of achieving something similar to paper-prototyping a system's behaviour.

The key word in all of this, though, is Sketching. An excellent book about the topic is "Sketching User Experiences: getting the design right and the right design" by Bill Buxton.

I justified the use of development methodologies like IBM Rational Unified Process because I would only develop the parts of the system necessary to reach my risk milestones. If I got to the point where I could no longer address the risk, I pulled out with a minimum amount of sunk cost.

Sketching takes this even further. Now we are minimising the effort required to communicate our understanding of a system's architecture by using animated sketches. Don't expect this not to come at a price though. Sketching quickly and clearly improves with practice -- lots of practice. But anyone can sketch -- immediately.

I've abandoned Storyboard Pro and now using another of Toon Boom's tools "Digital Pro" which is the animation tool. For quick sketches that I can also bring into Digital Pro I prefer to use Autodesk's "SketchPad Pro". I export the animation as a Flash file.

I create the deliverable using Adobe Flex and ActionScript 3.0. and embed the animations where appropriate in my architectural description. I can then either send the .swf to my client, or host it on their website (or mine).

My next step will be to create a version that will run on Adobe AIR.