Most of the article's diagrams are actually terrible in this regard.
It works because (node, edge, node) triplets then form propositions, the fundamental units of knowledge
Come to think of it, expertise researchers still do this today to make rough sketches of domains of study. The result is called a concept map.
This way sometimes the color can describe control, data, and sometimes even teams expected to implement this arrow by color coding teams.
The latter is very helpful for cross team meetings to make each group focus on the part of the diagram that will affect them the most, and give pointed feedback to assumptions and lack in specs
Control: Object/module/function A calls object/module/function B.
Data: The call can either push or pull data.
Build dependency: The call can be direct (A depends on B) or indirect through an interface/callback/etc (both A and B depends on the interface).
Ideally every design document includes all 3 as separate diagrams.
This is why communicating architecture is often as hard if not harder than implementing it.
The database can live without the web server, but the web server doesn't work without the database.
Therefore webserver ---> database.
Key thing in that these deployment / context / container diagrams don't have a temporal axis. If you want to represent a flow, then you want a diagram where time has directionality, like a sequence diagram.
A > B > C