SOA reusability debate is bit confused. For more clarity, we must understand the difference between service interface and capability behind it. A service exposes some interface which is backed by a capability. From a service consumer's perspective the reusability of interface is enough. Whereas from a builder's perspective the reusability of capability is more important. It is the later which is difficult (or impossible in some cases). It is possible that same interface can be mapped to multiple capabilities. For example an interface can be mapped to multiple capabilities based on Quality of Service (QoS) needs specified in interface. (Well, this is not possible right now in most implementations). The QoS needs like performance, scalability, availability, currency, data quality etc. would determine the binding of interface to capability. Sometimes even functional needs of services may force an interface to be bound to multiple capabilities developed over period of time. The problem is how does one control the proliferation of overlapping capabilities.
The reason why overlapping capabilities get developed are not straight forward. Sometimes it is weak governance, sometimes it is for QoS purposes, sometimes it is trade-off made to achieve results for a business facing project. This post by Todd Biske has elaborated about the last aspect. In practice one can address governance issues but capability duplication cannot be totally eliminated. The QoS needs will force multiple capabilities for same interface in some cases. There may be business drivers which will force a tactical trade-off to achieve larger business benefits. Well, one way to avoid trade-offs is to plan for the future, which I have suggested in this post. Still such overlapping capabilities will get built.
So what should one do? Well, one way out is to refactor and streamline the capabilities that are built. Here SOA would help, as consumers are not affected when capabilities change, as long as interface is same. So one should be refactoring and cleaning capabilities, because up-front reusable capabilties are hard to achieve in a working IT organisations. Business leaders must realize this reality and make funding available for these kinds of activities.
Subscribe to:
Post Comments (Atom)
Thursday, January 11, 2007
SOA: Reuse, of Interface or Capability?
SOA reusability debate is bit confused. For more clarity, we must understand the difference between service interface and capability behind it. A service exposes some interface which is backed by a capability. From a service consumer's perspective the reusability of interface is enough. Whereas from a builder's perspective the reusability of capability is more important. It is the later which is difficult (or impossible in some cases). It is possible that same interface can be mapped to multiple capabilities. For example an interface can be mapped to multiple capabilities based on Quality of Service (QoS) needs specified in interface. (Well, this is not possible right now in most implementations). The QoS needs like performance, scalability, availability, currency, data quality etc. would determine the binding of interface to capability. Sometimes even functional needs of services may force an interface to be bound to multiple capabilities developed over period of time. The problem is how does one control the proliferation of overlapping capabilities.
The reason why overlapping capabilities get developed are not straight forward. Sometimes it is weak governance, sometimes it is for QoS purposes, sometimes it is trade-off made to achieve results for a business facing project. This post by Todd Biske has elaborated about the last aspect. In practice one can address governance issues but capability duplication cannot be totally eliminated. The QoS needs will force multiple capabilities for same interface in some cases. There may be business drivers which will force a tactical trade-off to achieve larger business benefits. Well, one way to avoid trade-offs is to plan for the future, which I have suggested in this post. Still such overlapping capabilities will get built.
So what should one do? Well, one way out is to refactor and streamline the capabilities that are built. Here SOA would help, as consumers are not affected when capabilities change, as long as interface is same. So one should be refactoring and cleaning capabilities, because up-front reusable capabilties are hard to achieve in a working IT organisations. Business leaders must realize this reality and make funding available for these kinds of activities.
The reason why overlapping capabilities get developed are not straight forward. Sometimes it is weak governance, sometimes it is for QoS purposes, sometimes it is trade-off made to achieve results for a business facing project. This post by Todd Biske has elaborated about the last aspect. In practice one can address governance issues but capability duplication cannot be totally eliminated. The QoS needs will force multiple capabilities for same interface in some cases. There may be business drivers which will force a tactical trade-off to achieve larger business benefits. Well, one way to avoid trade-offs is to plan for the future, which I have suggested in this post. Still such overlapping capabilities will get built.
So what should one do? Well, one way out is to refactor and streamline the capabilities that are built. Here SOA would help, as consumers are not affected when capabilities change, as long as interface is same. So one should be refactoring and cleaning capabilities, because up-front reusable capabilties are hard to achieve in a working IT organisations. Business leaders must realize this reality and make funding available for these kinds of activities.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment