@christian I disagree.
Some software architects may operate like this, but their architectures are as removed from reality as building architectures drawn by architects who have no hands-on experience with materials like steel, rock, glass and concrete. Both kinds of ivory tower architects will produce architectures that are impossible to build in real life.
Most software architects I know does not necessarily consider themselves to be software architects.
But assembling large heterogeneous systems consisting of various materials, applying different patterns of communication to different parts of the system and ensuring that both individual parts and the whole make sense, is most definitely software architecture and is an essential skill and interest to have in order to produce usable and maintainable systems.
Not all developers have or needs to have this skill, though. But someone within a team do, or else they’ll produce unmaintainable big balls of mud.
@christian I agree it’s more of a role than a position.
“Software Architect” can also work as a position as long as they are aware of the correlation between distance from code and unrealistic architectures, and continually combat architectural issues rooted in what over time develops into code illiteracy.
Combatting these issues doesn’t necessarily mean the architect needs to write code themselves, but it’s the best solution, imho.
Other strategies are to listen to the team, take advice from developers with architectural traits, remain humble to other developer’s opinions and experiences, and incorporate that feedback into the architecture iteratively.