Architecture diagrams answer the following question:

You can replace "parts" with "components" or "entities" or "things" or whatever you need.

If this is true, then architecture diagrams don't need all the garbage you typically see -- a million different symbols and shapes all to represent the fine-grained details of the system. All those little details aren't necessary to answer the question.

For a "part" you need a rectangle with a label.

For a "connection" you need an arrow with a label.

Dude...that's it. You can 100% answer the question that an architecture diagram needs to answer with labeled rectangles and arrows.

Try it. It's simpler to create. It's simpler read. It's simpler to change.

Arrows should only point towards dependencies.

You can't make an architecture diagram if you don't truly understand how the parts are connected.

For some reason people like to use arrows in these diagrams to show data flow but that sucks because it doesn't tell you which of two connected parts knows about the other. Data flow in general can almost always be shown as a two-way connection -- one part sends some data (e.g., request) while the other part responds with some data. This data flow can reasonably be implied with a one-way dependency connection. If you really do have a two-way dependency where both parts know about each other, then use two arrows and properly label them; you might want to sanity check your design if you have this situation.

Color code things if that helps - but only use a couple of colors.

Keep it small and focused. Make other diagrams to dig deeper into the "parts" of other higher-level diagrams.

Don't forget you're answering the question: