SOA's squishy paybacks revisited

A couple of years back, I posted some observations on the issues around SOA payback. Some analysts still say there has been little to no payback from these efforts.  Since SOA payback is still such a raw and confusing issue, here is an updated reprise of that post:

Short-term, measuring SOA payback is relatively straightforward. A company saves x amount of dollars by not having to reinvent a service for a new application. But the big payback happens gradually, over the years, through business gains and agility. Capturing this kind of data is, well, not so straightforward.

Perhaps SOA should incorporate a risk assessment aspect, that reviews a lot of ‘what-if’ scenarios.

This challenge is being pondered at a large company that both preaches and practices SOA — Hewlett-Packard. ZDNet colleague Dana Gardner chatted with Terri Bennett Schoenrock, executive director of SOA services and consulting integration and J2EE open source programs for Hewlett-Packard, as well as Andrew Pugsley, worldwide lead for SOA service development for HP.

HP projects it will achieve a $70 million cost savings from its global IT operations as a direct result of SOA  deployments, Schoenrock told Dana. And at least $1 million of the savings happened right out of the starting gate:

"The cost savings actually start on implementation. When we look at where we measured return on investments; return on investment actually happened on go-live with our own implementation of our e-business center. Return on investment starts Quarter 1. We doubled our revenues. We halved our transaction processing requirements. We really recognized improvements right away. We achieved $1 million in cost reduction from fraud the first year we went live."

Much of the remaining $69 million in savings will come out of a synergy implementing shared services, Schoenrock observed. "And those shared services are shared business services, and the shared services that we’re going to get in a virtualized and managed architecture running those business services."

HP says the initial paybacks from SOA come through consolidation, reduction of redundancy and reuse across services. Then the long-term payoff comes from increased business agility, and an ability to react quicker to the marketplace. However, while the first phase is easy to measure and see payback, the second– and more lucrative — phase is more of a challenge.

For example, Pugsley said, in consulting engagements, HP can help customers come up with firm numbers that will come out of integration and consolidation. "We have a fairly well-defined methodology for consolidating applications and services. We come in and often we can give quite a good indication of how much saving would come from that."

However, he continued, "on the agility side, it’s more tricky, because you are dealing a lot more with unexpected things." HP encourages customers to set percentage improvement in time-to-market as a possible benchmark for improvement. "What we tend to do as part of our analysis is look at what are the events that are potentially going to happen, what’s the impact of those events, what’s the cost of the thing, how should they respond to those events, what’s the likelihood of that event occurring. From there, we can build up a picture not unlike risk assessment."

A couple of additional points here. Business agility is a squishy, amorphous cloud, and progress here results from a number of converging factors. It may be difficult to pin all the credit for new business growth on the SOA. (Perhaps that data warehouse played a role? That new compensation system that finally rewards line employees for new innovations and contributions?) In fact, one survey showed that three out of four decision-makers say IT isn’t giving them anywhere near the agility they need. Could an SOA turn this thinking around?

Then there’s the possibility of diminishing returns to SOA deployments, as raised by David Linthicum. David said that there’s a point where the amount of resources being poured into an SOA effort may begin to exceed the benefits being gained. David calculates that most of the benefits of an SOA may be wrung out within the first five to six years.

The big gains come later as the SOA gains critical mass within the organization, thus the payback being heavier at the back end. 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.

But, either scenario being the case, are organizations prepared to measure the more squishy paybacks that may occur as their business does gain more agility, reflected in better time to market and responsiveness to change? Perhaps, as Pugsley recommends, SOA should incorporate a risk assessment aspect, that reviews a lot of ‘what-if’ scenarios.