Yoni Commented  on my SAF - Deployment post :

"Somewhere in your blog you've mentioned Martin Fowler's "Who needs an Architect" article in a positive way. However, it seems that in contrast to Fowler's notions of an architect who's job is to "remove architecture by finding ways to eliminate irreversibility in software designs" - you are advocating making long-term binding decisions in the initial stages of the development cycle"

It is very hard to argue with Martin Fowler (as Gregor Hohpe put it in a recent post "Now who would want to argue with Martin Fowler? His opinions are facts " ) However, I think that devising solutions for flexibility (such as the database schema example in the article) are also architectural decisions. What makes things even "worse" is that these decisions are usually made at the expense of other quality attributes (e.g. performace) or other project constrains (e.g. time to market) - meaning that a decision on flexibility is a making  tradeoff  or in other words an architectural decision "par excelance".

Thus - architectural decisions, by definition,  are early  - whether we like that or not. Furthermore, Flexibility is an important quality attribute, one the architect brings into the table (in the same way that other stakeholders bring their concerns - e.g. the Project manager who want the project to end on time and on budget). It is the architect's role to balance quality attributes, understand the tradeoffs and make the decisions that will enable the project to achieve its goals. Many of these decisions have to be made early so that the project can move on, some of these decisions have to be made early to prevent ad-hoc architecture (un-balanced, spur of the moment decisions that will be hard to change). I believe very few decisions can be postponed without doing anything (i.e. without making some active decision to introduce flexibility).