Important insight for understanding container level vs component level at 53:00 : How much design/architecture should you do upfront? Answer: Down to component level. With microservices only down to container level.
Structurizr is a pretty neat approach. Not sure that it adds anything to PlantUML but export to different formats but still worth to think over the main idea to produce high level architecture docs via high level code.
An enlightening overview of software architecture diagramming. That said, at 51:20 Mr. Simon Brown advises against using computer graphic tools for diagramming; in the next beat he recommends using paper and whiteboards... I don't really understand the advise against using these tools.
Based on other talks he did, he usually only recommends against diagraming tools (e.g. Viso, Diagram.net) but recommends using modelling tools (specifically those designed for software architecture).
For up front design, paper or whiteboards offer to easiest tooling for sketching out ideas ... assuming everybody doing that design exercise is colocated, which admittedly hasn't been the case for the past year. For long-lived documentation, I'd definitely recommend modelling tools over diagramming tools though.
@@simonbrown4821 Thanks so much for clarification and for the talk. It makes more sense on revisiting. The subtitle in the slide says to avoid GENERAL PURPOSE diagramming tools to this end. Makes perfect sense!
15:20 it can be cognitive dissonance , they worked so much on that initial arhitecture that they won't change it anymore cause they consider it beautiful and important OR the software they used or used to persist the design is difficult to use.
Important insight for understanding container level vs component level at 53:00 : How much design/architecture should you do upfront? Answer: Down to component level. With microservices only down to container level.
Structurizr is a pretty neat approach.
Not sure that it adds anything to PlantUML but export to different formats but still worth to think over the main idea to produce high level architecture docs via high level code.
An enlightening overview of software architecture diagramming.
That said, at 51:20 Mr. Simon Brown advises against using computer graphic tools for diagramming; in the next beat he recommends using paper and whiteboards...
I don't really understand the advise against using these tools.
Based on other talks he did, he usually only recommends against diagraming tools (e.g. Viso, Diagram.net) but recommends using modelling tools (specifically those designed for software architecture).
For up front design, paper or whiteboards offer to easiest tooling for sketching out ideas ... assuming everybody doing that design exercise is colocated, which admittedly hasn't been the case for the past year. For long-lived documentation, I'd definitely recommend modelling tools over diagramming tools though.
@@simonbrown4821 Thanks so much for clarification and for the talk. It makes more sense on revisiting. The subtitle in the slide says to avoid GENERAL PURPOSE diagramming tools to this end. Makes perfect sense!
@@simonbrown4821 we have used Miro as a shared whiteboard, comes in pretty handy once the team gets the hang of it.
@@simonbrown4821 what modelling tool would you recommend
It would be pretty helpful to be able to read the text in the examples.
31:02 very well said. its an irony at true sense.
15:20 it can be cognitive dissonance , they worked so much on that initial arhitecture that they won't change it anymore cause they consider it beautiful and important OR the software they used or used to persist the design is difficult to use.
@0:58 TECHNOROGY!
good talk though ;)