Service-Oriented Architecture

Digg This!

Why do we do what we do? I mean, why do we design and implement SOAs? The truth is we do so to improve our business, thereby making it more adaptable and ready to accept change without major disruptions. However, what does this mean to the bottom line?

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.

Why We Service-Enable
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 we get 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 long-term survival. 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 heading 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 that 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:

Value = (NSR*DR) * C

Thus, if you have 100 services available for reuse (NSR=100), and the degree of reuse is at 50 percent (DR=.50), and complexity of each service is, on average, at 300 function points, the value would look like this:

Value = (100*.5) * 300

or

Value = 15,000, in terms of reuse

If you apply the same formula across domains, with consistent measurements of NSR, DR, and C, the relative value should be the resulting metrics. In other words, the amount of reuse directly translates into dollars saved. Also, keep in mind that we have to subtract the cost of implementing the services, or of creating the SOA, since that's the investment we made to obtain the value.

Moreover, the amount of money saved depends on your development costs, which vary greatly from company to company. Typically, you should know what you're paying for, functions or object points, and thus it's just a matter of multiplication to determine the amount of money we are saving by implementing a particular SOA.

Agility
Agility is a strategic advantage that is difficult to measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time
• The ability to adapt to change
• Relative value of change

The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market. Thus, while a paper production company may only have a degree of change of 5 percent over a five-year period, a high technology company may have an 80 percent change over the same period.

The ability to adapt to change is a number that states the company's ability to react to the need for change over time. The notion is that the use of an SOA provides a better ability to change IT to adjust to needed changes in the business.

Finally, the relative value of change is the amount of money made as a direct result of changing the business; for instance, a retail organization's ability to establish a frequent buyer program to react to changing market expectations, and the resulting increases in revenue from making that change.

Determining an SOA's ROI is not an exact science, but with some analysis and some realistic data points, you can figure out how much value your SOA implementation has brought you, or will bring you. Again, we need to cost justify the use of this approach and technologies, and the information presented here should help you along the road to creating your own business case.