7: Calculating ROI

Assigning a specific financial value of SOA can be difficult (per an earlier discussion, many of the potential benefits are not quantifiable), but in many companies, IT managers are required to provide cost-justification for their decisions all the same.

SOA is a technique that is used to develop a system that enables tasks to be performed, and it is the tasks, rather than the development technique, that generates revenue for the company. In that sense, SOA does not generate revenue, but it may create efficiencies that lead to cost savings.

This is a common problem to IT, and a survey is cited that indicates 89% of companies rely on "informal guesswork" to determine the value of their initiatives and "more than half" of executives conceded doubts as to whether their ROI metrics are even accurate.


Business turn to SOA to provide enterprise capabilities that contribute to their competitive advantage: being able to be nimble, flexible, and adaptable in order to be more competitive and responsive to customer demands. While these qualities are regarded as important, they can be difficult to quantify, though it may be possible to assume credit for the investment the company is making in pursuit of these objectives:

For example, if a company is willing to make an investment in being "adaptable," there may be some figure attached to the value of adaptability (in terms of dollars gained or lost, on a high level). If SOA is necessary to achieve these goals, than it can claim credit for at least part of the amount that the goals are considered to be worth.


Tactical ROI deals with short term initiatives with results that are more observable or measurable. SOA can claim cost savings for reducing middleware, licensing fees, development costs, system maintenance, and the like. Even that is a bit fluffy, as it entails suggesting what the costs would have been if another approach had been taken.

The only "hard" numbers for SOA pertain to the current costs that can be eliminated after the solution is implemented: the company can retire systems, stop paying licensing fees, lay off workers who are no longer needed, etc.


"Operational" ROI considers the value of SOA as being derivative of the value to the enterprise in supporting day-to-day operations and providing reusable assets.

The "iterative reuse model" concedes that the cost of developing a service may be substantial, but it constitutes a savings in that future services can leverage the service rather than have to develop a redundant capability. For example, if a service is created once and can be reused fur more times, it represents an 80% cost savings (presuming that the service costs as much to develop as any alternative solutions). One can estimate iterative reuse by examining the existing information systems, determining the number of systems that might reuse the service in future (when they are upgraded) and projecting the cost savings.

There is also a "calculated reuse model" that attempts to calculate the cost per function of SOA on an ongoing basis, which generally determines the cost-savings of each "function" execution, both for the present project and others than may reuse the service, to arrive at an ongoing stream of cost-savings as a result of an SOA deployment.


SOA is most closely aligned with strategic models of ROI, as their aim is to effect a change in the infrastructure of the enterprise that will have long-term impact toward achieving a desired future state. However, there is no "real cost" model for achieving a strategic objective such as gaining the ability to act quickly to future changes in the market and regulatory environment.

Much of this relies upon the creation of future scenarios supported by historical data, but there is substantial ROI on SOA initiatives when you can determine the cost saved or revenue earned if the company can do things faster.

As examples, a strategic ROA estimate may consider the amount that would be saved if SOA enabled the company to respond 20% faster in instances where fines and legal costs are assessed on a per-day basis, the company will earn revenue and gain a market advantage by providing services quickly, or cost savings will accrue when an IT solution is installed and ready for use.


Risk is often a "hidden factors" in ROI calculations. It includes both the risk inherent in a schedule (the willingness of a company to "wait" for a solution to be deployed and its tolerance for delays), the ability to adjust or modify plans to adjust to unforeseen events that raise, and the ability to modify the solution in the event that it looks like the predicted outcomes cannot be achieved without deviating from the original plans.

In all instances, SOA is inherently more capable of adjusting to risks, because it's comparatively simple to make adjustments in a number of small and independent services than to a monolithic system due to the compartmentalization of services: it is easier to pinpoint which services need attention, and easier to direct labor (or acquire additional hands) to attack a problem that is subdivided into independent components.