When considering the way SOA is sold within the enterprise, the notion of service reuse typically leads the charge. It just seems logical; a service-oriented approach means that we divide up applications into services, and then create a layer on top of those services to mix and match the services, turning them into business solutions. So, considering that, the core value of a SOA has got to be the ability to reuse those services, correct? Not a chance.

Indeed as we spend more time sizing up the value of a SOA, many find that the promise of reuse is coming up short when compared to other value propositions, such as agility. This is not to say that you won't find reuse valuable in the world of SOA, just not as much as you perhaps thought you would.

So, how does one figure out the value of reuse, or ROI, when considering SOA? There are some key metrics you need to define, including: The number of services that will be truly reusable, the degree of reuse, and the value of each service.

The number of services that are truly reusable is a true accounting of the inventory of services within a particular enterprise, and a true understanding about the number of services that will actually be reused from application to application, from domain to domain, and from enterprise to enterprise. Thus, this exercise is all about asking if a service is reusable, and not asking how much, or how valuable.

Truth-be-told, within many enterprises the number of services that are actually reusable from consumer to consumer are few and far between when getting right down to the essence of the services. One of the exercises I go through with my clients is to take a quick inventory of services, or service patterns, and then go one by one through each service, asking them about the need for this service as related to other applications, composites, or orchestrations. By the end of that analysis it's usually clear that there are indeed some services that are "reusable" but clearly not as many as they expected.

The degree of reuse refers to the percentage of reuse from the services previously identified. Thus, if we have 100 services that are reusable or available for reuse, what percentage of reuse will those services see? Again, it's a matter of considering the inventory and going through each service to determine the degree or percentage of reuse.

This is an eye opening experience for most, and it's during this process that services are analyzed for their own value and a percentage assigned to them as to the number of times that services will see reuse, now and into the future. A few things are typically apparent during this step. First, many of the services under analysis are tossed out because their degree of reuse is too low. In most cases it's 50 percent. Second, the percentages of reuse found are relatively lower than first thought. Finally, the services that do see a higher percentage of reuse are typically simple services, and may not have a ton of value.

Once you've figured out the number of services that are available for reuse, and the degree of reuse, it's time to assign a value to those reusable services. Thus, as you might expect, you list those services and assign value points (typically 1-10), and then assign dollar figures to those points (typically $10,000 per year). From there you can get a rough idea as to the value of reuse that your SOA will bring you.

While most were hoping for numbers well beyond 7 figures, the actual value of reuse is usually much less than expected. So, why is this? There are a few factors at play:

• First, most of the services that are exposed for use within a SOA are existing, and therefore were not designed for reuse. Simply re-exposing them as Web services does not change the underlying design patterns, and their ability to become a reusable asset does not increase by much. I suspect that as more services are designed and built from scratch, the reuse value will go up significantly.
• Second, the services are typically too course grained to be valuable for reuse. Once again, this is a matter considering foreseeable use. Those who built these services did not do so with reuse in mind, nor did the developers that service-enabled the system.
• Finally, the core business systems do very different things, and thus don't need to share services.

Don't get me wrong, this does not mean that reuse is not a core value of SOA, but its value is much less than we expected, or the "SOA hype" has been stating. The true value of SOA is the ability to create enterprise architectures that provide much better agility than the overly complex, static, and fragile architectures we have around today.

Posted by Dave Linthicum on October 6, 2007 04:31 AM