Real world architecture

Okay, so here's the thing - are there situations in architecture that really push you hard, drive you to come up with something of a compromise to achieve something placed upon you outside of your control?
I know that this particularly situation comes up, it's a bit like the 'on the buzzer' round on a game show. You have to think up something really creative to get around the constraint. yes, I know, the company doesn't have mature software development processes, blah blah blah, but sometimes these things happen that push you that bit harder. Come up with a solution that doesn't feel like it's selling your sole to the devil whilst still achieving whatever underlying constraint. I've been there many times, some companies have a better setup so this situation does not arise, but most do not in my experience.
So what do you do when this happens? Is there a core approach to architecture in this situation? I believe that there is, that we can have an initial approach of core process that we can use.
My first point is based around agile projects, all software development is an agile project to one form or another - I've never seen a project where the customer is happy with the outcome and doesn't want to add to it. That's not agile, but it should be! Anyway, I digress - what if you could put the architecture together an not case about such change? What I'm saying there is expect it? Changes the mindset somewhat, it is invigorating to not be constrained by the shackles of inflexibility is it not?

There's a couple of patterns that can help - first and foremost, the factory - delay implementation detail to a later date. This is a great start - its nice to be able to not care too much about the 'how' something should be done, only the 'what'. Okay, so most people are saying 'Duh, that's obvious'. Yeah, it probably is obvious by itself.
So I'd like to introduce the strategy pattern - this is a nice way to again abstract the implementation about from the function. Again, not exactly cutting edge thinking, I know.
Join those two concepts together, and we get something that Microsoft call the 'Provider' pattern. That is music to my ears - we now have a plug-able solution where were care a lot less about implementation. Sure we need to know the intent, but if someone changes their mind, which they likely will, we are happy to accommodate (in the next phase of course)
The second important thing to have in place is unit tests. I talk about them all the time personally. It's like driving without a seat belt, sure, you probably won't have a really bad crash and cause massive injury, but there's nothing like knowing you're creating a safe environment.
The only other constraint is to use proper OO techniques for encapsulation. So for example, you never expose anything like an IList, instead you would expose IPersonList, so you can change its meaning without affecting the solution. Let's face it half of that List<> functionality is going to go unused anyway, so why complicate matters and expose the whole interface? Yes, it's going overboard, but it insulates the project largely from change, and once you get used to doing things this way, it's not a big deal. Just seems pointless until the penny drops...

So, that said, what if you want the architecture to be SOA? Don't care. Why not have both, or some intelligent solution?

I'm thinking that there are people out there who have similar ideas an experiences? Please leave a comment if you do!