[Spearchucker]

This I agree with, other than prescribing n levels - many projects don't need more than 1, most only need 3 (conceptual, logical, physical).

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

[redact207]

I've been a dev for about as long as you were and keep flirting with the idea of moving into a dedicated SA space. How do you feel about the current trend towards togaf and ITIL? Are the useful, useless, good to cherry pick?

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.

[FourthProtocol]

Both TOGAF and ITIL certifications are a great way to land a job as an architect, but (especially true in the civil service) these documents often become the deliverable, project outcome be damned.

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.

[blub]

I like C4 because the diagrams are easy to understand irrespective of the industry and those diagrams cover an abstraction span that's impossible to cover through one diagram. I didn't get the feeling that it has to be 4 diagrams and I pick and choose myself.

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.

[simon_brown]

> I didn't get the feeling that it has to be 4 diagrams and I pick and choose myself.

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

[simon_brown]

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

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.