SOA reuse of services
valuation method


The problem

I provide consulting services with Oracle products since 1991 and I still see the same problem over the years: duplication of functionality and data. The duplication obliged organizations to build and maintain synchronization process (interface) between different applications of the organization.

For example, the Marketing department of an organization stores information related to selling products in a Content Management System (CMS). This information is then display on the website of the company. The web platform of the company is well integrated with the CMS. Customers can use this information to help them in their purchases. But information of products is also used by the Finance department. This information is also stored in the ERP system database. Therefore, we have the same product information in the CMS and also in the ERP system database. If the information of products is changed in the CMS and not in the ERP then inconsistencies can occur. This organization needs a synchronization process between the CMS and the ERP system database.

The purpose of this article

The intend of this article is to explain a valuation method of reuse of the services involved in a SOA project when the services are designed.

This approach can be used by IT manager to help to build the business case for a SOA project to avoid duplication of functionality and data and also to help to promote SOA projects. Reuse can also be applied not only to services but also to other assets used by a SOA project like business process model, XML and WSDL files.

The purpose of reuse

The main purpose of reuse an existing functionality is to code the functionality once and avoid the cost of maintaining different implementation of the same functionality. But first, we must recognize that building a functionality that can be used for a single project will take less time than building the same functionality that can be used by many projects and applications. Also, it is not all services that can be reuse.

Service design and reusability

Some people think that the more generic a service can be the more reusability a service can have. But a service can be very difficult to use if it is too generic. A developer will need too much knowledge of the implementation of the service to be able to use it correctly. I think that parameters and exception handling of a service should be clear and specific. For example, a service like EmployeeAssignmentService to manage the assignments of employees and an operation UpdateEmployeeAssignment with a parameter EmployeeData. If a consumer of the service wants to update the assignment of an employee, the parameter to provide is unclear. What is the EmployeeData and which assignment information do we want to update? We should provide an operation like UpdateAssignmentSupervisor with parameters like employeeId and date. This has a better chance of reuse.

Reuse program

Many organizational reuse programs consist of simply recovering old code for later use (sometimes referred to as “unplanned reuse”). However, the greatest benefits from reuse result from engaging in a formal, planned reuse program and should occurs early in the development lifecycle of a SOA project (2).

The percentage of reuse

With the SOA approach, the percentage of reuse is higher than using a traditional component-based approach because SOA is based on reusing services as much as possible. Reusing existing functionality (services) makes sure that it can be changed quickly because you don't have to start from scratch every time.

The level of reuse in a typical SOA application increased to 25% from an average of only 10% in a traditional component-based application, which drives significant cost savings on future SOA projects (1).

But IT manager must put in place good measures to evaluate the benefits and costs of reuse that is an asset valuation process that focus on development savings. It is good practice to nominate a group in an organization that is responsible and promote the reuse program. It can be one of the task of the Enterprise Architecture Review Board. This group knows the critical applications, the common data entities and business process. This can be a good start for identifying potential reuse opportunities. This group will need tools to help search and find reusable components therefore it need a reusable asset repository. But we must understand that these things cost money for the organization.

Reuse metrics

Estimated time required to build a service for single use

This metric represents the time spend (analysis, programming and deployment) to deliver a service for a given project.

Estimated time to build a service for reuse

This metric represents the time spend to deliver a service for reuse. It is usually twice the time required to build the service for single use. (200%)

For example, if we just considered the testing phase, probable message exchange patterns available within the enterprise should be tested.

Consumption factor

The time that a developer will spend reusing a service. This time can be evaluated as 5% of the time estimated to build a service for single use. But this number can be adjusted according to experience.

Predicted Net Hours Saved (3)

This metric represents the development cost avoided through reuse of the service or asset instead of recreating the asset in different applications. Therefore, it is : Predicted net hours saved = Estimated time required to build an asset or function for single use - estimated time to use an existing asset

Prioritization of investments of reusable services

We can use the following steps to help to prioritize investments in reusable services:/p>

  • 1 - 1- Estimate the level of annual usage
  • 2 - 2- Calculate the predicted net hours saved in dollars with a burden rate The burden rate is the overhead cost per hour for a given resource used by a project. This rate can be provided by the Finance department.
  • 3 - 3- Calculate the potential reuse value in dollars

The potential reuse value in dollars :

Predicted net hours saved x number of annual reuse of the service x burden rate per hour

For example, we estimate the total hours of development of a reusable version of the addressVerification service as 246 hours.

The time to develop a non reusable version is 50% of the total hours for a reusable version: 436 hours x 50% = 123 hours for a non reusable version of the addressVerification service.

The consumption factor is 5%: 123 hours x 5% = 6.15 hours

Predicted net hour saved: 123 hours – 6.15 hours = 116.85 hours

The number of annual reuse of the service is estimated as 10. We have 10 different potential applications that can be a consumer of that service.

The total burden rate per hour is $100

Potential reuse value in dollars: 116.85hours x 10 x $100 = $116,850.

The following worksheet is an example of what can be used to calculate the potential reuse value for year:


Organization must set goals to reach in the SOA roadmap but must also established key metrics to monitor progress. It is very important to show the business value of SOA benefits.


(1) The ROI of SOA Based on Traditional Component Reuse, Jeffrey Poulin, Ph.D. and Alan Himler, MBA
(2) Determining the Value of a Corporate Reuse Program, Jeffrey S. Poulin Joseph M. Caruso
(3) Oracle Practitioner Guide, Determining ROI of SOA through Reuse, Stephen G. Bennett

Oracle® & Oracle® E-Business Suite
are registered trademarks of Oracle Corporation