We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

What Percentage of Service Reuse Can a Company Realistically Expect From SOA?

Vote 0 Votes
While I've seen arguments from 100 percent service reuse to much less, what percentage of reuse can a company realistically expect from SOA?

13 Replies

| Add a Reply
  • Ultimately it depends on the service. At the lowest level, if data access services are designed well, these should be usable again and again to access or update data items based on the service. Lower level application services that do something at a low level should also be reusable again. FOr example, if there is a service available that calculates interest for example, does one really want multiple versions of this around that do things 'more or less' the same way ? I would suggest that you want services like this to be reused 100%. As the composite services that are made available based on lower level services are rolled out, they will become more specific, however, one would assume again that if a business has a requirement to 'Get data for "x"', that all processes that require the data for "x" would use the same mechanism as it will guarantee consistency throughout the business.

  • percentages of reuse are strange, people measure in many ways.

    for example, one useage scenario for a service is "use" not reuse. but is two scenarios using one service 100% reuse? How about a portfolio of 100 services where 50 services are only used by one useage scenario. Is that 50% reuse?

    What about a scenario where there are 100 services that are all very underutilized. In this scenario, service enablement and the offering of the services in a registry results in the discovery that one of the services could be deployed to end users resulting in a 10,000% increase in the usage of that service. But no other services are "reused". Is that 1% reuse?

    If all the services in a scenario are used by an average of 3 use cases is that 200% reuse? or 300% reuse. It should be 200% because the first use is just use and not reuse.

    Now add orchestration.

    If there are 10 services initially used only by one consumer and 5 of them are orchestrated into a flow, does that orchestration suggest 50% reuse?

    I guess what I'm trying to say is that percent reuse is extremely deceptive in terms of the impact of an SOA program. I realize there needs to be some way of communicating the benefit in cost to the CFO, and that selling a percentage of reuse is one way to do so.

    Here is a system call graph of Apache on Linux trying to send a single web page with one image. What percent reuse do you see in this image?

    http://www.codemonkeyramblings.com/files/SysCallApache.jpg

    • Re-use should be measured against the potential for re-use. Defining or assessing the potential for reuse is a tough job though.
      For example if a service could be re-used in 4 scenario but is re-used in three and implemented again(duplicated) in the fourth system then we can say the reuse is 75% as only 3 out of the 4 potential reuse opportnities are used. If we list the % for all reuable services and average it that would be a measure of re-usability.
      Another wrong statement is if a service is not reused it is NOT designed well. By nature certain business functionality are reusable and some are unique. we cannot say unique services are NOT Reused services hence designed poorly.

  • I think you'll find that the percentage of reuse is strongly correlated to the ability of managers in the organization (and that includes non-IT managers) to come up with some governance model that clearly breaks things down into shareable and non-shareable domains, including approaches to funding and support. If the ability to do this is low, then your percent of reuse will likely be low, limited to whatever IT can accomplish under the radar. If the ability to do this is high, then your percent of reuse is high. More importantly, if your ability to do this is high, you'll be more likely to focus on the right areas for reuse, rather than dealing with arbitrary edicts of "make this thing reusable" even when it might not be appropriate.

  • user-pic

    The percentage of reuse of business services is the function of business reuse in the organisation - how many business activities/actions/procedures are reused?

    I do not expect this number would be high; something at the level of a few dozens.

    Reuse of the service is NOT = to use of the same service in multiple projects because this is just a multiple use. Service value is not in reuse but in capability to be easily composed/recomposed by itself or particiapte in compositions of others, i.e. in the service business flexibility.

  • This is deja vu all over again. I remember this same discussion about libraries, procedures, objects, and components. Now it's about services.

    In my opinion, service reuse is the wrong metric to be tracking with SOA. In addition to be being very subjective, it's a very tactical metric akin to saying that an "enterprise is secure because our firewall has no known vulnerabilities." While an amusing statistic, service reuse is not why an SOA should be implemented, nor is it the proper way to justify it. Then what makes the business case for SOA? That would be a tangible, demonstrable alignment to organizational and business objectives.

  • As Miko points out, there are many ways to define percentage of reuse.

    Assuming we're talking about the percentage of services that get accessed by more than one business unit/department, I've heard that the 30% range is to be expected as part of a healthy, high-functioning SOA. In this context, I don't think 100% reuse is anywhere near realistic -- there are many services designed for one function of one department, and that's that.

  • I agree with Michael Poulin. Focus should be on composition/recomposition rather than reuse.

    The major difference between the two is that reuse across different projects does not emphasize change in business conditions (i.e. it can happen with no business change at all), while recomposition relates more to business agility in the face of changing business conditions.

    Ultimately, it is business agility that gives SOA its major value. Making sure that a SOA service interface/contract remains the same under changing business conditions is the toughest type of expectation, because it involves defining services that will be robust under unforeseen business conditions (and as such can be recomposed appropriately whenever business change requires it, without changing the contract and without getting IT involved in recoding the service).

  • Agreee with everyone's comments especially Tarak. My opinion is that reusability is more of sales tactic than a true benefit of SOA. In order to benefit from reusability, SOA governance must be in place as well as a versioning strategy. Even if versioning is implemented, would a new version be captured as reuse or as a separate service?

  • We should not confuse Service Reuse with SOA Value Proposition or with SOA benefits. May be Peter's next question will be: What is the value of Service Reuse? but the current question is about the percentage of Service Reuse and not about Reuse Value.
    I agree that there are many ways to define Reuse.
    Like Joe I already seen the 30% as a high estimate for successful SOA implementation. This percent is very far from the 90% or 100% people talked about few years ago.
    Few additional comments:
    1. "Reuse by more than one business unit or department could be reuse by two business departments or by 30 or 50 departments and by one Business Line or by all Business Lines.
    2. The 80-20 rule is applicable. 20% of the Services could be reused by 80% of the applications. The other 80% will seldom Reused.

  • Well, this question struck a chord and anything I would say regarding the definition of re-use, the importance of governance, and how one measures "re-use" would be redundant. Instead, based on the common theme that seems to be flowing from the responses, I'd like to propose a follow-on question -- what are the most meaningful metrics to use to assess the success of a SOA effort, from the perspective of the IT teams? from the perspective of the business? This is probably the number one question I'm asked when I'm briefing people on SOA... thougths?

  • Service reuse in an SOA environment is context driven with granularity being a key consideration. Thus it would be futile to quantify it in the general sense - rather effective utilization should be measured given a context.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT