An architect, on the other hand, is first and foremost concerned about the business.  It is the architect who is responsible for deeply understanding the business' needs and turning that into a vision for a software solution that truly meets those needs.  By business needs, I mean more than just basic functional needs but also its other needs such as IP protection, customer security and confidentiality, scalability, responsiveness, integration, interoperation, and perhaps most important, fiscal responsibility.  All of these are in addition to meeting basic functional requirements, and there are surely viewpoints that I have failed to mention and many that are peculiar to distinct domains.  But the point is that the architect thinks and speaks firstly in terms of business concerns, not in terms of technology.

Implied in this is the more stereotypical responsibility of thinking of the "big picture."  It is indeed a big picture, so big that often pieces of it are neglected when the architectural role is not sufficiently recognized, articulated, and supported by the business.  I've heard it suggested by many that our biggest task is to make the business realize the benefit of design documentation, but I really think what we meant and should have been focusing on is helping the business to realize the distinct need for an architectural role and that, for a project of any size, you really need to give that role full-time attention and support.  What documentation comes of that is an artifact of the particular process being employed; what is indispensible is not the fact of documentation but the fact of ensuring that all the various viewpoints for software are given sufficient attention. 

To adequately address all the viewpoints for successful (not just snazzy) software, one has to think primarily in terms of the business, and it is this kind of thinking that an architect should do.  An architect is not concerned about particular technologies except in as much as they enable her to create a software solution to her business' problems.  This obviously doesn't mean that an architect can't enjoy or be passionate about technology; it's just that passion about technology and freedom to express creativity in terms of a technology rank below passion to create a software solution that precisely meets business needs.

Naturally, I would suggest that it would be best for architects to have a development background as I think it would help them to better understand the demands placed on developers to implement a proposed architecture, but this also implies that architects need distinct training (or equivalent experience) in business to understand the needs of the businesses that they are serving.  That said, I can imagine an architecture degree based on a blend of solid computer science and solid business principles that could sufficiently prepare a person for a junior architecture role without that person needing to first work as a developer.  In fact, I would see such a development as a valuable indicator that we are sufficiently realizing the distinction between the two roles.