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.
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).