A world of difference between "I want to build things and I have studied how to build things" and "I have studied how to build things and would like to tell other people how to do it".
The perception might indeed be due to the existence of people labeled as architects who are indeed removed too much from actual developers' problems.
I believe that the software architect's job actually consists in making everyone else's work on the project possible (so each project stakeholder must be satisfied):
- give to the PM everything needed to estimate, plan and organize the work and budget - make sure that testers will indeed be able to test the system - make sure that the analysts understand what is being built and delivered, as well as understand how to document the requirements so that everyone else will be able to understand what is expected - make sure that the sponsors and senior management understand what they'll have and allow them to be convinced that the design is sound with regard to ASRs - make sure that the developers understand how to develop, which components, the interfaces.... - make sure that admin and ops people know how to install and operate and update and uninstall the system - make sure that the DBAs are satisfied with the documentation provided to them - ...
Given this definition of the job, it is clear that an architect has to understand everyone's work, their inputs and outputs, and can't work alone in his ivory tower. It looks like actually most actors in the market just don't know what responsibilities and practices software architecture actually encompasses.
Architecture evaluation may be seen as the way to prove that the architecture meets the quality and feature requirements. That's nothing short of helping doers show that what they do is indeed what they are paid to do.
I guess that when architects become talkers, it's a sign that they are not close enough to the technology or implementation any more. And indeed, talkers don't help do stuff, they talk.
As jdwyah[1] said[2], there is a HUGE difference between "here is what academia thinks architecture should be..." and "in the Real World™, here are a few ways we can architect this..."
I had the ... umm ... 'privilege' to guest in a friend's class several years ago on software architecture from a "pure engineering" perspective (whatever that was supposed to mean). He was pursuing an MS in CS (and, ftr, has done quite well for himself in the Real World™ (mostly by ignoring academia)), and had to take this "pure" architecture class during his time at the university he was attending.
His "professor" (a recently-minted PhD who had not even spent so long as a summer internship out of the ivory towers of academia) was pontificating on how software should be written the day I was visiting.
She asked me, being the Guest of the Day™, how what she said stacked-up against an honest-to-God, publicly-traded software company. Pretty sure she expected me to say something like, "we aim for those goals, but sometimes miss". Instead, I answered the class honestly: "none of what she said matters if you cannot deliver a security fix, or patch, or new version to your customers in the next few days - they do not care about you, and will leave for someone who will do what they want".
-------
[0] https://www.joelonsoftware.com/2008/05/01/architecture-astro...
Despite being told that it’d be a thing to help “modernize us”, what exactly do other people - both in and out of the IT world - actually thing an “architect” does? In deep time I might have equated it with something like “systems analyst” before that title was more concrete; someone who understood how things went together.
Just never as a thing in a divorced-from-the-doing like I see now, from people who have even, ostensibly, done some development, or at least coding, yet seem to lack a basic grasp on 1st and 2nd year IT concepts (DB normalization?), or, perhaps, brush aside whatever they might know in favor of letting the DB “architect” (modeler) take that fall.
it’s a jungle out there