services must have accompanying service descriptions to convey the meaning and real world effects of invoking the service. These descriptions must additionally convey both semantics and syntax for both humans and applications to use. Each service has an interaction model, which is the externally visible aspects of invoking a service.

First, what exactly is SOA, and why should companies press ahead with it?
SOA is an approach to designing software that dissolves business applications into separate “services” that can be used independent of the applications of which they’re a part and computing platforms on which they run. When individual services within applications are all available as discrete building blocks, companies can integrate and group them in different ways to create completely new capabilities

A common analogy for this sort of software design is the popular children’s toy: LEGO building blocks. A service-orientation turns your entire application portfolio – and that of your partners – into technological LEGO blocks that can be snapped into virtually any configuration. Since, like LEGO, the only real limit on what can be done with these blocks is the builder’s imagination and vision – and no longer the technology itself (stripped of its rigidity and incompatibility) – SOA turns technology into a supple instrument of business strategy.

The benefits to individual firms, as they themselves recognize, are substantial. Based on an analysis of 35 actual SOA implementations in 11 industries worldwide, we gained a very clear picture of the kinds of benefits firms are obtaining from SOA .

one hundred percent cited improved flexibility, the root of all the other benefits. For example, for one of its brands, a large retailer with both a physical and Web presence redesigned its Website to better match the selling process in its stores. The store not only improved the business process for that brand, but, using SOA, availed the application for use across its multiple other brands. This new flexibility compounded.

the original benefits of shorter cycle times, increased collaboration, and reuse of IT assets. These benefits were typical of the projects we reviewed.
Therefore, the case for adopting SOA is exceedingly strong. But that doesn’t necessarily mean that the way you approach it is predestined, or that you’re absolved of the necessity to measure its benefits. Like any other investment, SOA has to be assessed systematically. To assist business leaders with this assessment, we suggest a method for analyzing SOA investments that balances rigor with the need to act fast.

A practical guide to measuring return on that investment.

With service-oriented architecture (SOA), good things don’t come to those who wait. While companies shouldn’t abandon building a business case for SOA, they should, in the interest of speed, take a simpler, more intuitive approach.

Introduction
Unless you’ve been incommunicado for the last few years, you’ve doubtless noticed the extensive press that SOA has recently received. Though the term can be intimidating, the fundamental concept is really quite simple – and very powerful. It’s that to meet your present and projected business needs, you can turn your software applications into “building blocks” that you can infinitely rearrange, and usually at great speed. It gives you a new way not only to “reconfigure” your business, but to connect to suppliers, partners and customers.

Much like the Internet before it, SOA is sweeping through companies and industries, upending the competitive order. Thanks to SOA, companies are fast commissioning new products and services, at lower cost and with less labor, often with the technology assets they have right in hand. It’s like discovering that with your existing condiments, you can make an entirely new and unexpected recipe, to the delight of your diners and of course yourself. Most important, SOA is helping to put IT squarely where it belongs: in the hands of the business executive, under whose direction it can create the most value.
This is, at any rate, the theory of the case – but, IBM wasn’t content to accept the theory at face value. So we undertook to study 35 SOA projects, across a range of industries and regions, with which we were intimately involved. We discovered that indeed, every last one of them exhibited improved flexibility, and the vast majority decreased costs – as well as realizing a host of other benefits. But we also discovered something very intriguing: Companies, if they developed a business case at all for SOA, weren’t doing it in the traditional way – replete with exhaustive evidence. They all recognized the difficulties and limitations inherent in building a business case for any fast-emerging technology. But whether they built a business case or not, they all implicitly understood that SOA entails massive business benefits – not least in the crucial area of innovation – and that given the speed with which SOA was conquering their industries, they had better get on with it if they didn’t want to be left out in the cold. Striking the middle ground – between no business case and the traditional one – IBM has developed a simplified approach to measuring the business value of SOA. That approach is the subject of this paper.

First, we selected the expected benefits from the benefits value tree and established the costs incurred according to one of the three cost scenarios..With its claims business solution, the company
expected benefits such as:

• Reduced processing time, where the overall cycle time for claims processes was shortened on multiple claims-related activities
• Reduced errors, where costs and payments were reduced as a result of improved quality in execution and handling of claims
• Reduced staff, where fewer staff at multiple levels were needed to staff the revised processes
• Protecting existing revenue streams, where the improved process controls and improved management resulted in more favorable benefit and cost ratio results
• Increased sales, as new functionality helped retain existing policy holders as well as positively impacted new sales
• Reduced maintenance costs, as older applications were being phased out, their maintenance costs were being eliminated and the new application maintenance costs were lower.

The costs incurred were for the full implementation. These included the cost to implement the front-end application interface, a Web-based solution that was part of the business application, and a purchased software package. The SOA infrastructure required some software and hardware, as well as the labor costs to implement it. Last, the cost to develop the interfaces to other applications was added. This included the costs for the SOA interfaces needed for the other applications.

In this example, it should be noted that second and third implementations used the same infrastructure and the same services. As such, the second and third projects experienced much lower costs, as both services and infrastructure were reused beyond their original intent.

As we look at the ROI for this overall solution, the reuse of these components resulted in an exponential increase in the ROI . What’s more, when we performed the same analysis on another project in the insurance industry, we saw similar reduced costs for implementation. This second project
shows a similar curve, but a steeper return. While the individual elements of the return calculation will likely vary project by project, a similar curve and return for successive uses of the same infrastructure can be expected.

