I've received the same question during a number of C4 model workshops recently ... "the people who are not in this workshop won't know what the C4 model is all about, so we'd need to teach them about it before they understand our diagrams ... so what's the point?"

Let's step back for a second. If a team is using UML, the same thing applies ... the diagram consumers/readers need to understand the subset of UML used on the diagram(s). In the worst case scenario, this means reading a good chunk of a 750+ page spec -> omg.org/spec/UML/2.5.1/PDF

The same applies for ArchiMate, SysML, etc.

This doesn't apply if you're using an ad hoc collection of "boxes and lines". BUT, in my experience, most ad hoc collections of boxes and lines don't make any sense whatsoever, so the diagram author is required to literally explain the diagram, or risk people misunderstanding it.

Although many people think there's a "C4 model notation", this actually isn't the case. The C4 model is a set of diagram types, based upon a hierarchical set of abstractions.

I do, however, have some recommendations related to notation (be explicit about element types, add descriptive text, use unidirectional arrows, have a legend, etc) that are aimed at making diagrams more understandable without explanation. These apply to UML, ArchiMate, etc too.

With all of this in mind, the combination of (1) the small number of abstractions and diagram types along with (2) the notation recommendations, tends to make the C4 model easy to explain, and the diagrams easy to read.

In order to communicate, all parties need a shared language. Unfortunately there are no shortcuts, and no silver bullets. But we can certainly aim to minimise the overhead.

Very rarely, I'm directly (and sometimes aggressively) asked, "why are you reinventing UML, and not teaching UML?" ... to which my response is, "why are you not using UML?". 🤷‍♂️😂