(Architecture) Diagrams as Data
The Clojure community generally believes that everything that can be expressed as data generally should be, which yields many benefits.
Why then are we still drawing our system architecture diagrams with tools and opaque binary formats that can capture only lines and boxes, rather than using accessible data that captures the full semantics of the domain, as we do in the business systems that we build?
The meager information that is in most diagrams today is nearly impossible to reuse or leverage, leading to duplicative work, data drift, and out-of-date documentation.
In this talk I will describe many problems with the way system architecture is generally conveyed, and how many of those problems can be ameliorated by expressing our diagrams as data.
Finally I’ll show the (Clojure+FLOSS) tools and approach I’ve developed for defining our diagrams as data, and show people how easy it would be for them to get started doing the same.
Avi Flax
Funding Circle
@flaximus
Avi Flax (he/him) has been a Web developer since 1998, a software architect since 2006, a data architect since 2016, and a software documentarian since 2018. He’s been learning and using Clojure since 2011. Throughout his career he’s worked hard to communicate system design effectively, and to that end he’s been working on an architecture diagramming framework for about a year and a half.