Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Hybrid Cloud and Weblogic WAN Clustering | Main | Role of Testing in successful project implementation »

How to measure ROI for SOA projects? A Tollway Approach

Guest post by
Prasad Jayakumar, Technical Lead, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.


Early morning I was hitting I-94W to meet my client in Milwaukee.  I wish I had my I-PASS; toll varied from 25 cents to little more than a dollar.  I was wondering "Why not the government builds the infrastructure out of tax collected and let us free?"  Immediately I realized my ignorance.  My discussion topic with client was "How to measure ROI for SOA Projects?"  It was a meeting to see if we can present benefit of SOA in a tangible way to business.  I was wondering if the toll way could answer the question.


Please note: All values are notional. Click on image to enlarge.


The whole idea of SOA ROI by toll way approach is based on Throughput Accounting

Throughput (T) = Daily transactions priced at some notional $ value

Investment (I) = SOA Infrastructure Setup

Operating Expense (OE) = Development Cost + Maintenance Cost

Return on Investment = (T-OE) / I

There could be a day where IT paybacks some business unit (Service Provider), of course getting from other business unit (Service Requester).  What else could motivate business better than dollars?  I am not sure if business would be interested on asset/service reuse [it is presumed to be IT thing] unless we position it differently.  Tollway approach can go beyond measuring ROI if embraced by business and IT.


This is a very interesting concept. In fact in one of our projects a similar thought had come to my mind when we were trying to get the client to agree to paying a high upfront development cost for a setup automation project. Since it was difficult to quantify the ROI of the project it was difficult to justify the upfront investment. An alternative was to charge a nominal development cost upfront and then charge on a per record setup basis for the next two-three years through this tool to recover the cost of implementation. It would have worked for both parties but I guess clients are not yet ready for such radical pricing models.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles