Harry Pierson talks about architecture and software architects. He quotes and adopts Alan Cooper 's* view of an architect : "...The architect is responsible for determining who the user is, what he or she is trying to accomplish, and what behavior the software must exhibit to satisfy these human goals..."

I agree that customer focus is a very important aspect of the architect's work - To quote from WWISA's definition of the architect's role:

"Client advocacy is the cornerstone of the architect’s role ... An architect ceases to be an advocate if tethered to a prescribed set of technologies, tools, or methodologies, only narrowing the solutions available to the client…". Marc Sewell in "The Software Architect's Profession: An Introduction" expands this view comparing software architects to construction architects, i.e. the architect role is to represent the client vs. the construction (development) organization.

Nevertheless - I believe that the only way for the architect to accomplish these feats is to do design - no - not "low-level" design of local issues, but yes the design of the overall system, be that partition into business-aligned services advocated by SOA or identifying strategies needed to cope with fault-tolerance (an availability issue).

Yes "Coming up with the lists of functional requirements and non-functional constraints is the architecture problem" (as Harry wrote in a previous post) is an important part of the architect's job - but it is far from being the only part, this is just the preface to the actual work of laying out a solution that can support these requirements and especially the quality attributes (non-functional reqs.). (To use Marc Sewel's analogy) Just as building architects design blueprints for buildings, Naval architects design blueprints for ship building  - the software architect has to draw the blueprints which the development teams will use.

Lastly, Jack Greenfield et. al. pointed out in "software factories" the model of one level of abstraction are the specifications for the next level of abstraction thus the requirements  are the specification of what the system does (without specifying what the solution is) and architecture is the specification of what the solution is (without specifying how it should be implemented)

It is also important to note that the customer is not the only stakeholder whose concerns has to be considered (and balanced) by the architect (see a previous post I made on stakeholders) - This aspect  is even more intensified in "real-life" since the architect is more often than not a part (or hired by) the developing organization and not the client (i.e. you don't usually see a client that hires an architect to represent it vs. the development contractor).

Having said that, I would also like to comment on the quote "architecture is design but not all design is architecture" - what I meant to imply by that is not that architecture is some sort of "good design", but rather, it means that architecture is a certain level of design that takes into account global decisions which affects the whole system (and identifies key local decisions) and that there are other levels of design which are not architecture (what Harry calls engineering)

* Alan Cooper is considered as the father of VB. He is  also the author of very enlightening books on interaction design: "About Face 2.0" and "The inmates are running the asylum"