iSAQB Software Architecture Gathering 2025
From your writing, one can conclude you are a fan of visual communication. Do you believe most people benefit from visual representation, i.e., are „visual thinkers“?
I’m a fan of any type of effective communication. There are still too many silos and gatekeepers in both tech and business, and documentation-as-an-afterthought is prevalent. When I go into an organisation, I usually have to talk to multiple people and access multiple sources of documentation to get the full picture. But it can be even worse for the people who work there, spending much of their time hunting for the information they need or constantly fielding questions from others.
Visual communication isn’t just for visual learners or thinkers. Many diagrams and visuals would be harder to understand as a text, a bulleted list, or a table of data. Or they would take a lot more time and space to explain the message you want to convey.
To select your medium for communication, you need to think about your audience and what you want them to understand and think. A table of all instances of your digital products by cloud region may show where all the instances are, but not highlight to your audience that all instances of a particular product are far away from their users geographically. A visual can show this clearly, or even be the method by which the problem was discovered.
LLMs are not really thinkers, and especially not at all visual. Do they still, in your experience, produce useful visualizations? (For example, box arrangement often encodes some semantics like layers or network proximity)
If you have at least a basic understanding of a diagrams-as-code DSL (domain-specific language, e.g., PlantUML), can write a very specific prompt, and give the LLM references to documentation, some LLMs can produce useful visualisations using diagrams-as-code. Otherwise, an LLM is likely to hallucinate or make mistakes.
I have seen plenty of examples where an LLM, such as ChatGPT, will give me a very confident answer that is absolute nonsense. This is one reason I created my Diagrams-as-code + AI training, to give people a grounding in some of the most popular diagrams-as-code notations so that they can confidently use them with AI, but also, importantly, without AI. You version control your files, and a human can edit them later.
With LLMs changing so rapidly, it also makes my job harder to keep the training content up to date. I’m looking forward to experimenting with a few of the latest models in the weeks before I give the training at SAG. It will be interesting to see if they have improved.
There are now some tools, usually built on top of an LLM, that improve the output of the LLM by doing some of the prompt engineering for you, but you still really need to have a basic understanding of what you are doing. The educated human architect or developer is not going to go away.
What are the major limitations and caveats when LLM-generating diagrams?
This is a topic we go into deeply in Diagrams-as-code + AI. You need to know how to check the LLM’s output, and you need to know how to tell the LLM specifically what to do. I show examples in my training where an LLM will hallucinate if you ask it to do something at a high level. “Move box b so that it is after box d” would be understood by a human, but an LLM can just hallucinate its own syntax to try to please you.
Another key caveat is that you need to know when it will be faster to just do it yourself. This is another reason to learn at least the basics of the DSL you are using. If your prompt is long or you end up going back and forth with the LLM a few times, leaving the LLM out of the loop is going to be quicker.
Do you have a personal favorite diagrams-as-code tool? If yes, can you pinpoint why? (or is it just taste?)
When it comes to diagrams-as-code DSLs, they all have their pros and cons. There is no silver bullet or one syntax-to-rule-them-all. Some types of diagrams can be created by multiple DSLs, and some are specific to only one. This is why I cover three of the most popular DSLs, so that you can compare them, understand how they can fit into your workflow, and select one or more based on your unique situation.
There are multiple tools that you can use with each of the DSLs, too. Some are online and free, and useful for experimenting. Some tools can be run locally, but usually take a bit of setting up. PlantUML, Mermaid, and Structurizr also have the option to use the command line, so that you can automate the output of your diagrams during your build process.
Your DSL and tool of choice will depend on your unique context. What type of diagram you want, where you want to display it, whether you need automation, whether you need multiple users, etc.
Do you see any convergence towards a standard? Would that be beneficial, or should we (the trade) come up with more bold ideas?
I don’t think there will ever be one standard to rule them all. You get products that try to do a lot, and others that try to do one or a few things really well. Those that do a lot tend not to meet users’ needs across everything. You need a suite of tools that will fit into your workflow and meet your needs.
There may end up being high-level guidelines for diagrams-as-code, or lower-level tools that are used by more than one standard. There are a variety of rendering engines that are used by multiple DSL tools.
Comparing the benefits of diagrams-as-code, diagrams, and models is an interesting part of my training. They all have their pros and cons and will be the best option for someone in some context.
How does diagrams-as-code go together with collaborative modeling (joint interactive modeling with technical and not-so-technical people, typically very heavy on sticky notes)?
What comes out of collaborative modeling is not the final design output. An event storm wall of sticky notes is hard for those who weren’t there to understand, hard to find the bit you need (as they are usually huge), and hard to share remotely if on a physical wall. The aim of the collaborative modeling was to break down silos, get information out of people’s heads, and work together to agree on a model (or at least identify where you disagree and need to work together further).
Diagrams-as-code is useful to document what came out of the collaborative session (in a way that suits version control, with clarity around what has changed), which is usually behaviour rather than structure. For behaviour, PlantUML can be used to create sequence, use case, or activity diagrams. Mermaid offers user journey, sequence, and state diagrams. You can also design the structure and use diagrams-as-code for that too, for example, with C4 or Entity Relationship diagrams.
Domain Storytelling, another collaborative method, does have a 3rd party PlantUML library available. This could be useful if you want to preserve your collaborative output, but in my experience, collaborative sessions are best done by hand, if possible. A pen allows ideas to flow much better than a digital whiteboard, diagramming tool, or diagrams-as-code. You can then document the information you need in a way your audience can understand.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
You need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from Turnstile to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Turnstile. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Facebook. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Instagram. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Google Maps. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from X. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information