Making a Change

For the next few months, the Center of Excellence paid off. Projects were identifying services early in the lifecycle. Those same projects were successfully identifying other potential consumers of these new services. Implementation technologies were being chosen correctly and interface design was being properly done. Most importantly, everyone felt the SOA effort was on track.

By this time, it had been almost two years since Spencer’s team developed the Customer Information Service for the auto insurance and home insurance divisions. While these two groups were very happy with the results, no additional teams had leveraged it. Outside of the annuity project, this wasn’t a case of projects going in another direction; it was more due to lack of opportunities. That was about to change.

Spencer was eating lunch in the cafeteria when Ramesh walked up. “Mind if I join you, Spencer?”

“Hey Ramesh, it’s been quite some time. Go ahead and pull up a chair.”

“Do you remember two years ago you tried to convince Ryan to use your Customer Information Service?”

“I sure do. I didn’t want to show my face in the annuity area for about a month after that. He really wasn’t very receptive to the idea.”

“Well, I have some good news and some better news for you. The good news is that about six months later, Ryan decided to leave Advasco. The better news is that we’ve now got a major initiative to revamp a number of our systems in the annuity department. I’d like to take advantage of the Customer Information Service as part of that effort.”

“That’s good news Ramesh. I didn’t harbor any resentment towards Ryan, but I’m certainly happy about having another potential consumer for the Customer Information Service. I’ll put you in touch with the service manager for it.”

“Thanks Spencer. That would be great. We’re just getting started on our architecture, so the timing is perfect.”

“Let me know if you run into any problems. I’m still part of the SOA Center of Excellence, so it’s still my job to make sure it goes well!”

Spencer put Ramesh in contact with the service manager for the Customer Information Service, Maria. Maria had recently transferred over after her work on the account maintenance effort, and now had responsibilities for the Customer Information Service. In the meeting with Ramesh, she brought her technical lead, Craig, with her

“Spencer told me that you’re interested in utilizing the Customer Information Service in some of the new systems you’re building in the annuity department, Ramesh.”

“That’s right. We’re rewriting a number of our systems, and based on what I remembered from Spencer two years ago, I thought we might be able to leverage the service.”

“Great, I’d be happy to help you out. This is Craig, the technical lead who covers the Customer Information Service. He’s here if you’ve got any technical questions. Have you had a chance to review the information available in the service repository?”

“I have. I reviewed the service interface, and while it certainly looks like there’s enough there to warrant using the service rather than building our own, there’s also a number of additional things that we’ll need.”

Craig responded, “What kind of changes are you looking for? Are there new operations that you need that are specific to the annuity area?”

Ramesh said, “There are two or three operations that we’d like to see, but most of the changes are actually in the message schemas for the existing operations. There are some additional attributes that we need, and some of the relationships between the attributes are different in our representation.”

For the rest of the meeting, Ramesh and Craig went through the changes that Ramesh wanted to be made to accommodate his needs. In the end, it was clear that some changes to the existing schemas would have to be made. Maria asked, “We’re going to need to go back and look over these changes, along with the integration approach for your existing database. What does the schedule for your efforts currently look like?”

Ramesh replied, “We’re still in the initial stages of planning, which is why I wanted to make sure I talked to you now. Right now, the project sponsors would like to have something within six months, but they also know that nine months is far more likely. Since I have some flexibility in my schedule, why don’t you take a week to look into the effort required for the changes, and let’s work out the schedule then. Does that work for you?”

“That works for me. We’ll get back to you next week with what we think it will take to implement the changes.”

On the way back to their desks, Craig commented to Maria, “You know, while I don’t have any concerns about getting the work done for Ramesh, I do have some concerns on how these changes are going to impact our existing consumers. Some of these changes are going to break the existing interfaces.”

Maria said, “That is a concern. I know that there aren’t any resources available to do any work on the home insurance side of things. Any suggestions on how we should handle this?”

Craig said, “Well, we definitely should make the existing consumers aware that a change is going to be made and at least get a clear idea of what the impact will be. If you can take care of that, I can take this to Spencer and the SOA Center of Excellence, and see what suggestions they have.”

“That sounds like a good plan to me,” replied Maria

