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.
A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all).
In the context of business enterprise application development, an Architect must act as a bridge between the business and technology communities of an organization, representing and protecting the interests of each party to the other, often mediating between the two, but allowing the business to drive. The business organization's objectives and operating realities should be the light in which an Architect leads technology-oriented decision making.
It seems to be a never–ending source of surprise and distress to system builders that one data model, one message format, one message transport—in fact, exactly one of any major architectural component, policy or stance—won't serve all parts of the business equally well. Of course: an enterprise ( "enterprise" is red flag #1) big enough to worry about how many different "Account" tables will impact system building next decade is most likely too big and diverse for one "Account" table to do the job anyway.