Author "Software Architecture for Developers" | Creator of the "C4 model for visualising software architecture" | Founder at Structurizr | Software architecture training at architectis.je
There are certainly different uses for software architecture diagrams, yes. If I'm doing an up front design exercise, I'll tend to use a whiteboard or flip chart paper. This allows me to focus on sketching out ideas, and it's much easier to do collaborative design with a larger physical space. I'd still use the C4 model (in terms of the abstractions and hierarchical diagrams), but I might not necessarily follow all of the notation guidance. These diagrams tend to form a starting point, and they are usually short-lived. Once we start coding, and I want to start creating long-lived documentation, I'll switch to a tool. Another use case for a tool is for proposal/pre-sales purposes, where you want to show some software architecture diagrams to accompany a "this is our plan" type presentation. Those diagrams tend to be quite short-lived too.
Ignoring up front design (where I still think a whiteboard is the best option), I think we can do better as software engineers, and I don't think we should be using general purpose diagramming tools at all for the creation of software architecture diagrams ... short or long-lived. "Modelling" has some unfortunate associations with heavyweight design processes, but I believe that we can change that with better tooling, as I illustrated in Modelling software architecture with PlantUML, for example. My goal is to help teams create better looking, and more consistent, software architecture diagrams more quickly than they can with a general purpose diagramming tool.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are certainly different uses for software architecture diagrams, yes. If I'm doing an up front design exercise, I'll tend to use a whiteboard or flip chart paper. This allows me to focus on sketching out ideas, and it's much easier to do collaborative design with a larger physical space. I'd still use the C4 model (in terms of the abstractions and hierarchical diagrams), but I might not necessarily follow all of the notation guidance. These diagrams tend to form a starting point, and they are usually short-lived. Once we start coding, and I want to start creating long-lived documentation, I'll switch to a tool. Another use case for a tool is for proposal/pre-sales purposes, where you want to show some software architecture diagrams to accompany a "this is our plan" type presentation. Those diagrams tend to be quite short-lived too.
Ignoring up front design (where I still think a whiteboard is the best option), I think we can do better as software engineers, and I don't think we should be using general purpose diagramming tools at all for the creation of software architecture diagrams ... short or long-lived. "Modelling" has some unfortunate associations with heavyweight design processes, but I believe that we can change that with better tooling, as I illustrated in Modelling software architecture with PlantUML, for example. My goal is to help teams create better looking, and more consistent, software architecture diagrams more quickly than they can with a general purpose diagramming tool.