Deferring architectural decisions

When describing the "known exceptions" to the Knot anti-pattern, I wrote the following:

Starting out on a large project, such as moving an enterprise to SOA, is difficult enough as it is. You can’t figure everything in advance; you need to deliver something – so as Nike says “just do it”. Get something done. You do need to be prepared to let go and redesign further down the road

In a comment to that post, Derrick Gibson wrote:

I have concerns about a "just do it" approach; it belies an assumption that at some point in the future the opportunity will be there to do things a "right way", whereas today time does not permit adherence to this mythical "right way".

One cannot put off til tomorrow that which should be done today. There is no guarantee of any future work to do "enhancements" or "architecture" and there is certainly no guarantee that even if there is a future project, you will be around to work on it. The next team will be starting from scratch and they will be left literally scratching their heads asking, "why did Team Alpha make this decision?"

So, if you make the first assumption that your team has to implement the best architecture it can with the time it has allotted, then will that not lead to other discussions along the way that prevent laying the seeds for this anti-pattern?

For instance, would not the use of a service bus and an approach that says each application makes calls to and receives responses from a service bus, free you from having services that call each other? Now, your services are no longer dependent upon other services or even other back-end data stores, so as new processes are defined and/or new systems are implemented (or others retired), your services remain agnostic to those changes.

This requires your service bus to have the logic which says, "this message needs to be routed here, while that message needs to be routed there." Wouldn't this approach resolve the knot anti-pattern before it ever originates?

The concrete  answer to this comment  is that service bus is one of the candidate solutions to solve/circumvent the Knot anti-pattern (as I also mentioned when I described the anti-pattern) - The question it begets  however is how do you know that the service bus is the right architectural decision for the project on the onset?! Ths question has much wider implications.

In "Who needs an Architect?" (a worthwhile reading in itself) Martin Fowler mentions that we can look at architecture as "things that people perceive as hard to change". The conclusion from that that an architect can do her work better if she doesn't impose these "hard to change things" or does that  as late as possible.
My experience is that when you start a "new grounds" project (such as moving an enterprise to SOA) there are a lot of moving parts. What I mean by that is that the uncertainty levels are very high e.g. the requirements are not set, the understanding of the technology and/or domain is partial, team is new and what not. Making a definitive architectural decision, which is "hard to change" and has a lot of effect on how you design your system and/or has substantial costs (both in licensing, training, adoption etc.) is not necessarily the right the decision. In fact, chances are you initial architectural decision will be flawed.

A phrase I heard from Ivar Jacobson once  is "plan to throw one away, you will anyway" - This is something I try to take with me and differ costly decisions if possible. Especially considering initial releases usually suffer from "time-to-market" constraints. To use a cliche - sometimes you need to go slow to go fast. By the way, this is one place where I don't agree with Uncle Bob who recently said "When is redesign the right strategy? ... Here's the answer. Never."

Like every guidance, this isn't always true. For instance, if this is your n-th similar project and you already know enough about it to say that an architectural pattern X (say service bus) or technology Y (say Hibernate) is good then, yeah go ahead and use that. You still want to consider the "cost to change" though since you can still be wrong.