SOA Change Management

With a layered picture of SOA, it is clear that each layer undergoes a lifecycle – but at different cycle times. Some of the layers have a real-time lifecycle measured in seconds, while others have a lifecycle measured in weeks, months or years. The real-time lifecycles are managed by the SOA platform/tools, while the slower lifecycles should be managed by change management tools and disciplines. Should be. Our observation is that some layers are well-managed, while others aren't.

SOA change management calls for each layer to be properly managed, and the links between layers to be properly managed. We need to know when a change in one layer impacts the next layer. (For example, if the functionality or performance or cost of a service changes, this might prompt retesting of a service composition or closer monitoring of system performance, and may even require redesigning the use of this service.)

And because each layer may be managed independently, change management across multiple layers becomes an exercise in collaboration. We need a publish/subscribe model not just for the services themselves, but for changes to the services.

Impact analysis may be both downwards and upwards. Sometimes the service provider needs some assurance that the service user is using the service properly. (For example, eBay demands certification.)

With proper encapsulation, some changes are private to the service provider and should not need to be notified to the service users. But it is not always clear exactly where to draw the dividing line between public changes and private changes. The service user may be forced to trust the service provider (and the whole service supply chain) to manage this encapsulation correctly, and to publish all changes that may impact the service use. But there are always going to be some service providers who get the encapsulation wrong, and there are always going to be some service uses that are too critical (business critical, safety critical) to rely on network trust alone.

The solution to this is partly organizational and partly technical. 360 degree intelligence tools can monitor the service network, identify patterns of behaviour that indicate significant changes, and publish independent change notifications. Thus you are not solely dependent on the service provider to tell you that the service has changed – you may get an alert because some other user of the same service has started to hit problems. Implementing this kind of intelligence is hard, because it not only requires different bits of technology to be integrated, but also good collaboration between multiple organizations to make the process work effectively.

CBDI Newswire (public access)
CBDI Report SOA LifeCycle (restricted access)

---

Update

Steven Cohn describes some SOA lifecycle requirements that he says go beyond the present capabilities of the Microsoft platform.