Rich Turner writes about architecture & change. I agree with a lot of what he says.

I often find myself explaining to stakeholder (PMs, developers, etc.) that the only constant thing in the project is that it is that it is changing :)

One project I am currently working on,  exhibits this inherent change - For one the  customers don't really know yet what - they want (think) that they would be able to use the exact same solution for a  several very different configurations (ranging from standalone computer to a server farm with dozens of clients) etc. 

What do we, as architects, can do to handle these situations? Well, what I usually do is add a lot of modifiability related quality attributes (see utility trees) these can include requirements for interoperability, adaptability, changeability etc. etc. (An example scenario may be: provided with a verified algorithm,  replacing an existing navigation  algorithm shall take less than 3 man-weeks).

While I will (probably) talk a lot more on strategies for handling quality attributes in posts regarding modeling (as part of my SAF posts), SOA (sans hype…) is a good strategy to cope with flexibility (i.e. changing requirements). The explicit boundaries and contract first approach help localize changes  also the resulted loose coupling help to replace, add and remove services easier, Lastly the basing communication on policy helps postponing issues that has to do with the network (QOS, security etc.)

A completely different angle on the issue of changes -  is that sometimes it can be problematic to allow it, even at the expense of missing some of the customer's changing requirements. An example (maybe the only one) is for critical systems, where a defect can result in loss of lives  (two polar examples are medical systems on the one hand and weapon systems on the other). In order to be able to ensure software safety (Identifying hazards, proper fault tree analysis etc.) there's a need to affix the requirements for longer periods compared with other types of projects.