A software architect job is about interfaces between modules. An architect job is to design interfaces that are aligned with the product direction and technical capabilities (both of the product and the people developing it) and tell a consistent story, both syntactically as well as semantically.
Without such a person, each pair of developers, no matter how good an engineers they are, will have to develop their own language that is bound not to match those that are developed around it. This adds to the burden of each developer as he (or she) has to use APIs developed by different such teams. Consistency is key.
Because the architect has to see the big picture to do his job, it makes sense that he's also the look-ahead guy. Because he defines interfaces and modules, it makes sense that he gets to evaluate new technologies - so playing with rabbitMQ really is part of the job description.
This kind of job tend to require a working knowledge of the product internal, otherwise APIs can get completely incompatible with capabilities. As such, it attracts good developers that also think "strategically". Because many architect still love the code, you usually see such a person wearing two hats - the classic architect one but also the "lead developer" one - so code reviews, cleanup work and super important (but small) modules tend to be part the architect work, even if not in the job description.
Lastly, the architect must have soft skills. The job requires a lot of human interaction, considerably more than a developer job does. It also requires a much closer interaction with "management", the architect understands the aforementioned big picture.
Is the architect "better" than any developer? No. It's a complimentary role. Is this role always needed? No, but as a project gets bigger and start having more modules, interfaces tend to get hairy without a guiding hand. So why do architects make more? Supply and demand. Not everyone has the ability or the will to think "big picture" all the time. It's tiring, it's complex and you tend to think about balances (how will this affect the future? How much risk? How many man-hours? What's the alternative? How to phase development?) instead of "code purity".
Disclaimer: I'm an architect but I also do a lot of "lead developer" parts. And while the definition tends to get fuzzy around the edges (and some interfaces are made ad-hoc, without that guiding hand), I see the best results when I follow the above recipe (which, sadly, means a lot less coding than I actually like to do).
TL;DR: architecture is about interfaces between modules, not content of each module. Usually architects also wear "lead dev" hat because they like it.
Is the architect "better" than any developer? No. It's a complimentary role. Is this role always needed? No, but as a project gets bigger and start having more modules, interfaces tend to get hairy without a guiding hand. So why do architects make more? Supply and demand. Not everyone has the ability or the will to think "big picture" all the time. It's tiring, it's complex and you tend to think about balances (how will this affect the future? How much risk? How many man-hours? What's the alternative? How to phase development?) instead of "code purity".
Disclaimer: I'm an architect but I also do a lot of "lead developer" parts. And while the definition tends to get fuzzy around the edges (and some interfaces are made ad-hoc, without that guiding hand), I see the best results when I follow the above recipe (which, sadly, means a lot less coding than I actually like to do).
TL;DR: architecture is about interfaces between modules, not content of each module. Usually architects also wear "lead dev" hat because they like it.