Reusing reuse…
Wow, someone stirred the pot today. Miko Matsumura lashed out on the topic of reuse within SOA, along with David Chappell (the .NET David, not the Sonic David), as quoted in Joe McKendrick’s ZDNet SOA blog. This started with another post by Joe, quoting Charles Stack of Flashline BEA. Stephen Anthony commented on his blog with more questions than answers.
One of the biggest mistakes I think could be made would be to sell SOA purely as a way to achieve the IT Holy Grail of reuse. In other words, reusing reuse to sell the latest technology trend in the same way we used it to sell previous technology trends. Should services be used by more than one consumer? Absolutely. Will all of them? Certainly not. In many cases, the service boundary may be the point that separates things that may change from things that don’t (e.g. interface and implementation). In such a scenario, we are likely providing a more agile solution. Rather than having to rip apart the entire solution, only the services impacted by the business change need to be touched. The change may not be within the service, but rather on the consumer side. I may adjust my process definition and invoke the service at a different time. Do these solutions mandate reuse? Certainly not. Agility in supporting the business and its changes are the primary concern. Eliminating redundancy and leveraging exists assets will always be a goal of IT. While that may cut costs, it’s not going to help revenue. Only my meeting the changing needs of the business through agile solutions can that revenue stream be impacted for the better. If you’re cutting your costs at the same time, even better.
One added note. Mark Griffin made a great point in his blog that if you are striving for reuse, you’d better be prepared for handling change management. Sooner or later, that service will be modified and its interface will change. Whether you have one consumer or many, you’ll need to effectively manage that change.
4 Responses to “Reusing reuse…”
Leave a Reply
Your point and Mark Griffins is spot on–if you want reuse, you must deal with Change Time.
This is one of the main reasons why I dont buy Paul Patrick’s argument here
http://blogs.zdnet.com/service-oriented/?p=695
He says:
“The reality is the repository doesn’t hold the actual definition of the service,” Patrick explained. “Rather, it holds multiple definitions of the service at different points in its lifespan. But only one of those versions at one point in time is published to be used in the production environment.” Such is the job of the registry.
The concept that there’s only one version of the service at production isn’t at all what we are seeing in real life (at Infravio). We see multiple deployed versions in our customers, and people using mediation as a way of dealing with changes and version to get service consumers routed appropriately.
These changes are handled primarily through composition, process, contracts and policies, which is what makes them agile, as opposed to changes handled by going back to custom software development.
I absolutely agree. The exact number of versions that an organization should support in production can vary depending on the release cycles of the services. I think that if a group takes on a 6 month release cycle, 3 version in production makes sense. If a group takes on a 12 month release cycle, then you’d probably only want to support 2 in production. You can see that my logic points to not maintaining a version that’s more than 2 years old.
What makes this challenging is actually having a regular release cycle for internally developed efforts, both services and their consumers. This way, services change at predicatable times, and the changes to consumers can be scheduled along those predicable times. Odds are that the organization will need dedicated release managers for the coordination invovled, but it’s a level of maturity that I believe will be necessary.
I absolutely agree with Miko. If the writers of articles on SOA really spent time with the real world implementors you would see a different perspective. There are political and social problems to overcome to have one version at a given time. I have seen services have different functionality depending on the way it was called.
Who is the consumer? The consumer predicts the version of the service that needs to be in production. So if you have slow adopters of a service version well guess what. hmmm…. hmmm….. there is more than one version in production 🙂
The new version has to be published before people move to it for “sales” reasons. Show that the next version will be stable in a production environment and than the slow adopters move to it eventually.
[…] Reusing reuse…: This was originally posted on August 30, 2006, and discusses how SOA should not be sold purely as a means to achieve reuse. […]