There are few things that can guarantee failure of your project more successfully than a bad architecture. The truly insidious thing here is that you may not realise the scope of your problems until your first release is out and you're left with an instant legacy disaster that will be a nightmare to maintain and impossible to extend. Here are some semi-fallible warning signs that your architect may not be quite ready for the challenge of building your application.

Your architect has never maintained a system before

Maintenance of an application is a very different thing to building a new application from scratch. Having an existing version or install base requires you to think very differently about what you're doing. In a maintenance scenario you may have to live with all kinds of design flaws because you have existing users who depend on them (or rather your application with those flaws). Someone who's only ever started with a blank slate is less likely to understand and allow for these concerns.

Your architect has never heard of patterns

You aren't an application architect until you understand patterns. Go read the definitive book on the topic and then try again. Patterns are one of the best and most reliable ways of sharing experience between systems. Failing to take advantage of them means you have to reinvent the wheel. This isn't smart.

Your architect wants desperately to use patterns, any patterns

It's unfortunately common that when a developer encounters patterns they start trying to use as many patterns as they can, regardless of applicability. This leads to overly complicated code or scenarios where the implementation doesn't really match the problem and is therefore less effective to build and maintain. Letting this get into the architecture (insofar as this distinction exists) is worse because of the greater scope for trouble.

Your architect wants to use the latest greatest thing but can't articulate why

Odds are if you can't explain why you want to use something in a clear and coherent fashion, you're not going to be able to make effective use of it. Adopt the new when it's useful, not just because it's shiny and all the cool kids are doing it. (You can still jump of bridges if your best friend did it though)

Your architect doesn't have a clear, definitive answer to the question "Where does the business logic go"

In an application you should be able to point to the place where the business logic lives. This place should have a solid boundary that it's not allowed to leak over. It should be distinct from presentation logic and concerns such as data persistence. If this question doesn't have an answer, or the answer is some variant of "all over the place" or "in the user interface" then your architecture is an official failure. You have failed to make your application maintainable, understandable and extensible and you're looking at a whole lot of pain in the future.

Your architect proposes the use of drag and drop tools

There is a place for tools that allow you to drag and drop elements together to create applications that link your database to a graphical user element. This place is in presentations to people who don't know any better or don't care about building quality applications. Sure it looks cool that you can produce an application that shows a grid of data from the database and allows you to add and edit records, and you can do all that in minutes. But where does the business logic go? What happens when I need to do more than just pull the data up and display it? How do I handle inevitable schema changes when every client application talks to my database directly? These tools are an abomination. Shun them.

Your architect thinks that they can use modelling tools to generate most of the application

I like UML, but I primarily like it for what Martin Fowler refers to as "UML as a sketch". I also like code generation, but only in targeted situations which aren't going to involve complex, variable logic (for instance to produce message classes automatically from schema descriptions). Real logic is complicated and has lots of nasty corner cases that must be dealt with. Representing these graphically quickly exceeds the ability of our modelling languages to handle in an understandable way.

What to do when you see these signs

You could fire your architect, but that's unlikely to be helpful. Most of the problems above are due to a lack of experience. Consider options such as mentoring from a more experienced architect. If you don't have such a capacity in-house consider bringing in external experts for coaching and training purposes. If you do take this approach diplomacy is important otherwise your staff may feel unappreciated or insulted and can oppose the efforts to assist them. This destroys the value of the entire exercise.