Thinkers are rare, doers are rarer, thinker-doers are rarest. Fred Brooks
Seasoned IT craftsmen know from experience - your initial intuitions about the system design will turn out to be embarrassingly wrong. There’s a paradox here: the more you’ve been designing systems - the more distrustful of your initial intuitions you become. Probably, it’s an example of Dunning-Kruger effect.
So having that distrust, good architect will look for an effective way to burst the bubble of those initial intuitions. Nothing does it better than formalizing your design into code. You need to get into the minutia to get a feeling of “that’s not right”. This feeling should make you zoom out and check maybe you are yak-shaving, maybe your modules/services are too pristine, lab-coat, “recommended practice” induced. There’s no substance there.
Then you simplify. Try to understand the essence of the problem. To be on-point with your design.
Drawing a diagram of your initial intuitions will not do the trick. You put your delusions into a nice picture. Solidify it and communicate it to others in this solid visual form. The more likely effect here - you will reaffirm you delusions: “See? The picture looks good!”
Writing your ideas into a high-level design document will reaffirm your delusions in pretty much the same manner.
I’ve seen speculations that it’s sufficient for an architect to do testing of the system. I don’t see how that will burst your initial delusions about system design at all. Do you?