Conclusion
No matter how you slice it, the case for SOA as a software design framework is very powerful. Chances are, because the business logic is so compelling, you’ll deploy it sooner or later. The measurement approach we’ve suggested should help you to add simplicity, sense and speed to the process, allowing you to exploit the first-mover advantages momentarily available.

Now, it’s in the second and subsequent implementations using the same infrastructure that not only is the real return evident – but that it’s likely to be higher than planned. For example, it’s widely accepted that reuse yields benefits beyond what’s immediately measurable as reusable application code is applied to new business problems. Large travel providers, for example, expose their online reservation systems to third-party Web sites (like travel agencies and other complementary travel providers), allowing for a big market expansion, at relatively little cost.

For revenue-generating SOA-based services, the returns can be even higher because applications
that previously added only cost are now contributing revenue to the bottom line. Another reason for using a multiple implementation time horizon is because business and IT benefits materialize on different timetables. As soon as the first implementation is completed, companies can begin realizing IT-related benefits right away, as components of the solution are reused in subsequent projects. But business benefits accrue according to a different schedule – one based on the rollout of associated business changes, such as modified processes or new product launches. Because of the variances involved, the time horizon for evaluating returns must be long enough to encompass both the IT- and
business-related benefits that materialize over multiple implementations.

Since SOA is so new, seeing will be a large part of believing. Many people will need to witness the first implementation to fully grasp the transformational power of SOA, not only technological, but strategic. As this awareness grows, it’s likely that the demand for these SOA-based services will grow.

If you’re only a service user (e.g., a Webbased e-commerce site using a shipping service), your application is using services made available to them by a service provider. The service provider could be other lines of business within your firm, your partners or, within the near future, external providers
making services available separately. Your total cost would be to change your front-end application,
allowing you to tap these services. If you’re a service provider (e.g., providing information services from your internal systems), you are creating services that others, within your firm or outside of it, can use with their applications. In this case, the total cost would be the SOA infrastructure, plus the
development of new, or alteration of existing, applications, plus the generation of interfaces.

If you’re both a user and provider, you would add user and provider costs together to arrive at the total cost of implementation. In this case, you’re building the entire application, and incur the costs for all the components.

We found that we could distill the benefits into two broad categories: improved flexibility, culminating in increased profitability (from both increased revenues and decreased costs, a double boon not associated with most technologies). Further, we found that there were two major more-qualitative elements that contributed to increased profitability: reduced operating risk and improved ability to comply.

The benefits of SOA are very real, and they’re extending from individual companies to entire industries.
A cellular telecommunications company we studied created an entirely new service – for locating cell phones – out of its existing IT assets. Though estimates vary, this capability could open up a US$_ billion market by _009 for this telco. A large agricultural machinery manufacturer needed to boost its ability to finance sales in its showroom. It tapped SOA not only to improve and expedite current lending practices, but to provide a new lending product to keep pace with competitive alternatives. It was able to double loan application volumes and increase the loan decision rate from __ percent to __ percent, all while maintaining prudent risk management levels.
A large insurance company that sells annuity products through a network of broker/dealers used SOA to streamline and automate data feeds, improve cycle time for data assets, protect an important sales channel, and position itself to reuse this data-access channel to sell through additional broker/dealers in the future.
If individual firms can extract these kinds of benefits from SOA, then masses of them are likely to adopt it, and whole industries are bound to change. Consider that according to IT analyst Forrester Research, 67 percent of the largest enterprises – those with _0,000 employees or more – will be using SOA by the end of this year.9 Nearly 70 percent of enterprise SOA users say they’ll increase their use of it. Clearly, SOA has already reached a “tipping point.”
How exactly could it change industries – or how is it changing them now? SOA could become the required way to collaborate among firms; dominant suppliers and buyers could demand it. SOA-enabled collaboration could cross current industry lines, inviting, among other things, the swift penetration of industries by new, unforeseen competitors. Even though SOA is relatively early in its lifecycle, it will soon become “table stakes” in many industries – particularly those where IT capability is a vital characteristic. By our reckoning, that includes most industries today.
Taking the logic a step further, it’s not hard to imagine the advent of an SOA-enabled global economy one day.

These last two might not be obvious, but consider: SOA affords an alternative to “rip-and-replace” – the present outcome of technological obsolescence – by exploiting and extending the life of existing IT investments. And it provides reusable software, reducing the risk of delayed IT projects and thus increasing the likelihood of timely new product and service introductions. As well, SOA enables faster and more thorough compliance with external and internal mandates. How? By centralizing a common source of functionality, changes made to comply with the mandate can be done once and used throughout the enterprise, eliminating duplication.

The point is that though you can look at the benefits in Figure 3 in isolation and they’ll be quite sizeable, to capture their full extent you have to factor in the impact that various benefits have on other benefits (e.g., from the chart, “increased reuse” leads to “reduced maintenance,” which leads to “decreased costs;” or in another path, “increased reuse” leads to “reduced integration time,” which leads to “reduced integration cost” and thus to “decreased costs”). In any event, the sum of the monetary value of all the benefits you deem applicable will be your overall benefit.

The investment analysis framework we propose has five primary steps:
1. Selecting the expected benefits from the benefits framework
2. Identifying the applicable cost scenario 3. Calculating the initial, simple return 4. Assessing and selecting the cost scenario
for the second and subsequent implementations
5. Keeping the benefits constant, calculating the returns for the second and subsequent implementations.

We believe this method will make it quite clear – if it isn’t already – that the benefits of SOA far outweigh the costs and that the benefits grow over time, while the costs decline.