Reuse is often cited as a major SOA benefit and justification. It is easy to explain and to understand Reuse Value Proposition in IT and Business perspectives.
Services and Processes Reuse reduces Maintenance & Development costs, enable shorter Time to Market and is a key for building applications through assembly of existing Services by non-IT employees as mentioned in my first Web 2.0 for Dummies post .
Understanding, Reuse Value Proposition is not enough for realizing the benefits.
A SOA initiative without Reuse or with a low Reuse Ratio is doomed to failure.
According to many analysts' reports, NIH is a consideration of some software products they analyze. NIH, stands for Not Invented Here. As most of the analyst firms' headquarters are in the largest market i.e. USA Japan or many years ago Dynasty one of the best Client/Server IDEs developed in France
Some enterprises, I know extended the NIH concept significantly: the H (Here) stands for another department in the same enterprise or even another team in the same department.
I am sure that implementing SOA Reuse in an enterprise of that kind is almost impossible mission.
Creating a Reuse Culture is the key challenge for almost any enterprise implementing SOA. For enterprises having the extended NIH culture it could be the main reason for failing SOA initiative. They should change their Maturity Level prior to initiating their SOA initiative.
On the other hand Service Reuse is probably not as difficult for enterprises which already experienced other Reuse types such as: Objects Reuse in Object Oriented or Components Reuse in Component Based Development.
Key Reuse Success Factors
- Reuse Culture
This challenge was partially discussed in the beginning of this post.
Employees in an enterprise adopting Reuse Culture will constantly prefer usage of existing assets
(Services) over building new assets.
The assets included in the Services inventory could be assets invented here as well as NIH assets i.e.
Business Partners Services and SaaS services.
It should be noticed that Reuse requires different budgeting and accounting patterns. Departments using Services developed and/or maintained by another department should participate in these activities costs.
The rewarding schemes should also be changed: rewarding some of the less productive IT employees (in terms of writing programs) instead of the most productive (e.g. developing a large amount of programs or systems).
These "less productive" are actually more productive they Reuse instead of building new programs.
Services functionality should be published and managed in order that any potential user could think of
reusing them. Technically, the meaning is usage of easy to use Service Repository.
It also implies a new role: An expert of Service inventory. Systems Analysts should consult him for
matching Services to their systems.
Management in this context also implies Change Management.
For example, unifying of functionality of a bank branch and bank customers via internet by building a
common service, may require a decision about change frequency. The more dynamic internet channel
may require frequent changes, while the conservative and robust branch change rate is slower.
Facilitating Service Reuse is dependent upon services granularity and boundaries. Business defined
boundaries are a key for high reuse ratio.
Some SOA implementations are only Service usage by Multi-Channels. In that case Legacy Services
granularity could be too coarse.
Services should be defined with future usage by other applications in mind.
In many cases Service Reuse by other applications will require some modifications or extensions and a
new Service will be built instead of reuse in case of hard to extend or change services.
Talking to this enterprise SOA evangelist I tried to figure out the real advantages. "We did not measure it" was the answer to my question: What is the service Reuse Ratio in your SOA implementation?
Service usage should be measured systematically. The measures could identify Services which are rarely used, services that are used only by a single
-->application or single channel or single user (i.e. no Reuse or low Reuse rate).
Service usage should be measured systematically. The measures could identify Services which are rarely used, services that are used only by a single
