In one his latest posts, David Linthicum asks a very good question that everyone will need to think about: When building a SOA, how do you know when you're done?
As with all things, the return is greatest when you start out, reaches some type of crescendo, then falls into a diminishing point of return. As David puts it: "you can service enable and orchestrate the entire enterprise, perhaps your supply chains as well, but I doubt the cost of doing that is going to justify the benefits on most cases. However, clearly you can do to little, and thus not get the benefits you need. You need to find a balance."
There's some kind of economics curve at work here, like price elasticity, in which raising prices too high will reduce demand, and therefore revenues; and likewise, charging too low will sell a lot of product, but at a loss.
As David put it, "We are assuming that there comes a time in the implementation of a SOA when the effort has a diminishing return or the point when the amount of effort won't produce enough value to
justify continued work at the same level of effort. So, how do you figure that out?"
David has come up with a formula that measures the relative value of SOA by a computation of two key paybacks: agility and reuse. The formula is : Relative Value = (Effort over Time x (Value of agility + Value of Reuse)).
He provides the example of EOT for SOA is a constant 25 percent of resources, and that Value of Agility diminishes by 10 percent yearly and Value of Reuse diminishes by five percent yearly. Based on this assumption, David calculates that the value of SOA will diminishes in its fifth or sixth year (the calculations are on his blogsite.)
Let me throw this thought into the mix: SOA may be more about economies of scale. Perhaps the ROI comes later in the evolution, and the most expenses incurred and risks taken in the earliest years of an SOA effort, since that's when the first components for a particular service area are designed, developed, debugged, tested, and put in the registry/repository. No special benefits are realized since only one business unit is using the new services, and initial costs may not be all that much different than the work required for a legacy application or integration project.
The equation changes when a second business comes along that can also use some of those service components. But perhaps at least three-quarters of the required services still do not exist and need to be built from scratch. The next business unit may then find an even larger list of services it can draw from, perhaps half of what's needed, and so on. Eventually, an enterprise may reach a point where relatively little original work is required for new applications. That would mean ROI is realized through an increasing economy of scale, achieved through ever-growing reuse.