Over the next week, the Customer Information Service team did the analysis required to estimate how long the changes would take to implement. Maria used the communication features of the service registry/repository to push out a message to the existing consumers about the pending change, and as she suspected, the biggest problem was going to be the home insurance system. Due to other priorities, the earliest they could even begin to make changes to their consumer would be nine months from now, potentially three months after the service needed to go live.

Craig met with Spencer and explained the problem to him. Spencer agreed to facilitate a decision-making session to explore the different options. Representatives from all of the existing consumers were there, along with Ramesh, Craig, and Maria

Spencer started the meeting, “I’m sure all of you saw the notification from Maria last week that some changes are necessary to the Customer Information Service in order to support its usage by the annuity department. The problem that we face is that these changes will break the existing consumers of the service, and not all of you can make the changes to your systems in the currently proposed timeframe. Let’s start out by listing all possible options, regardless of whether we all presently agree or disagree on their viability.”

Craig started out, “Well, if we’re listing all possible options, the first one is toupdate the service, and then get whatever push we need from management to get resources allocated to the consuming systems so they can make the changes in the time required.”

Maria replied, “Come on Craig, you know that we can’t just pull resources off projects that easily.”

Jason, from the auto insurance department, added, “Aren’t all of these changes a result of the annuity department? Why can’t they just include modifying our applications within their project scope? They already have resources allocated to their project.”

Paul, from the home insurance department, replied, “Do you really want some developers that have never seen your application before mucking around in your code? I know I don’t.”

Spencer said, “Let’s remember, we’re listing all options, regardless of whether we all know that the option won’t fly. We want to make sure we’ve explored all of the options. I’m going to just leave this as one option, since we still wind up with the same result, regardless of where the resources come from. I’ll capture the concerns about the option.”

Paul, from the home insurance group, added, “Okay, here’s another option. Why don’t we leave the existing service in place, and simply have the annuity project write a new service that just they use. Then, none of us using the existing service would be impacted.”

Craig replied, “That’s true, but isn’t that going against everything we’re trying to do with SOA? I thought we were trying to avoid redundant implementations of the same capability.”

Spencer replied, “Duly noted, Craig. Just as with the last option, let’s keep it on the board, and I’ll make sure that your concerns are captured. Paul, that option actually triggered another one in my mind. In addition to having Maria’s team write the new service for the annuity system, why couldn’t they also keep the existing version of the service available in production for the rest of you? You can then migrate as your schedules allow.”

Paul and Jason both replied in tandem, “That would work for us!”

Maria jumped into the conversation, “While I’m sure it would, that sets a very dangerous precedent for my team. How many versions of the service are we going to have to maintain? While it’s a little bit better when all the implementations are owned by one team, we still have multiple implementations.”

Jason then asked, “Isn’t there a way to make the new service backwards compatible with the messages associated with the old service? That way, Maria’s teamwould only have one implementation, but we could each continue to use our existing interface.”

Spencer replied, “That’s a very good question Jason. While we all agree that the service interface needs to change to support the annuity department’s requirements, I don’t know that any of us have thought about whether we can easily transform messages associated with the previous version to messages that will work with the new version, and vice versa. Craig, you’re the one most familiar with the new proposed schemas. Do you think we could leverage XSLT to apply transformations for backward compatibility?”

“Yes, I think it’s possible. The only concern I have is what impact this will have on the service implementation. Working with XSLT within Java code isn’t the easiest thing to do, and as we make future modifications, that’s just going to get uglier and uglier.”

Spencer said, “There’s another option for that. A year ago, we put some XML appliances in place for security purposes. I know they have XSLT capabilities and they’re already in the request path.”

Craig replied, “Of all the options, I think that one would work out the best. I really don’t like the idea of maintaining multiple versions of the service, and having to maintain all of that XSLT code within the service is only slightly better. Allowing the annuity group to write their own goes against everything we’re trying to do with SOA.”

Spencer said, “Well, we know where Craig stands. Are there any other options that we should look into? No? Well, what does everyone think?”

Paul was first, “We know that we’re not going to find resources to make the changes in all of the consumers at the same time, so that option is out. Likewise, it doesn’t make sense for Ramesh’s team to write their own service given our SOA goals, so that one is out, too. As for whether Maria’s team maintains two versions of the service or utilizes some transformations somewhere, it really doesn’t matter to me. From my perspective, both options give me the freedom to migrate at the time that works best for me.”

