UML: round two

I became aware of Unified Modeling Language (UML) several years ago when I was feeling the lack of high-level system descriptions at work and went looking for a solution.

My proposal to use UML internally was quashed by a senior engineer who (I think) considered it old-hat and geared towards object-oriented languages. They favoured structurizr, a different Diagrams As Code (DAC) application, which may well be great, but it never clicked with me.

Between the syntax of the language itself and trying to get to grips with the C4 model and applying it to systems I didn't understand (and which, of course, lacked adequate documentation), it was all too much for me to get to grips with.

We never built any momentum for structurizer within the department, that senior engineer is long gone and we still lack high-level system descriptions and a culture of using diagrams to document architecture.

PlantUML

It turns out our most recently hired developer shares my opinions on how the digital delivery team could work more effectively. Being a relatively new addition to the team, they're more accutely frustrated by the lack of system diagrams than those of use who have been around a few years and have gotten used to things.

Last week they pointed me towards PlantUML and despite my aim of not spending another weekend on work-related matters, I became obsessed and did just that.

I'm not going to get into the nuts and bolts of PlantUML and what I've learned about it — the low barrier to entry is one of the things that's so great about it, so you might as well just go to the source.

It's a testament to how good it is that after just a few hours of experimentation I'm already running up against the real problems:

• how best to break up our systems conceptually so they can be diagrammed effectively
• who the diagrams are for; what is the purpose and how much detail is appropriate
• where in the documentation these DAC should be stored to take advantage of version control

END

Home