Why you need a stated "service versioning policy"?

I felt I needed to expound on the topic of service versioning after I heard concerns from a few CIO level executives about needing to "support" multiple service versions. The reason stated was that maintaining multiple service versions was expensive from both a hardware and on-going support perspective.

I completely support this opinion in that if left "unchecked" - read without the right level of governance - this could turn into a maintenence nightmare (not to mention a regulatory hazard especially if the regulatory policies are not implemented uniformly across all versions). But then this is a case for having governance and not an argument against supporting service versioning policy.


I attempt to outline some reasons for defining and publishing a "service versioning policy" to support both the business need and to create an efficient resource-utilization operating model. A carefully thought out strategy of service versioning that is rigousously "governed" allows us to do some of the following:

1. support multiple versions where in business functionality may be altered based on the operating business context or business area or industry vertical
2. support multiple versions based on the user community needs (for example, invoking a service that incorporates work-flow rules vs. needing a service that is invoked as part of an automated process level interaction)
3. support multiple versions that allow an enterprise to reduce the risk to the business when introducing new business behavior or new business process optimization changes
4. support multiple versions of a service that allow the enterprise to incorporate and interject additional authorization, entitlement and audit related rules that change based on the business context and/or business user role
5. support multiple versions that allow the system administrators to provision server resources appropriately based on the QoS/SLA needs of the service consumer and the service contract definitions.
6. support multiple versions of a service to isolate more expensive business behavior calls to specific versions so as to reduce impact to all of the other consumers (For example, a version with externalized business rules while the business is "testing" a new rule would be less performant than a version where the business rule is ratified and encoded into the business logic layer. In this example the business behavior is externalized making the service version more flexible but this makes the service less performant)

Finally, I think that service versioning can be used as a strategy to both support the business need and to optimize resource utilization that in turn make consumer interactions more efficient. Thus, the "appropriate service version" is invoked based on the "right" business context.

Your comments on this topic are invaluable.

Thanks.

surekha -