by David A. Chappell
I have been intently following a blog thread that was initially started by the "Other" David Chappell. David's initial posting
SOA and the Reality of Reuse
sparked a small flurry of responses, and responses to responses
, which also include Joel McKendrick's Pouring Cold Water on the Service Reuse
. I tend to agree with most of the points made in David's initial posting which includes -
- Reusable services can sometimes be hard to do
- Effective SOA reuse requires strong corporate wide organizational support with top management support and buy-in.
- SOA creates agility by allowing for flexible business processes, which if are configuration driven may be readily changed to suit the changing needs of the business. David argues that this can be a form of reuse.
However the overall tone of the threads seem to be casting a very strong doubt on the reality and practicality of service reuse at all. Some of the responses are flat out saying that service reuse is not possible.
So I went and compiled some information gathered from our customers who are building SOAs.
It mystifies me that so many would assert that SOA does not promote reuse if the service provides value for value. That the technical approach works is obvious. That the business model works isn't as clear. No free lunch.
The challenge is getting the value in return. A commoditized service tends toward an economic lagrange point: given a competitive service with equal value, the switching costs tend toward zero. Then the little differences make a big difference. Sustainability (a crucial part of the QoS evaluation) can be one of those differences.
Sort of a "d'oh" but a simple point worth remembering. Whether internal facing or external facing, service providers have to compete for value and it will be fascinating to see how that competition shapes up. SOA doesn't produce a frictionless system; one still loses energy having to keep the customers. It produces a low-energy transport system (as opposed to a Hohman transfer).
The economy stratifies by service types as you point out. For the content services, I suspect that protecting the sources for resources is one means and that does't augur well for the services that rely on user-generated content unless the 'greater fool' means keeps producing talented amateurs to replace the sources that are contractually obligated.
One has to question whether an organization has truly created an SOA if at least some of the services deployed into that SOA are not reusable/reused. If all we are doing is creating another technical layer and not providing more business flexibility in the bargain, we are doing a disservice to the organizations we work for, which after all do pay us to deliver business value.
One way to make that work is to combine service development with notification systems. The range from static service subscription to dynamic service composition is the unexplored country.
For businesses (as a type of service network) that require high QoS numbers and longcycle ticks for predicting results, the range is toward the low static side. For games or simulations (a just in time service network), the range can be quite dynamic.
What is missing is this range of just-in-time discovery and subscription.
All these young turks fretting over reuse. (sigh)
If you have worked in computer science as long as I have (35 years) you will have seen that "reuse" has been a holy grail in every era and always comes up short. Subroutines, functions, libraries, modules, classes, components, distributed versions of all of the previous, and now "services".
The problems are always the same:
* knowing how to make something reusable (which only happens with feedback from multiple attempts to reuse each particular component)
* knowing where to find components which are reusable, and knowing
what those components do (which means doing the detailed clear type
of documentation that never seems to get done)
* and most importantly, it is simply more easy (dare I say fun) to
develop from scratch than to find, learn, debug, refactor, existing
"reusable" components written/controlled by someone else.
* OH, and dont let me forget! People have the whole notion of "components" (aka services) backwards...FRAMEWORKS are what must be reusable and reused. Components dont exist! In the same way that donut holes dont exist. Frameworks are the donuts which define the holes/components. As long as people think about components in isolation, all of the above problems are made worse.