Make the many ROIs work for you: correct analysis of service-oriented architecture

“Return-on-investment” (ROI) is so important and frequent in business conversations that it’s easy to lose track of the variety of ways it’s used. Make sure the conversations you’re in are consistent about ROI, so that you reach your real goals.

ROI is fundamental in wise management of any activity. Naive decision-makers might try to practice simple-minded heuristics like, “do whatever is easiest now”, or “concentrate all resources on the most important project”. Literally and metaphorically, the first tactic results in spiraling debt, and the second one allows small problems to amplify out of control. The motivation behind ROI is that it provides a way to balance cost and benefit to optimize outcomes. In the datacenter, for example, ROI helps choose ten “winning” projects from among three dozen possible alternatives for the six months to come. These will typically mix relatively “lightweight” initiatives such as, “make Active Directory the common authentication mechanism for all servers” with more ambitious items such as, “plumb for water cooling”.

One difficulty arises when different people use “ROI” in different senses. For cultural reasons, quite a few organizations equate ROI with “cost-saving”; used this way, stretching out a refresh cycle might be “an ROI project”, because it shifts capital expenses to a future budget. Organizations like this might not recognize development of an application to improve customer support as worthy of ROI status, because the benefits are higher retention, goodwill, and engagement, none of which appear as expense categories.

Improved customer relations is an entirely real and legitimate benefit, of course. Be aware of the assumptions of your audience, and prepared to explain that a particular proposal is competitive, once the right spotlight shines on it.

Analysis of service-oriented architecture (SOA) projects are prone to systematic errors or at least confusions of this sort. Larry Carvalho touches on this in his, “Can Platform as a Service (PaaS) Vendors Meet User Expectations?“. There, he mentions that “Software as a Service (SaaS) and Business Process as a Service (BPaaS) are easily measurable, since invoices are based on the volume of transactions consumed.” In contrast, PaaS has even greater potential to benefit the organization by growing business “… through a cloud’s ability to improve business agility”, but cost-saving is at best secondary and probably hard to measure. Worse, as Carvalho also observes, PaaS pricing is considerably more opaque at this point than what SaaS has achieved.

In part, SOA vendors will continue to reshape their offerings to make purchase decisions easier, as the second article hyperlinked above hints. You don’t have to wait for that, though: understand clearly how your colleagues and executives use ROI, and make a point of expressing costs and benefits in terms they’ll understand. ROI is the right framework for analysis of SOA; you just have to use that framework wisely.