While everyone is bound and determined to build an SOA within their enterprise--perhaps even between enterprises--few have attempted to determine their Return on Investment (ROI) to justify this approach and technology. True to form, we are again approaching new technology with fervor and excitement, but we also need to figure out the business case for this movement.
These days, IT architects and business people must work hand-in-hand to determine if changes proposed are the proper course for a business. Indeed, the application of an SOA has different degrees of ROI, depending on the problem domain. The cost of implementing an SOA should be directly related to the benefits to the business, in both hard and soft dollars. Let’s explore this notion.
The Value Proposition of an SOA
We implement SOA for two major reasons. First is the ability to save development dollars through reuse of services. These services may have been built inside or outside of the company, and the more services that are reusable from system to system, the more ROI from our SOA. Second is the ability to change the IT infrastructure faster to adapt to changing needs of the business. This, of course, provides a huge strategic advantage and thus allows for the business to have better chances of survival long-term. While determining the ROI on agility is difficult to figure out in hard dollars, we know the value is there.
Reuse of Services
Under the concept of service reuse, we have a few things we need to determine to better define the value. These include:
- The number of services that are reusable.
- Complexity of the services.
- The degree of reuse from system to system.
The number of reusable services is the actual number of new services created, or, existing services abstracted, that are potentially reusable from system to system. The complexity of the services is the number of functions or object points that make up the service. We use traditional functions or object points as a common means of expressing complexity in terms of the types of behaviors the service offers. Finally, the degree of reuse from system to system is the number of times you actually reuse the services. We look at this number as a percentage.
Just because we abstract existing systems as services, or create services from scratch, that does not mean that they have value until they are reused by another system. In order to determine their value we must first determine the Number of Services that are available for Reuse (NSR), the Degree of Reuse (DR) from system to system, as well as the Complexity (C)of each service, as described above. The formula to determine value looks much like this:
1
Print this article
Email this article
Talk Back!
Write to Editor
