I see the architect as the technical lead who shepherds a product through the overall design, someone who explains enough about the system and how it hangs together so that the other developers can take their parts write/design them (in whatever way works for them). I now believe in as-little-as-possible design-up-front and as-much-as-possible emergent design. Because I see the architect role as a shepherding role, I see the architect as immersed in the project, and integral part of the project team who needs to continue to participate to see when things go south.
But I wonder if some of you are thinking about the architect as more of a consultant. The more up-front design and architecture you do, the more you can try to create the architect-as-consultant role. Certainly, architects for buildings do become “merely” consultants once the general contractor starts the actual construction. (Yes, this is one more reason the building construction metaphor doesn't work for me.) If the role of the architect on your project is more of a consultant, then I can understand why you disagree.
I'm going to have to think about ways to make the architect-as-consultant model successful, even if I don't believe in it. (For me, this all points to feedback for the architect.) Certainly, many of my clients believe in and use that model. Just because I can point out ways that it doesn't work doesn't mean these folks can or are willing to change. So, I'll be thinking about ways to make it work–and the risks involved. (This will make the organize-your-project-team chapter easier to write too. Duh.) I may well ask you for your comments.