Supporting Dynamism in Architectural Level

In the past decade or two, there were several attempts to come up with a proper way to support the dynamism in software architecture. Different approaches such as architectural style based, graph grammars and Architecture Description Languages (ADL) based models were also introduced.
According to my understanding the actual constraint comes when we map the dynamism that can be seen in the design to the implementation. The barriers posed by limitations in operating systems, programming languages and hardware would take some time to resolve. But our approach as software architects or engineers to find ways to support dynamism in the design level. That’s only the first step there are bunch of other questions to be answered.
I came up with a typical set of questions that to be answered and not limited to, in supporting dynamism in the implementation level, are follows.

1. How to analyze run time changes? And how to analyze them in run time?
2. How to map run time changes to implementations.
At the end what ever the design, we have to map the design into an implementation.
3. How the implementation platform supports run time changes. What changes to be done in the platform level? If not feasible, what are the alternatives we can find?
Constraints in languages, operating systems, tools need to be considered
4. How to preserve the system integrity? How to prevent any security violations?
5. What are the cost effective ways to implement changes?
6. What approaches associated with lesser risk

Change management in Services Oriented Architecture

Also if we map the question in hand to the Services Oriented Architecture, what are the approaches we have taken in terms of supporting dynamism and change management? It is unavoidable as in other software systems; the components (mainly services and consumers) too need to be evolved over the time. Especially the continuos availability of services is concerned. So the services need to be changed due to following reasons.
1. Change of requirements that are initially set.
2. Change in the environment
3. Changes due to fixes and patches

Advantages in Services Oriented Architecture

The SOA model itself has some characteristics that support the dynamism
1. Loosely coupled nature minimizes problems in services dependencies
2. Service descriptions makes it easier to propagate changes to other systems
3. Abstract business logic hides details from its consumers via encapsulation
4. Stateless behavior
5. Self described nature
6. Re-usability
7. Ability to compose or assemble services

So the above characteristics make systems in SOA to show more support in dynamism than the conventional systems. But are there any specific issues related to SOA, in supporting dynamism? This is going to be a god research topic I think.