Admittedly, I've been struggling with the "Architect" title in the IT world. It is not that I think there's no role for architecture, far from it, but too often I've encountered architects who focus too narrowly on architecture, losing track of the realities of actual software development and the context in which the software will be used. I wonder, if there was no "Architect" title and people who are responsible for architecture would be called guide or coach or tech lead, or just the senior developer, whether things would be better.
About a year ago, in a discussion about architects, rather than trying to define what an architect is or does, we looked at what he or she should know. We expressed our ideas as mini-essays, strictly limiting ourselves to one per essay, and it turned out that, at least to my surprise, there was a lot of agreement; maybe because we hadn't come up with hard and fast rules but with ideas and guidelines.
Luckily Richard Monson-Haefel was part of that discussion and he had the resolve and means to make our thoughts more widely available. Our list of the 97 things every architect should know was collected and refined on this wiki, and is available under a creative commons license. For a more convenient read it has now also been published as a book by O'Reilly. As expected, the discussions have begun.