He continued, "It seems that the thing we need to do is to come up with a policy that balances the needs of both the consumer and the provider. We clearly can't have an unlimited number of versions, but we also can't have just one version available."

Ron replied, "In the case of my area, we sometimes don't touch an application for 18 months."

Raj added, "My department is the same. I'd say that the majority of applications are only modified once every 12 to 18 months, with a few even longer than that."

Jared commented, "We have more turnover in my area. Just about everything gets released at least once a year. The few applications that don't, usually wind up getting decommissioned in the next year."

Spencer asked, "What's a realistic timeframe for service updates? In the case of the Customer Information Service, we almost went two full years without needing an update. I also know of at least two other services that have been updated every six months."

Raj replied, "Our services follow a similar pattern. I haven't seen anything that's updated more than twice a year. Some services are updated every nine months; some are updated every 12 or 15 months. There doesn't seem to be a standard pattern."

Spencer then said, "Let's look at this from a different perspective. Since it appears that all of our systems are updated at different intervals, let's instead look at what's realistic. We know maintaining one version of the service isn't enough. If we maintained two versions of the service, the worst case would be that the consumers only had six months to make their changes, presuming a new version was released every six months. If there were 18 months between versions, they'd have 18 months. If we maintained three versions of the service, the worst case now goes out to 12 months. If version 1 was in production, and version 2 was released in March, version 3 would be released in September, and then version 4 in March of the following year. That's also assuming that consumers aren't notified until the version goes live. What is more likely to happen is that version 2 would be announced early in the process. Realistically, a system using version 1 would probably have about 14 to 16 months to make their change. For a service that is only updated every 18 months, we're now talking about three years or more to make the necessary changes."

Raj replied, "What if the service is updated every two months, or even more frequently than that?"

Spencer answered, "While it's certainly possible that a service could be updated more frequently, do we really think that the interface would change that frequently? I'm sure if we have projects that are updated that frequently, it is probably more likely to be bug fixes or other small changes that don't cause any change to the service interface. If the actual service interface does change that frequently, I think that the service team probably hasn't done a good job in seeking out potential consumers. They are probably being reactionary, and waiting for consumers to come to them. If we take the time to seek out consumers, we should be in a better position to avoid that scenario. On top of that, how many projects get completed in two months? If there were any, I wasn't involved in any of them."

Raj replied, "Yes, that's a good point. So, it sounds like three might be our magic number. Consumers wouldn't immediately have to jump to the new release, but they'd have at least one additional release cycle to acquire funding and staff to make the necessary changes."

Ron added, "I think we can live with this, but the one thing I want to be sure of is that changes aren't done in a vacuum. Just because there's a policy of three versions doesn't mean that all changes should be discussed with all existing consumers and new prospective consumers prior to committing to a release."

Spencer said, "Good point, Ron. If we don't communicate with each other, we're leaving ourselves open to problems and dealing with ‘he said/she said' scenarios."

With this caveat, everyone agreed that three supported versions was a good starting point. They all also agreed that the inconsistency in release schedules of applications could become a problem in the future. All of the members of the Center of Excellence knew of at least one application that was still in use in production, yet hadn't been modified in at least five years.

Spencer made sure he discussed this with Elena when he followed up with her the policy of three supported versions in production at one time. Elena and Spencer both agreed that having applications in use for over five years without anyone touching them was actually risky for the company, since all knowledge of the system could be lost to technology changes, personnel turnover, or other reasons. By keeping the policy at three supported versions of each service, it would encourage Advasco to review and, if necessary, refresh the systems on a more frequent basis, mitigating any risk associated with these long tenured applications.

Next Page: SOA Development - Service Versioning Policies - Page 3