MomentumSI: Reuse in SOA

Reuse in SOA

January - 2006

I.T. leaders will often reference 'reuse' as a goal, if not the primary goal of their SOA program. Most people will agree that reuse is a noble goal - however, most people who have been in I.T. for any period of time also realize that it is difficult to achieve reuse. At Momentum, we believe that software will continue to be modularized and various sizes of modules will exist. Some modules will be more complex than others; some will be simple classes, some will be components and others will be services. Organizations will find reuse opportunities at all levels.

As companies begin to assess their SOA program goals they are likely consider the following reuse metrics:

Count the number of services
Count the number of clients
Find the average number of consumers (# of Clients divided by # of Services)

And this is good math. However, they are likely to be disappointed when they count the average number of consumers. Why? It's simple: because SOA does achieve a certain amount of reuse, but some of the other benefits of SOA are perhaps more important than reuse (consistent shared logic, one source of data, metadata based composition, interoperable distributed computing, etc.) Let's take a look.

First, let's define some terminology:

Business Services - Services which implement an activity or step in a business process
Technical Services - Services which front-end technical functions (workflow, identity, etc.)
Structured Data Services - Services which front-end operational data stores, MDM, data warehouses, etc. (pure data)
User Produced Services - Data centric services produced by end users (RSS feeds, Hailstorm like schemas, etc.)

Let's face it; all service are not created (or consumed) equally. By their very nature some services will have broad consumption while others will have narrow consumption. We have to acknowledge this simple fact and make sure that we don't let this data accidentally skew our goal assessment.

We can easily draw analogies to the physical world. Simple components like a transistor or resistor will likely find lots of reuses. Slightly more complex items like a printed circuit board may find less reuse. While a fully integrated / programmed mother board will probably only find use in only one product family. And as we look at our services we will find a similar pattern - the more elaborate the solution, the less applicable it becomes for broad consumption. One might accidentally walk away from this conversation thinking, "well, let's not do business services because they're clearly less reusable!" And that logic would be partially correct - but... mostly wrong. Let's take a look at the reason.

As we peek inside of our various services, we come to a simple observation: Some services cost more money to build and maintain than others. In fact, we will most likely see that our 'business services' were the most costly to build while our simple RSS feeds were the cheapest. Remember, our business services may have to deal with complex logic as well as transactional, security and reliability concerns that some of the lighter weight services didn't need to address. In essence, we identify that by reusing these services once or twice, we avoided significant labor costs associated with duplicate coding efforts.

And although these savings may be significant, this still might not be the primary value of reuse - the real value may just come from 'sharing'. With sharing - we see a slightly different value proposition. We see the value of 'one instance' - meaning... we always run the same set of logic against the same set of data. We avoid 'multiple instances of the truth' while also being able to make a change in one place and having the 'truth' propagate to all consumers.

Bottom Line
Be careful in how you measure your SOA success especially around reuse. If you're measuring only 'average number of consumptions', you'll probably be disappointed. However, if you measure on 'cost avoidance' or factors related to time-to-market, agility, etc. you'll likely find significant value.

Authors
MomentumSI SOA Practice