In my 20 years in this field I can easily count on one hand the times a diagram like this has been useful. I’ve seen more cases where they were clearly created to satisfy some exec that wanted to see it and never updated again.
orthoxerox 22 minutes ago [-]
The most common mistake I've seen is not agreeing on what arrows represent: control or data. Does A-(customer data)->B mean A asks B for data or A sends customer data to B?
Of course, sequence diagrams make it clear with two separate arrows when control and data flow in different directions, but a lot of diagrams are of the "plain old boxes and arrows" variety.
zabzonk 13 minutes ago [-]
In high-level diagrams, which I think is what is being discussed here, I like to think that A --> B means that A "uses" B in some way, and leave it at that.
segmondy 3 minutes ago [-]
yup, A interacts with B with the interaction originating from A.
kingforaday 22 minutes ago [-]
Their master diagram example in #3 contains a #2 mistake with an unconnected resource (the stripe account). Maybe a double validation of why the master diagrams can be hard to maintain.
zabzonk 1 hours ago [-]
Couple of comments:
> This can be as simple as adding a type suffix to a resource name (e.g. Orders Table, Results Bucket)
Don't encode types in names. And I disagree somewhat that the names are really needed at all.
> Making a “master” diagram
I think such a diagram is useful but obviously each top-level "box" in it doesn't need to contain all sub-components.
tremon 1 minutes ago [-]
And I disagree somewhat that the names are really needed at all
You want a diagram containing only icons? You will still need a legend somewhere that explains what each icon means, otherwise you will end up with at least as many interpretations of the diagram as there are readers of it.
I'd say that that first image as shown is useless anyway. There is little value in just laying out resource components without linking them to system operation in some way.
gruez 33 minutes ago [-]
>Don't encode types in names.
Why? Hungarian notation probably is probably going too far, but in cases where a single word is heavily overloaded encoding types is helpful (eg. image file, image table, image bucket).
zabzonk 17 minutes ago [-]
I don't think the type needs to be in the name because it is displayed elsewhere in the diagram, possibly as the object's icon. Plus of course the reasons no-one uses Hungarian anymore - types change.
And for your naming, I would probably have something like "Unnormalized orders", "normalised orders", "queued orders", but obviously I can't tell without much more information.
datadrivenangel 50 minutes ago [-]
Diagrams are communication tools, and are best done with a target and goal in mind. The C4 framework is good for addressing multiple levels of abstraction and different types of viewers. The business execs don't need the level of detail that someone debugging the system does.
ashwinnair99 1 hours ago [-]
The worst ones are diagrams that look clean but hide all the decisions that actually matter. A messy diagram that shows the real tradeoffs is more useful than a pretty one that lies
chaps 40 minutes ago [-]
Once worked with a systems architect who intentionally disorganized their flow diagrams by just moving nodes in their flow to random places (hi Dan!). The only reason I can think of why he'd do that is to maintain job security by keeping the junior apps folk confused.
Rendered at 14:06:49 GMT+0000 (Coordinated Universal Time) with Vercel.
In my 20 years in this field I can easily count on one hand the times a diagram like this has been useful. I’ve seen more cases where they were clearly created to satisfy some exec that wanted to see it and never updated again.
Of course, sequence diagrams make it clear with two separate arrows when control and data flow in different directions, but a lot of diagrams are of the "plain old boxes and arrows" variety.
> This can be as simple as adding a type suffix to a resource name (e.g. Orders Table, Results Bucket)
Don't encode types in names. And I disagree somewhat that the names are really needed at all.
> Making a “master” diagram
I think such a diagram is useful but obviously each top-level "box" in it doesn't need to contain all sub-components.
You want a diagram containing only icons? You will still need a legend somewhere that explains what each icon means, otherwise you will end up with at least as many interpretations of the diagram as there are readers of it.
I'd say that that first image as shown is useless anyway. There is little value in just laying out resource components without linking them to system operation in some way.
Why? Hungarian notation probably is probably going too far, but in cases where a single word is heavily overloaded encoding types is helpful (eg. image file, image table, image bucket).
And for your naming, I would probably have something like "Unnormalized orders", "normalised orders", "queued orders", but obviously I can't tell without much more information.