Over at The Server Side, there's a discussion about how to become an "architect". Though TSS comments often turn into a cesspool, I couldn't resist adding my own two cents.
I should also add that the title "architect" is vastly overused. It's tossed around like a job grade on the technical ladder: associate developer, developer, senior developer, architect. If you talk to a consulting firm, it goes more like: senior consultant (1 - 2 years experience), architect (3 - 5 years experience), senior technical architect (5+ years experience). Then again, I may just be too cynical.
There are several qualities that the architecture of a system should be:
- Shared. All developers on the team should have more or less the same vision of the structure and shape of the overall system.
- Incremental. Grand architecture projects lead only to grand failures.
- Adaptable. Successful architectures can be used for purposes beyond their designers' original intentions. (Examples: Unix pipes, HTTP, Smalltalk)
- Visible. The "sacred, invisible architecture" will fall into disuse and disrepair. It will not outlive its creator's tenure or interest.
Is the designated "architect" the only one who can produce these qualities? Certainly not. He/she should be the steward of the system, however, leading the team toward these qualities, along with the other -ilities, of course.
Finally, I think the most important qualification of an architect should be: someone who has created more than one system and lived with it in production. Note that automatically implies that the architect must have at least delivered systems into production. I've run into "architects" who've never had a project actually make it into production, or if they have, they've rolled off the project---again with the consultants---just as Release 1.0 went out the door.
In other words, architects should have scars.