I used to work heavily in this kind of system modeling (developing tools for it, and dogfooding), and still use it when high-value for figuring out or communicating an aspect of a system.
Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams.
It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talking about a domain.
You usually have to know or learn a lot about the domain, and/or have an domain expert you can walk through it exhaustively, before you can find errors.
And an error can be whopper: a single graph edge missing, or between the wrong vertices, or with the wrong adornments can have huge implications.
For example, large amounts of work that have to be redone, or a project abandoned, or a mess that takes 10x longer than it should to write, and 10x the tech debt going forward with a bad architecture, or a fundamental security flaw.
One of the mistakes many people make is treating formalized diagrams as "marketecture" visuals, like they only need for handwaving sales presentation slides, where there's some kind of visual for every concept they want to be able to literally point to.
Nope, if you have software engineers and domain experts communicating and reasoning about your system in only the fuzzy terms of sales/exec presentations, you're really stabbing yourself in the face.
Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams.
It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talking about a domain.
You usually have to know or learn a lot about the domain, and/or have an domain expert you can walk through it exhaustively, before you can find errors.
And an error can be whopper: a single graph edge missing, or between the wrong vertices, or with the wrong adornments can have huge implications.
For example, large amounts of work that have to be redone, or a project abandoned, or a mess that takes 10x longer than it should to write, and 10x the tech debt going forward with a bad architecture, or a fundamental security flaw.
One of the mistakes many people make is treating formalized diagrams as "marketecture" visuals, like they only need for handwaving sales presentation slides, where there's some kind of visual for every concept they want to be able to literally point to.
Nope, if you have software engineers and domain experts communicating and reasoning about your system in only the fuzzy terms of sales/exec presentations, you're really stabbing yourself in the face.