Abstract: The notion of a dynamic, federated world of collaborative applications composed from "On-Demand" Services presents a number of challenges to traditional Change Management (CM) approaches. This is particularly apparent in external collaborations where the implementations at either endpoint are not just loosely coupled via the Service, but should be invisible to the remote organization. This raises questions of how and when CM activity should be communicated across the various participants.
CM best practice is well understood at some layers of the SOA Lifecycle. Making changes to the software implementation behind the Service should present few challenges to the existing internal CM process of the Service Provider. But now there are external dependencies created through the Service that must be considered. For example, if the Service itself remains unchanged under what circumstances should it be necessary for changes in the implementation be communicated to Service Consumers? Should the Service Consumer trust the concept of immutability, or should they know when the implementation has changed? In reverse, should the Service Provider test usage when the Service Consumer’s application changes? Or what does it mean for the Service Consumer to move their application from test to production when the Services consumed are already “live”?
Traditionally, interfaces are designed to encapsulate the component implementation and hide change from the application assembler. In reality, because the physical component resides within the same organizational boundary as the assembly that uses it, overall CM can be easily maintained. Changes to the component implementation are visible to the assembler, and the need to re-test is easily communicated. Best CBD practice reported by forum members has been to err on the side of caution and retest the whole assembly even though the service offered by an individual interface should not have changed.
However, with Services any changes to the remote implementation might not be apparent. Is the concept of immutability going to be enough? If the implementation is truly hidden, is there a responsibility on the provider to notify Service Consumers of changes to the implementation? The need to communicate changes will be a factor of the risk, the degree of dependency, and level of integrity required from the Service.
We might expect the Service Consumer to retest their application in response to any notified or visible changes to the Service and its implementation. But is the reverse also required? Should the Service Provider also test the Consumer’s usage of the Service before permitting them access to production systems? Is it just a function of monitoring the Service to weed out badly behaved requests? Or is there a formalized process by which both Provider and Consumer test each other’s endpoints? As well as the above factors this could also be factor of the number of different Service Consumers involved. The more Service Consumers, the greater the need to introduce formality to ensure that some Service Consumers are not impacting the Service in a way that is detrimental to the rest. EBay provides a good example, where users of their API must first get their applications certified before they can use the production Services.
To address these and other issues, CM must evolve to support a collaborative, distributed Service Lifecycle. It is no use having a well oiled CM process that supports one level of activity such as modifying the software implementation, if there is no corresponding process governing the impact of changes to the Services provided or consumed. It also highlights the need for Service Level Agreements (SLA) that cover not just the usual performance and availability, but also place the appropriate CM obligations on both Provider and Consumer with regards to the Service lifecycle, such as the need to notify appropriate participants of relevant changes.
A key challenge will be providing sufficient levels of CM without destroying the promise of dynamic Services, through overburdening the process with bureaucracy. I.e. organizations also need dynamic CM if business agility needs are to be met.
As a starting point, we recommend end-user and vendor organizations first need to understand the SOA Lifecycle. In the recent CBDI report “The SOA Lifecycle”, we discuss the extent to which the lifecycle of services differs from the conventional software lifecycle, and consider to what extent the lifecycle of services looks different from the supply or the demand side. We also consider what opportunities are there for automating and integrating service lifecycle management. A prior report "Establishing a Service Lifecycle", also looks at the additional information regarding a Service that now must be managed and exchanged both across each step of the lifecycle, and between the provider, consumer and other participants. Finally, for an insight on how one vendor is addressing the service lifecycle from a broad perspective, not just CM, see the CBDI report on "HP's Strategy for Managing the Adaptive Enterprise". |
Home