Architects have to have a big picture attitude. They need to focus on technology for long time. They need to be generalist.
Look at an architect as being a bit like a flight traffic controller. They determine where the pieces go and how they relate to each other. It is a very fine line to be able to walk.
Not only is there a large technical knowledge required, but also a great deal of common sense. An architect should be able to see the entire project landscape and how to get there, all the while promoting new technologies to provide efficiencies, introducing frameworks and concepts, documenting and describing the path chosen, plus (in my opinion) being able to jump in and get their hands dirty.
Most architects I have worked with have a stellar understanding of the language or platform that they are working on. Additionally, they should be extremely well versed in how code can be used to create and meet repeatable goals, stable releases, and an all around good performing product that meets the goals of the project.
Some specific things that might help:
I have worked in shops where architects have too much power and authority. It is very important to remember that you are a team player, first. The architect should be an expert that people can look to and who will provide guidance. Wisdom and judgment are very important.
In addition to the obvious knowledge, skill and experience, I've noticed three characteristics.
They read about software developement a lot.
They talk about software developement a lot.
They know what they know, and they know what that don't know ... yet.
Software development is still (at least in historical terms) a pretty young field; there are no universally accepted certifications, and job titles can be indefinite enough that they can't be relied on to mean the same thing across different organizations.
Where I've worked (which has been in a fair variety of smaller shops, but few really large organizations) such titles haven't had clearly defined meaning beyond "senior" - to the extent that "architectural" decisions are made, they're generally made by the most qualified people (read "most senior") and in the best places are made after much collaboration and discussion. I've only worked in one place where someone at a very high level made large-scale decisions that were then rigidly propogated down the chain of command, and even as a junior it wasn't terribly enjoyable.
The job title also seems deceptive in that it seems to imply that architecture is sort of a separate beast from development, where in fact they're more like points along a continuum, from higher to lower level development, and I've never seen architectural decisions that were not modified on contact with lower-level necessities.
Another aspect of this is that the kinds of decisions and considerations that push you to thinking in larger-scale terms are often already made on many projects, especially if you're coming in to an established team/project and doing mostly maintenance work - this is probably why most programmers like building new things.
Keep in mind that architect in not always a position you get promoted to, but also a role you grow in, and you end up occupying full time.
And there are various forms of "architects", either technical (development-oriented with Software Architect, or a more senior position with Enterprise Architect), or functional (with a deeper knowledge about the customer business).
For me, a good way to get to that position has been through "advanced support" (in my case, technical support), where you must provide good technical frameworks all other teams must base their work upon, or development environments (IDE, but also versionning policies) all others must use.
Since those are sensitive topics for developers, you will be judged on your ability to listen and adapt your solutions to respond to the problems meet by your colleagues.
That relationship aspect is really what I enjoy the most: you have to meet face to face with many (often very very) good developers, pragmatic people you can not (and of course do not want to) bluff in any way, and you have to offer them concrete solutions.
The only drawback is that kind of position is only a sustainable one as long as you maintain the level of trust you have with your peers. That keeps you on your toes.
What does the developer community think about architects?
The term "architect" is heavily overloaded in the software industry. And even more heavily overloaded when one thinks of software versus non-software companies. But generally there are two schools of thought. The first tends to lump all architects into the architecture astronauts camp, and is very suspicious. The second tends to regard architects as a necessary evil.
Why are some people promoted to architect?
In non-software companies, the most common reason is to provide a career path that is technical, without having to go into management. The architect role isn't usually seen as integral to the company, but as a way of keeping the best IT people.
In software companies, architecture is integral to the company's work. People are often promoted to this role once they demonstrated a strategic view of software development within the company.
Who is interested in becoming an architect?
In software companies, it's often developers and program managers who are both very competent and very experienced. In non-software companies, it's often developers who are both competent and understand the company's business.
What actions do people take to reach that goal?
I can't comment on software companies, as I've never worked for one. But in non-software companies:
I can only comment on my own experience in developing as a programmer to a software designer and then software system architect. I now refer to myself as a software designer/architect no matter what title I might have in a given work relationship.
First, I find the Microsoft work on architects and architecture rather interesting for its careful identification of the different kinds of architecture that are involved (e.g., infrastructure, solutions, and enterprise). It is important to differentiate. There have also been valuable webcasts on development as an architect. Most of this is not specific to Microsoft technology.
With regard to having task knowledge and ability to work hands-on, my sense is that this becomes necessarily limited except for two things: There must be enough technology knowledge so one could dive in and can certainly guide other developers (at the solutions level and deeper). In addition, an architect may hold the reins to critical invariants and may actually own the specifications and code that are tied to that. This is similar to the architectural role involving defining and preserving the critical interfaces and the separations of concerns via the chosen architecture.
Now, with regard to my own experience, I started out as a highly-inquisitive programmer and then software developer in the late 50s and early 60s. There was ample opportunity for being self-taught and also follow the work that would grow into software engineering, software quality-assurance, and various development methodologies, including reliance on programming languages.
What I noticed for me is that I moved farther and farther toward concern for design and organization of my software efforts, both through learning from the software of others, through reading in the literature of the time, and in wanting to understand how to make software designs explainable and the implementations confirmable and conceptually understandable. I also found myself very attentive to modularization and the creation of useful libraries and related tools.
This observation is in terms I use now, looking back. At the time, my interest was not so well-articulated. There was mostly a certain restlessness and wanting to have ways to be confident in my work and my understanding of it. In fact, preserving my confidence in approaches and how I demonstrated success was a consistent presence as I learned to grasp larger and larger development situations. The level of abstraction of that confidence was raised gradually without my noticing so much at the time. I also think it paced the raising of our grasp through use of more powerful tools for development and attention that was paid to growing a body of practice.
In the 70s-80s I saw myself as a software designer. But it was really in the late 80s and 90s that I began to notice how much my attention was on the end-to-end, full software-development/deployment lifecycle. It was also in this period that I was viewed as and acted as an architect (although my first Architect title, as such, was in 1972). My attention was also on how projects fail and how developers often have their attention on the wrong ball. So I was also interested in what would have developers pay attention to factors that would allow them to have more successful results. I was a big Fred Brooks, DeMarco, and Yourdon fan.
In this century, I have been impressed by the emergence of software engineering and software-development management as disciplines with a substantial body of knowledge (as illustrated in the work of Steve McConnell), and the emergence of agile development and management is inspiring to me. I find myself working at a more-abstracted level, also.
With regard to development itself, I am now a little dismayed at how poor the on-ramp for entry-level software developers and budding computer scientists is. It seems we have forgotten something or maybe we never really new it, but I see gaps in how people become experienced and raise their level of mastery, and wonder what kind of preparatory support would be more effective.
Although I write less code these days, I still enjoy it and I notice it is often in challenging areas that others have left behind or that are simply not part of the current developer kit. Part of my fit for that is I remember how to work at those levels and more-recent developers have never been exposed to them. I don't think that is a problem so much as the lack of fundamental understanding that I think is also missing. I'm not sure what would bridge that gap and still be relevant for the level at which developers now finding themselves working.
Architect is sometimes (not always though) used as a name to have people who cannot code great code themselves feel important since they're still valuable for the organization but have been bypassed by others hired after them...
Though the CEO sees their contribution and see that they're still important to do "communication" between customers and coders so they raise their salaries and give them a fancy title...
I've been in the architect role for a good percentage of my career, and for me it meant "super programmer".
Knew the whole system, moved the system architecture technically, was involved in a most of the platform decisions. The projects were way too large to do it all, so delegated implementation of portions of the system changes to other Software Engineers.
That is an example of the good part of architect. I'm sure alot of architects aren't this, but in fact just have a better title, pay or tenure.
1) Architects are a level away from the code in designing systems for various business processes. This may require in-depth knowledge of a technology if it is heavily used in a company, e.g. some may need to know a lot about ASP.Net if a company has a handful of web sites that the architect has to manage. They come up with the plan for various systems would be another way I see them.
2) In some companies the promotion may be because the person has been around the systems long enough to have a great deal of in-depth knowledge of how things work, e.g. ERP and CRM. I can see it being a bit above a developer as there isn't the troubleshooting angle like there is for developers.
3) I would think a lot of developers that like to make plans and handle more of a strategy angle want to be architects and as the title becomes more common, hopefully there will be some form of standard kind of like what exists for developers where there are many interpretations but there is some commonality.
4) To achieve this goal, some may want to apply for an architect position at another company to try to move into the role that way while others may graduate into it if the company is successful and grows so that the old guys get that position.