SOA Development - Service Versioning Policies

Elena met with Spencer later on in the day and relayed the conversation she had with the CIO. At the next meeting of the Center of Excellence, Spencer brought the team up to speed on the discussion between Andrea and Elena. He went through the efforts associated with Maria's Customer Information Service, and then asked the team for their thoughts.

The first person to comment was Jared, "I'm really surprised that this got Andrea's attention. I don't think any of the services that I've worked with yet have needed to be touched since version 1.0."

Another team member, Ron, concurred, "I agree. We've only had one service in my area that's had to be modified since its initial release, and in that case, it only had one consumer that moved in lock-step."

Raj countered these statements, "I have to disagree with you. In my area, we have at least five services that will be modified in the next six months. I think Andrea and Elena are right to have us look into this."

Spencer added, "Yes, remember, they didn't ask us to tell them whether there was a need to deal with versioning or not, they asked us to come up with some policies to ensure that when versioning does occur, we have some standard guidance on how to handle it."

Raj quickly offered his opinion, "I have some thoughts on this. Services are all about consumption, right? We've all said that a service is no good unless it can be consumed, right? Well, if that's the case, shouldn't we do whatever we can to accommodate service consumption? I think we shouldn't put a limit on the number of versions of a service interface that must be supported in production. In fact, I think we should make it a requirement that a service provider supports whatever interfaces are currently needed by its consumers. While my area is the one that has a number of changes coming, those changes tend to be driven by one consumer. Most of the other consumers don't change very often, probably even less frequently than when your services might change, Jared."

Jared countered, "Raj, I have to disagree with you. Trying to maintain a potentially limitless number of service interfaces would quickly become a nightmare for the service development team."

"But are you willing to sacrifice consumers for the sake of having a smaller number of interfaces to manage?" Raj asked.

Jared replied, "Remember, I've worked in the commercial software world before joining Advasco. The company I worked for had made so many different versions of our product to meet the specifications of our customers that we got ourselves in trouble. We had to make a change to a single capability, but due to all the branches that had been made in the code, the effort took months longer than it should have. As a result, we lost customers, not because we didn't make changes when they first came along, but because we had no ability to change quickly when a number of customers required the same modifications."

Raj responded, "I can see your point, however, I don't think that means the service providers can go to the opposite extreme and expect that consumers will incorporate whatever change they decide to throw out."

Spencer decided to interrupt the debate, "You've both raised two important, yet conflicting viewpoints. On the one hand, we have the service consumers. These consumers expect to have their demands met, and if there is an alternative path that meets those demands more quickly, they'll probably take it. This leads to a desire to bend over backwards to meet the demands of any consumer, even if it means having many, many versions of the service. On the other hand, we have the service providers. In order to provide good service, the team needs to keep the number of versions it provides to a minimum. While it's all managed by one team, we're really creating the exact same problem that we have today—the same logic being implemented in multiple places, and as a result, the time required to implement a change goes up."