The database is where all of the data, both input by your employees and data collected from your customers, resides. User interfaces, business and application logic, and even employees will come and go, but your data lasts forever. Consequently, enough cannot be said about the importance of building a solid data model from Day One.
Every software architect should know and understand that you can't have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time. There is a true story which software architects should know, understand, and be able to communicate to clients and colleagues.
Failed projects can happen for a multitude of reasons. One of the most common sources of failure is altering the project schedule in midstream without proper planning. This kind of failure is avoidable, but it can require major effort on the part of multiple people. Adjusting the time line or increasing resources on a project are not normally of concern.
A good architect should lead by example, he (or she) should be able to fulfill any of the positions within his team from wiring the network, and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.
Application architecture determines application performance. That might seem rather obvious, but real-word experience shows that its not. For example, software architects frequently believe that simply switching from one brand of software infrastructure to another will be sufficient to solve an application‘s performance challenges.
However, if you aren't looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two week iterations, I'd say performance testing should be included in the process no later than the third iteration.
A big problem in the software industry, in my opinion, is that people are often responsible for solving problems requiring more contextual sense than they've accumulated. Perhaps this is because the software industry is barely two generations old and growing explosively; perhaps it will be a sign of maturity in the software industry when this problem no longer exists.