Jason immediately added, “I agree with everything Paul just said.”

Ramesh then offered his opinion, “Well, I certainly know that I don’t want to give up any of my developers to work on Jason’s and Paul’s systems. We need every developer we can get right now. As for writing our own service, we’ve already been down that path two years ago, and now we’re obviously changing the system again. If we had migrated to the service earlier, it would be one less thing that we had to touch as part of these changes. As long as Maria’s team delivers my service on time for my projects, it doesn’t matter to me what Maria’s team chooses to do on their side.”

Spencer replied, “Well Maria, it looks like everyone else thinks that we need a solution that will allow all of the consumers to continue to use their existing interfaces or the new one, but the details of how that happens is completely up to you and Craig.”

Maria said, “Let’s not jump to conclusions yet. If I’m going to maintain multiple versions, I need some kind of guarantee that the existing consumers will eventually migrate to the new version. If my team allows continuous use of the old interface for 12 months from the time the new interface goes live, would that be an adequate time to complete whatever modifications are necessary?”

Jason and Paul thought about it and decided that this was reasonable. For the past three years, they’d averaged an update every nine months.

Maria said, “I’ll make sure to remind you, early and often, that the old version and its associated interfaces are going to be decommissioned. In the meantime, I’d like to first get the new version built. I’m going to need to keep both versions around initially just to compare messages. Ramesh’s team can begin using the new service, and…” As she was talking, she stopped mid-sentence.

Spencer said, “Is there a problem, Maria?”

She replied, “Well, I was just thinking, how are we going to avoid having two URL’s out there? The existing consumers are using a URL that points to the XML appliances, right? We want to apply transformations to that path. What URL will Ramesh’s team use? We don’t want to try to apply transformations to their requests.”

Spencer said, “Fortunately, I don’t think we’ll need to do that. We’ll need to talk to the team that operates the appliances to be sure, but I’m pretty sure that the appliances can apply processing based upon incoming attributes on the message. As long as we can determine which requests came from which consumer based on the message content, we should be able to control when transformations happen, while having all the existing consumers using a single URL. We’ll obviously need multiple URLs behind the intermediary, but that will be hidden from the consumers.”

Maria replied, “Okay, that eases some of my fears. Just make sure you find out quickly whether the appliances can handle it or not. Until we find out, can we set up a simple routing rule so that requests from the annuity group go to the new service, while the old ones stay where they are? That way, Ramesh can use the new service as soon as it is available, and Craig and his team can start working on the transformations for backward compatibility. I’d like to wait and see how that work goes before deciding whether to leave both versions out there for 12 months or to leverage the intermediary. We’ve never used that functionality before, and I don’t want to take a chance on impacting Ramesh’s schedule in case we run into difficulty. By keeping both services available in production at first, we can eliminate any dependency between the decommissioning of the old service and Ramesh’s schedule.”

Craig added, “From my point of view, that shouldn’t be a problem. I can treat the new version as if it were a completely new service, as long as the intermediary shields the consumers from that change. I will need to check how we can manage both versions at the source code level, though.”

Maria responded, “Good points, Craig. Taking all of this into account, I think this approach poses the least risk overall.”

Spencer said, “Then we’re all in agreement, right? Maria’s team will build a new version of the service according to the new interface, and the old interface will be available for 12 months from the time the new service is deployed. Initially, both versions will be available in production, but Maria can decommission the old service before 12 months are up, so long as the new version can be made backwards compatible via XSLT transformations. Maria will notify all consumers prior to decommissioning the old service, since regression testing will be required to ensure that backward compatibility has been maintained. She will also notify all consumers as we get closer to the 12 month cutoff when the older interface will no longer be supported.”

Everyone in the meeting agreed with this approach, and the teams went off and made it happen. Craig’s team investigated the best way to apply the transformations, testing them using the latest Java libraries, as well as the XML appliances that Advasco had recently installed. They found that the XML appliances performed very well, and kept the programming model of the service very clean. While the Java libraries performed satisfactorily, the resulting programming model was not as clean as the team desired. With the use of the routing rules in the appliance, they were able to remove the older version of the service from production, while still supporting the older messages for the full 12 months as promised.