When I started to work professionally as a developer, I was fascinated by the role of software architect. Somebody who could design software, decide how modules interact together, write lots of diagrams and specify a system.
I think those days are long gone.
Although my career hasn't been particularly long so far, I've already seen lots of changes in the software development world. Maybe because I started in an environment which - for questionable reasons - wasn't really up to date with emerging trends (even though XP wasn't really emerging anymore in 2008!), but I feel it's been ages. It's been ages since we felt we needed UML class diagrams, it's been ages since we thought inheritance was the solutions to all (ok, not all, but lots of) duplication problems, it's been ages since we thought that code was the problem.
People working as developers would progress their careers - and both they decided to go into management, or stay "techincal" by becoming architects, they'd spend less and less time coding. As all aspiring software craftsmen know, coding is a craft, and a craft can only be perfected with practice. Think about how do you feel going back to code, if you had a two week break without a keyboard. Surely you'll feel comfortable again not in a long time, but you'll always have a feeling of rustiness.
Often, software architects spend their days in meetings with management, thinking about what product to buy (based on the one they feel comfortable with...) and to use in the next big upcoming project. And, unfortunately often, development teams have to live with the decisions made by architects, that in a very good number of cases don't have a proper idea of the real state of the application, and why a particular decision could or could be not appropriate to the project.
Development teams should be empowered to have decisional power on technologies and software architecture. After all, only the one who puts his hand in the code on a daily basis is the one that knows which tool is fit for the job, or if you should separate layers in your applications. Of course probably not everybody in the team would have the experience to make an informed choice, but a well formed team would definitely make a better choice. After all, they'd pay the price of a wrong choice at the very beginning. Teams that choose their tools and systems are also the teams that feel their project really "their project", improving productivity and quality of the software.
Do you really think you need a Software Architect? Or you just need to have experienced, trusted and adequately empowered developers?