I've worked on several projects where the architect was like a seagull. He swooped in, dumped a lot of poop in the form of PowerPoint pictures of the architecture, and left as soon as possible. He didn't stick around for the hard part of the project: making the product work in this architecture or evolving the architecture so that the product could work by the time of release.2 But if your architect is overly fond of drawing programs and not fond of writing code and can't really answer the developers' questions about how to make the parts fit into a coherent structure, you don't have a real architect. Eliminate that person from your project, and build time into the project for assessing the architecture as you proceed. Add the lack of architecture as an explicit risk to your project so you can manage it. Not every project requires an architect. If you have no architect, your sponsors should recognize that your team needs time to assess the architecture and see what patterns are emerging. It's possible to have an architect who acts as a consultant to the project. It is harder when you have a consultant-architect—Murphy's Law implies that the architect will be busy on another higher-priority project when you need him or her most.
I'm reading the book Manage It! and found this excerpt that talks about seagull architects. I hope you like it.