To solve these problems, you do need some sort of common language. Switching to UML potentially solves many of these problems, but teams don't want to do this for various reasons. As noted on the website, the C4 model is an abstraction-first approach (with only 4 levels to learn), although the simple notational tips do aid comprehension.

Note that people in the protection (life insurance) industry will see no ambiguity in this diagram. Note also that this diagram is contained in a Vision/Scope document that provides disambiguation (each box is described), responsibilities (and all stakeholders) defined, and all abstractions. Haven't anonymized that document so it's not online. Obviously no one on the team works alone, so it's made clear to all.

Largely based on the Microsoft Solutions Framework from many years ago because it's still the best tool in this space. And by god after 20 years as an architect and before that 14 as a developer I've seen my share.

I respect the effort brought to bear here, but there are existing solutions and frameworks out there, from the terrible (6 Sigma or EDS' BCL Framework) to the excellent (MSF 3, parts of the UML).

Also did you enjoy your last 20 yrs as a SA compared to if you stayed in some type of development? I'm quite interested in your back story as there's not a lot of seasoned SAs where I live.

Just getting certified will alter your thinking in a good way though. It shows you in what kind of environment and how many large enterprises work, and there's use in that.

Yes I enjoyed it. You need to keep yourself honest though. Once async/await came along I doggedly stuck to message queues because it's what I knew. And then I wrote an app using async/await and felt like a fool. It can be humbling.

And I stay in development by writing a lot of code at home, sometimes at work to demonstrate a thing. An SA who doesn't maintain dev skills is not as effective as one that does.

I moved into EA about 5 years ago, and my next move would've been CTO, except that I resigend last year to write software I hope to make a living from. I'm lucky in that I managed to sell a solution I developed about 12 years ago for myself to an enterprise for enough money to not have to work for the next 10 years at least.

I like like architecture/design, and perpetually live in the persuit of perfect technical documention (what I wrote 10 years ago and thought of as good was... terrible), so of course I'd recommend it.

I get it that the example you gave works for your project, but if I took that and transplanted it into mine I'd expect a lot of questions at least about the relationships (arrows) and probably also about the responsibilities of the components (boxes).

Having a textual description of the above certainly helps and should be done, but people tend to focus on the diagrams and ignore the text in my experience.

Correct. I get the feeling that most teams using the C4 model tend to stick to the top two levels - System Context and Containers (these levels also "age" slower than the others too).

That's a fair point, and I'm occasionally asked why I'm "reinventing" UML too. Again, that's a totally valid question. If teams are using one of the existing approaches/notations, and it's working for them, I recommend that they stick with it.

But the majority of the teams I work with either (1) have no diagrams/documentation at all or (2) use collections of ad hoc "boxes and lines" diagrams ... usually "because we're agile". In many cases UML, ArchiMate, SysML, MSF, etc are not even on their radar. In others the teams are simply not interested in using these existing approaches, for a number of reasons.

https://domainstorytelling.org/

I really like the approach of event modeling recently:

https://eventmodeling.org/

That seems a little strong. We're talking about a potentially complicated system in a technical field. Some standardised notation and terminology could be helpful to keep the visuals concise and unambiguous. I agree that this looks far too complicated, though.

So I think it’s not a worthwhile investment. The non-techs can’t create or edit and typically can’t read. The techs don’t use it for what they are creating.

I’d rather spend time on docs in the actual system components or teaching non-techs enough to read autogenerated docs or walk through code that actually is the system. Then couple that with block diagrams written on whiteboards or powerpoints or whatever. If you get to the point you need notations it’s too complicated and point them to the appropriate source.

This isn’t easy. But I think it’s easier than pretending that both sides learning an artificial middle language (uml, etc).

Because construction analogies are stereotypical if you are building a building. A big, expensive skyscraper. If your construction workers speak English and your financiers and architects speak French. I think you’re better off investing in hiring some people who speak both languages than in making them both speak German to work on blueprints.

I have often seen a group of developers discussing something and then someone sketches a simple diagram showing entities and relationships, transitions of a finite state machine, or message-passing similar to what UML would call a sequence or communication diagram.

However, in my entire career, I have never seen anyone actually draw out fully annotated UML diagrams using the official notation, nor any instance of some of the numerous diagram types UML specifies. And that includes working at places where everyone had been given UML training!

"The C4 model doesn't prescribe any particular notation. A simple notation that works well on whiteboards, paper, sticky notes, index cards and a variety of diagraming tools is as follows."

Curious to know what makes you think it's too complex? What am I missing?

Disagree. It might not come across so great in written form but I watched this person give a presentation on this model and it was one of the best I’d ever seen. Probably the most logical way to explain a complex system. And then he rolled out the library he had written that could generate these diagrams automagically from Spring code... mind blown.