According to industry watchers, achieving ROI with Web services is still a new concept and is not accurately being tracked in most customer shops. Indeed, the vast majority of the Web services currently in production involves specific integration projects that were undertaken to link systems together.
This approach, of course, is very different from the service-oriented architectures (SOAs) now being touted as the premium in Web services adoption. With an SOA, a company standardizes on Web services interfaces throughout the corporation and then uses Simple Object Access Protocol (SOAP), Web Services Description Language and other specifications as the basis of much of the IT architecture. But so few companies have implemented a full-fledged SOA that ROI data for this camp is virtually nonexistent, said Jason Bloomberg, a senior analyst at ZapThink LLC in Waltham, Mass.
SOAs bring with them an ROI conundrum akin to the classic chicken-and-egg riddle. The biggest benefit of standardization, whether it's Web services or not, comes when the entire company uses the same approach or methodology. But these enterprise-wide projects also take much longer to yield ROI because they are so big and incorporate so many parts; many customers are hesitant to undertake them at this point.
For these reasons, "measuring the return on this is relatively new," said Kim Harris, an analyst who follows the insurance industry at Stamford, Conn.-based Gartner Inc. Over 70% of these firms already use XML as the basis for information exchange via the Web -- mostly to help standardize the plethora of forms filled out by customers and others -- and are looking to incorporate Web services as well. "A lot of the benefits are theoretical," according to Harris, but include things like faster customer service, an improved connectivity process and increased IT productivity and efficiency. "The faster I can get information from my database, the more work I can get done," she explained.
Most of the information about ROI with Web services to date comes from money saved, not in new income generated, according to Harris and Bloomberg. Customers save because they don't need to buy third-party middleware that was previously required to connect applications.
Another savings comes from being able to use existing in-house expertise, including Java or Visual Basic developers, to create Web services-based integration interfaces.
Integration projects, in particular, can show quick payback because Web services aren't all that complex compared to other integration technologies. Most developers can pick up the concept very quickly -- wrap components, expose them and then use SOAP calls to connect them. It doesn't require a big leap to use Web services successfully in these schemes.
Exposing information to outside partners or customers with Web services is another area with potentially quick ROI. Amazon and eBay, among others, provide an application programming interface based on Web services standards, which allows even very small businesses to be able to connect into Amazon or eBay platforms to sell their wares.
Of course, actual ROI time periods depend on specifically how Web services are implemented, even in these types of quick-hit projects. Even "basic" integration can become quite complex.
Two basic types of integration projects
According to experts, there are two essential types of integration projects. With data delivery, a Web service grabs a customer's account number, for example, that can be shared by different applications.
Under the second, more complex type, a Web service combines with others and the results change depending on the data at hand. Let's say a customer places an order on a Web site. Before the order is completed, the system sends out a request to a database (essentially a Web service), which checks in with the credit card issuer's database to make sure the credit card isn't stolen or maxed out.
While the first type of simple integration yields a much faster payback period, ROI on the second type can take much longer because it incorporates more moving parts.
Another problem in calculating Web services ROI is that "we don't really have very good spending estimates," Gartner's Harris said. "There are different pieces needed from different vendors, and I haven't seen anything that's really apples-to-apples at this point." Without a good understanding of the budget outlay needed, ROI is impossible to nail down accurately, particularly for larger and more complex types of Web services projects.
In the future, ZapThink's Bloomberg said, the finances at the heart of Web services will become part of how SOAs are governed. To implement a successful SOA, IT will have to learn how to manage and cross traditional boundaries imposed by business units or IT organizations that work according to an operating system or a hardware platform. A major change involved with SOA is crossing these boundaries and thinking in terms of the service being provided to the customer or end user.
"Reorganizing IT to be truly service-oriented is really the hard part" of an SOA, Bloomberg said. The financial and ROI issues are pieces of the SOA governance question, and "there's no quick fix for that," he explained. "You need to establish enterprise-wide policies, and that's essentially a business issue for each company to deal with individually."
In the meantime, one ROI strategy for anyone building Web services meant for outside consumption is to play nicely with partners. "Focus on growth through excellent relationships," said Richard Stevens, a Seattle-based analyst with technology consultancy Capient. This includes "building trust in all your constituencies," he said. "Without these relationships, even the most technically innovative plan will inevitably fail on execution."
This was first published in November 2004