Tuesday, May 13, 2008

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 -

2 comments:

Integral ):( Reporting said...

Surekha:

thank you for focusing on this problem. Service Versioning is actually central to SOA. A lot of people dismiss this question and claim it is solved by some "routing" capability in an ESB.

In reality, SOA is about "reuse" and Services can rarely be reused as is when a new consumer shows up. The key to SOA is to be able to support new consumers without breaking existing ones. The central concept that no other technologies bring to the table is "forward compatibility" (See Dave Orchard's articles on the question). Forward compatibility is the key to avoid keeping all kinds of service versions in productions.

It is important to note that Service Governance, if always desirable, is not often practical. How often can you bring all potential service consumers to the governance table? how often can you predict the needs of a particular consumer 12 months from now? In reality, Service Versioning with Forward Compatibility, allows an imperfect governance process. This is what makes reuse successful.

Anonymous said...

All the objects and services need to have version control. It's odd that so few enterprises deal effectively with many instances in a production environment. Managing the transition states is impossible if you don't have this type of control infrastructure. Although CA and other vendors offer pieces of the puzzle we have only found one small vendor, alfabet meta-modeling (www.alfabet.de.

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...