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.