In speaking at the Gartner Show this week on SOA ROI, as well as attending some of the other sessions on the same topic, a few things became clear to me: First, reuse is a "wash" in the world of SOA. While a valuable as a byproduct of SOA, there is typically no cost justification for building a SOA for reuse alone. Under the concept of service reuse, we have a few things we need to determine to better define the In speaking at the Gartner Show this week on SOA ROI, as well as attending some of the other sessions on the same topic, a few things became clear to me: First, reuse is a “wash” in the world of SOA. While a valuable as a byproduct of SOA, there is typically no cost justification for building a SOA for reuse alone. 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. 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. One of the things that are true with this notion is that the weight that you place on each of these key metrics is dynamic and domain dependent, not static. Thus, you need to carefully consider the problem domain, and variables around the problem domain. For instance, while complexity is typically a representation of value, in many instances it’s not. Thus, your analysis needs to be dynamic. Moreover, the notion of agility should be consider using the same dynamic analysis. If you’ve been reading my stuff you’ll understand that I put forth 3 key metrics to determine the value of agility as a value of SOA: 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. The ability to adapt to change is a number that states the company’s ability to react to the need for change over time. Finally, the relative value of change is the amount of money made as a direct result of changing the business. While a good start, you can go well beyond these metrics to determine the value of SOA within a particular enterprise. For instance, the presence of regulation in a particular industry that limits, or drives change. Thus while there is a desire for change, and an ability to change, and a huge value to change, they can’t change quickly. All of this needs to be factored in. I’m working business cases for SOA a lot these days, including speaking at conferences such as Gartner’s this week. As I discover better ways to analyze SOA ROI, I’ll make sure to share them here. For now, SOA ROI is clearly something that needs dynamic analysis from somebody that’s able to adjust the approach for a particular enterprise. While one size should fit all…that’s almost never the case in the world of SOA. Software Development