Service reuse if often mentioned as an important aspect of SOA. Many people cite it as a way to measure SOA success. For example, Eric Roch:
Certainly if you were measuring SOA success, and you should of course, then an obvious measure is service reuse. A friendly competition between development teams that achieve the most reuse would be a great way to publicize and encourage service creation and reuse.
Reuse is very much a part of SOA. It's part of the simplicity of SOA, and in linking services together to solve an end-to-end business problem or process.
As mentioned above, when looking to measure the success of SOA, the amount of service reuse is frequently used as a metric.
Service reuse is both a feature and a benefit of service-oriented architecture (SOA).
However, it's never quite that simple and since the early days others have been suggesting that service reuse either isn't important at all or certainly shouldn't be considered the main driving force behind SOA. As Dave Chappell put it back in 2006:
Creating services that can be reused requires predicting the future… how can a service’s creators accurately guess what future applications will need? The ‘If-you-build-it-they-will-come’ approach is tough to turn into real reuse.
Now Burton's Richard Watson has entered the debate, suggesting that "reusability is always overpromised" and that developers, users and decision makers should not become fixated on service reuse. As he puts it:
A service may never be reused, but still be used to create value in other ways: by being adaptable and less costly to maintain, reducing redundancy, increasing security and compliance through consistent enforcement of policies, to name just a few other desirable outcomes. Exclusive focus on reuse blinds us to these other outcomes.
He suggests that it may be possible to break this down into an equation to calculate reuse and savings over time. But of course you would also need to factor in deployment and application specific criteria. According to Richard, what we should be looking at is the value of the service, and reuse is only a small part of that. As he goes on to say:
[...] the value of the service can be refreshed occasionally, say when a changes to reporting regulations dictate a different set of rules and the changes required can be made in an isolated place instead of across the board. But that gets us back to the value of service "use" not "reuse".
Object reuse was often touted as a major benefit of object-orientation, but frequently the reality failed to live up to the theory. Eventually people stopped using this as a way of detracting from OO and focus on the other tangible benefits it brought (and continues to bring). Maybe service reuse is going in the same direction?
Community comments
Reuse is overrated
by Colin Jack,
Reuse isn't the end goal of SOA
by Vijay Narayanan,
Reuse means something different in SOA
by Jean-Jacques Dubray,
SOA is just another buzzword
by Chris Treber,
Reuse is overrated
by Colin Jack,
Your message is awaiting moderation. Thank you for participating in the discussion.
Udi Dahan has some interesting blog posts (old and new) on this that are worth reading:
www.udidahan.com/?blog=true
Reuse isn't the end goal of SOA
by Vijay Narayanan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Very interesting read - reuse isn't the end goal of SOA! Achieving business objectives - reducing costs, increasing agility, reducing time to market for new business processes/products/services is the goal. I recently blogged about this topic.
Also, service reuse and object reuse both face a lot of similar challenges. Designing/developing/versioning reusable assets is a challenge and so is getting your developer community to buy into them. Here is my list of why reuse efforts fail and why reuse is risky.
It is important to reuse services but not at the cost of other considerations such as cost of development/maintenance, design complexity, lack of transparency/visibility, and performance.
As tricky as it is to predict the future, it is still useful to understand variations in your problem domain and plan for them (as much as it makes sense). Your services are capabilities that can vary based on a variety of factors - the extent to which you can identify and realize those variations will impact service reuse as well.
Reuse means something different in SOA
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
what most people still don't understand is that "reuse" does not mean in SOA what people usually understands when they hear the word "reuse". Reuse in SOA is forward reuse or as I heard it this morning, upward reuse. In SOA, reuse means that the new version of a service built for a new consumer does not break the existing consumers. Thinking that one can design a service today that can be "reused" in two years is for the most part a fantasy. In SOA older consumer "reuse" the service versions built for the latest consumers.
This is what Kjell-Svere and I explained in this article: www.infoq.com/articles/contract-versioning-comp2
SOA is just another buzzword
by Chris Treber,
Your message is awaiting moderation. Thank you for participating in the discussion.
>Object reuse was often touted as a major benefit of object-orientation.
Because hiding details through encapsulation helps managing complexity immensely (it IS my favorite OO feature), and thus could/ should be furthering reuse.
But reuse usually does not happen on higher levels, whereas is very often happens in more generic areas (collection frameworks, GUI widgets, data base APIs).
Why? The rather obvious reason is that special problems need special solutions, and at some point the creation and configuration of quite specific reusable components is more complex than writing your own code based on a good framework.
It's just the same with services.
>Maybe service reuse is going in the same direction?
Yes - I work for a large company that insists doing everything "SOA" (one problem with that is that there was no global steerage, and there is no global steerage now).
Services that support a companies business are (usually) not like a service for ordering "a book" or "a cubic meter of sand" (that is, services that are so generic that you might be able to use a UDDI directory).
Instead you probably will discover that ordering an item for a customer depends on a lot of parameters that vary with the type of customer, the kind of product, and even the department (often enough each has there own specific data structures). So, the service "order a product" is either a single very complex service, or a number of pretty different specific services.
Now, maybe that service level is too course. But from my experience it doesn't necessarily get better on a finer level: to check the financial background of a customer, department A demands different input data, rules, and output information than department B.
Long story short: if a company would have well organized processes and matching IT architecture, it would be easy(er) to implement SOA. It probably is a prerequisite to SOA, or a part of the process of introducing SOA, to get up to that level of organization, overview, and insight. But then 90% percent of the work is done, and why would you call that SOA?
To me, SOA is a bit like that flea poison that 100% sure will kill the flea - once you pour it into the carefully opened mouth of the flea you caught.
Chris