Great article - very well written, very concise.
I've found that there are three areas of Architecture relating to Software Engineering.
One is Functional Architects - who often also fit into the Business Analysis area. These are the people who take a look at the massive bucket of user requirements and somehow transform them into nice neat functional packages. This like changing an accounting system into areas such as Accs Payable, Accounts Recievable, Payroll, Journaling, General Ledger etc. I've seen good functional architects take pages of assorted ramblings and produce very elegant and concise representations of the system - the kind of representations that can be used to further drive the development of specific functional areas of the application. Quite often these people have either moved from the business area into IT or are people who long ago moved out of hands on development.
The second area - Technical Architects (Sometimes also Systems Architects) - these are the people who know that for a system requiring x thousands of transactions a day, for x amount of distributed clients, based on the Functional Requirements (from the Functional Architect) tell you if you need n-tier, client - server, thin client, messaging, RPC, transaction gateways, etc. These guys are responsible for putting together the design of the technical infrastructure.
The last area - what I think of as the Software Architects - although could also be referred to as Code Architects or Code Designers - are the people who put together the software code infrastructure that all the developers workinside - increasingly these architectures are prefabricated in vendor products like websphere, but in very large applications these are the people who decide on the elegant algorithims, who are really big on Design Patterns.
After this there I think that there is an associated area of the Super / Uber / Alpha / Artist Developer - this is the person who comes along and in smaller specific areas works the magic that takes your 1st year stupid bubble sort algorithim of array data and changes it into a sorted tree structure, how makes that process only take 5 minutes instead of 3 hours.
A lot of this depends on the scale of the systems being built. The bigger the system gets, the more the need is there for the components of the Architecture - Functional, Technical, Software to become more specialised.
Conversely, as systems get smaller, and as bigger systems get simpler to develop the role described as "Software Architect" becomes more of a Jack Of All Trades of a good senior allrounder - someone who can atlk to a client and refine functional details, who knows enough about hardware / infrastructure software to design the infrastructure, and (although this is only really on smaller projects) may know enough to help with the coding.
As the systems get bigger, the knowledge and time involved in any one of the branches of the architecture area gets so big and demanding that I can't imagine anyone having enough time to do all of them. And as other posters have mentioned, coding is something that needs regular practice to remain proficient.
I know on one project we locked the Project Manager / Technical / Functional Architect out of the source code system - not because he wasn't any good at coding, but because he spent so much time doing the other roles (this was a moderately sized project - 6 people, 1 year) that they didn't have the detailed knowledge of the code to be effective (read: avoid breaking things).