Have you ever been in a meeting where someone is trying to explain how a software system works?
I was having a conversation with a relatively new ...
For further actions, you may consider blocking this person and/or reporting abuse
Are these diagrams your own notation? Or do they follow a diagram specification?
The only mention I saw was related to the Persona diagram: "The architecture persona diagram dips into the BPMN model".
It would be worthwhile adding something about modelling languages that architects use such as UML. While in meetings people may scribble boxes and lines free-form to get their message across; for documents people tend to follow a modelling standard.
Thanks for sharing and starting some good comments.
It’s all about audience and ease of diagramming in my view.
We use Lucid charts with C4 and Wardley diagrams and old-school Ciscoish network diagrams, 2x2s, sequence diagrams etc etc. Whatever works for the situation at hand and the audience. If it helps to bend the rules I’ll do it rather than present an intricate but correct xyz diagram that’s effectively write-only.
I like Lucid because you can import from databases, cloud providers etc. and because it is feature rich and very easy and intuitive and you can generate Visio for those using that.
I agree with the levels and descriptions of each and believe they will all be effective for the audiences you have described. We have standardized on using C4 Models as it provided a comprehensive framework for modeling in general. It was very easy to choose several required models for each project and point to optional models when they make sense. I believe draw.io supports C4 however we have adopted PlantUML with a C4 extension.
Goof job, thanks! The role of solution architect in software development is to provide technical guidance to help clients build solutions that are secure, reliable, cost-optimized, and fault-tolerant.
To me all the examples shown look the same "box and arrows" diagrams, with the "Persona" one slightly differentiating since it uses "swimlanes" ...
UML has plenty types of diagrams but for me the most useful are Use Case, Class, Sequence (or activity, here's on with lanes), and Deployment diagrams. You d better familiarize yourself with those and use them when appropriate (Note, I am not fond of complex formal "enterprise-y" design processes, but a common notation is usually useful...)
There it is! There was the pieces of the puzzle that brought it all together for me! Ty ty
Good article. I think we miss articles that are not code focused. Software engineering is not only about code.
I'm not a trained architect but I've explained difficult topics to various groups. I don't do enterprise/business architecture so my angle is always "technical".
I find the following information to be conveyed in a solution
For some reason, everyone expects very detailed sequence diagrams to be the silver bullet for everything. I don't get, plus I don't think that too much detail in a diagram serves any purpose unless you assume you work with code monkeys. In my experience, architecture is to set up the dancing hall but the engineers including the architects will do the dancing as the night progresses.
I prefer plantuml though it has it's problems. This is because of its nature in code that can be easily added in any source repository and align with the branch. It is also easy to inject in any other system that would use the script as a master source and generate other artifacts and if necessary allow for translation of the master version. I worked for technical documentation.
Hi Allen, this is a very good read! As a senior cloud developer, I work with diagrams almost every day of the week to create proposals for clients. I usually just use Infrastructure and Flow diagrams in my work. But with this post, I think it would be worthwhile to use the other diagrams as well, especially the ones for business people.
I can't see how the example Persona diagram could be of much value to product owners. They're generally concerned with what the system does, and for whom, rather than how it's done.
Also in that diagram, and most of the others, there are unlabeled icons that require very specific knowledge to understand. Product owners are unlikely to recognise which one stands for an AWS Lambda function, nor understand what that is or why they're looking at it.
For system diagrams, I think the C4 models are pretty good. We use the context and container diagrams only, since the others are far too low level for most purposes. They're pretty simple but they require labelling every node and edge which avoids the problem of someone having to guess what they're looking at based on a fancy picture of a disk or lambda symbol.
But I don't even think the C4 diagrams are very relevant to product specialists -- maybe the system context diagram can be good to just illustrate which pieces we are responsible for, etc.
Perhaps of more value would be old school use-case diagrams or similar UML ideas.
Separate artifacts create silos and slow communication. I address all of these diagrams with Event Modeling. It acts as a blueprint that serves the purpose of all of the above.
Just this week a designer helped me draw my architecture/flow diagram. I could then use the diagram to explain the various components in play as well as the sequence of events - far easier than lots of text.
I'm concerned though, like any documentation, it gets out of date.
Thank you for your article.
For each audience you need to diagram and explain differently. Good article!
thanks..
Agree.
Great article, I can relate to a whole lot of what you wrote here! Diagrams are critical IMO whenever designing a system or documenting an existing one.
A nice guide here for targeting the right audiences, will definitely refer back to this for my own diagrams.
Nice share bro.
I totally agree with you.