The Software Architect Elevator

Chapter 22. Diagram-Driven Design

Cheating in a Picture Is Much Harder Than Cheating in Words

Designing with Diagrams

Some years ago, the Crested Butte Enterprise Architecture Summit once again proved that sticking a bunch of geeks in a remote town can lead to creative results. In our case, the result was an A-to-Z list of 26 new development strategies, starting from activity-driven development (ADD) and ending on zero-defect development (ZDD). Domain-driven design (DDD) was dedicated to Eric Evans’s fantastic book Domain-Driven Design.¹ However, another “DDD” sprang to mind: diagram-driven design, and it turned out that there’s actually a serious idea behind the fun exercise.

Presentation Skills: More Than a Wide Stance

While working for Google in Japan, I created and taught a class on presentation skills for engineers, which included some common ideas of using strong, impactful visuals inspired by books like Presentation Zen.² Following my own advice equipped me with high-resolution graphics of confident managers, fuel gauges indicating that your mileage may indeed vary, shoes that apparently do not fit all, and so on. Still, however impactful fancy graphics may be, for most technical presentations a wide stance, deep voice, and Steve Jobs–like hand gestures (turtleneck optional) are unlikely to teach the audience how a multicloud strategy increases your system architecture ...