Simple sketches for diagramming your software architecture

Agility is about moving fast and this requires good communication. A consistent, shared vision is essential in order for teams to push in the same direction, but it's surprising that many teams struggle to effectively communicate the architecture of the software they are building. As an industry we do have the Unified Modeling Language (UML), yet many people favour informal "boxes and lines" sketches instead. The problem is that such diagrams rarely make any sense, usually need a narrative to accompany them and ultimately slow the team down. Although we can argue whether UML offers an effective way to communicate software architecture, that's often irrelevant because many teams have already thrown out UML or simply don't know it. Abandoning UML is one thing but, in the race for agility, many software development teams have lost the ability to communicate visually too.

This hands-on session is aimed at those involved in the software development process and is about improving communication. In part 1, you'll see some typical diagrams and we'll use these as a basis for understanding why they often don't communicate software architecture in an effective way. We'll also identify some anti-patterns of such diagrams, which will help you avoid them in the future.

In part 2, you'll learn some lightweight techniques for communicating the static structure of a software system based upon a small number of simple sketches. We'll be focussing on "boxes and lines" sketches although the same principles are applicable to UML.

Other formats


    of 74