Web Services Business Models
You may have noticed that I didn't list software-as-a-service as a Web services application template. That's because software-as-a-service isn't an application. It's a business model in which you license subscription rights to access hosted software rather than license the rights to deploy the software in your own organization. For example, Salesforce.com uses the software-as-a-service business model. Salesforce.com hosts a CRM system, and users pay a monthly subscription fee to use the software.
A lot of the early hype about Web services led many people to equate Web services with the software-as-a-service business model. The hype projects a blue-sky vision of being able to dynamically discover, assemble, and consume Internet-based software services. But IDC predicts that the realization of this vision is at least 10 years away. I view that prediction as optimistic.
My point is that, except in a few rare circumstances, you don't sell a Web service. Instead you sell some other type of product or service, and you use Web services to help you do that. Only in very rare circumstances are Web services the focus of their own business model. Without a viable business model, it's hard to create a business case for Web services. For example, let's look at Google.
Google is the world's leading Web search company. Google provides a public search engine that contains an index of more than three billion Web pages. The normal interface to this search engine is a human-oriented browser interface. The business model that supports this public service is advertising. Users can access the service for free in exchange for viewing a few ads. Google collects revenues from the businesses that place the ads.
Google also provides a Web service interface to this public search engine. It calls this Web service the Google Web APIs. You can use these Web APIs to query the Google search engine from an application rather than from a browser. The results of the search are returned as structured data so that the requesting application can process the information.
As of the time of this writing, this Web service is still in an experimental stage. Google is encouraging developers to use their imagination to create new and interesting applications using the Google Web APIs. Here are three examples:
Subject monitoring: issue regularly scheduled Web searches to find any new information on a particular subject
Market research: issue regularly scheduled Web searches and analyze the difference in the amount of information available on the subject over time
Plagiarism search: search for phrases from a piece of writing to ensure that it is original material
Researchers and developers may be excited about the Google Web APIs, but it's hard to figure out what benefit Google will gain from this Web service other than goodwill. The Google Web APIs undermine Google's normal business model. The Google Web APIs don't constitute a new service. Instead they simply provide a programmatic interface to Google's public Web search engine. The Web APIs are free. Users are required to register, and they are limited to 1,000 queries per day per user, but users of the Google Web APIs don't receive the Google advertisements.
The cost of an individual Google search is minuscule. Google views it as a reasonable investment to give away a few million searches in exchange for the generation of goodwill. But in general, I wouldn't recommend that you follow Google's example. Web services should be designed to support your existing business model. They should provide a new or improved mechanism to sell or use an existing product or service.
For example, let's look at Kinko's, the world's leading provider of document solutions and business services. Kinko's has offered a browser-based utility for quite a while that allows you to send documents from your PC directly to Kinko's for printing. Now Kinko's wants to use Web services to make the process even more seamless. Kinko's plans to roll out a “File, Print...Kinko's” Web service in mid-2003. This Web service allows you to send a print job to Kinko's over the Internet directly from any Microsoft Office application. The service will require you to install a small add-in to Office, which will supply the client interface to the Kinko's Web service. After you've installed this add-in, “Kinko's” will appear in your list of printers when you select File and Print...from the Office menu. When you select the Kinko's print service, Office will launch Kinko's client interface, which then presents you with an easy-to-use dialog box to guide you through the process of submitting a print job. The dialog box will help you find a convenient Kinko's location, select options such as stapling and binding, and specify payment, notification, and delivery methods.
Suppose you're sitting in your hotel room writing a proposal in Microsoft Word. When you're finished, you select File, Print...Kinko's. The hotel's high-speed Internet connection sends the print job to a Kinko's in another city, and the proposal is delivered directly to your client. Kinko's will even send you a notification when the job is complete.
The “File, Print...Kinko's” Web service doesn't compete with the company's core business model. It enhances it by providing another way for users to submit print jobs. And it provides a level of convenience that many users will certainly appreciate.
Amazon also uses Web services to enhance its core business model. Amazon's business model is based on online retail sales. Amazon is renowned for the features of its online catalog, which provides the primary consumer sales interface. The catalog is designed to be viewed by a human sitting at a browser. Amazon also wants to make this catalog available to applications so that its 800,000 marketing affiliates can more easily sell products for Amazon. So Amazon created a Web API for its catalog. Before it offered this Web API, it was quite difficult to access the Amazon catalog from an application. You needed to build a screen scraping application that simulated a human sitting at a browser.
The new Amazon Web API allows Amazon's marketing affiliates to easily incorporate Amazon content and features into their Web sites. Many of Amazon's most popular search facilities—such as keyword search, ISBN search, and even “Listmania!”—are available through the Web service. Now consumers can buy products from Amazon transparently through the affiliate sites. The affiliate Web site uses the Amazon Web service to search Amazon's catalog and display the results on its own site, including features such as Amazon reviews and book ratings. This free Web service is a win-win situation for both the affiliates and Amazon. Each time a consumer makes an Amazon purchase through the affiliate site, the affiliate earns a 15% referral fee. Meanwhile Amazon expects to see a boost in product sales.
UPS also uses Web services to promote sales. UPS provides a set of Web APIs called UPS OnLine Tools. Businesses can use these APIs to connect their applications directly to the UPS logistics system to add integrated shipping, tracking, and related functionality. UPS OnLine Tools are available at no charge, and UPS provides free e-mail support. As with Amazon, this Web service offers a win-win situation. Customers appreciate the way this Web service can streamline their logistics process; UPS can expect to see an increase in UPS shipments.
Sometimes Web services can help enable a new business model. T-Mobile International, a division of Deutsche Telekom, is one of the world's leading international mobile communication providers. One of its service offerings, T-Mobile Online, provides a wireless Web portal for more than three million T-Mobile customers in Austria, the Czech Republic, Germany, and the United Kingdom. As with most wireless plans, the business model is based on consumer usage.
When first planning T-Mobile Online, T-Mobile realized that to promote consumer usage it needed to provide interesting content on the portal. Recruiting content providers was critical to the success of this new venture. T-Mobile needed to make sure that it was as easy as possible for content providers to join the network.
One of the biggest challenges T-Mobile faced was figuring out a way to give the content providers access to information about individual consumers. Providers need this information to furnish customized, localized, useful content. Another challenge was devising an affordable micro-payment system to ensure that the content providers got paid for their services.
Given that each content provider might have a completely different IT infrastructure, T-Mobile elected to use Web services. All consumer information and billing services are made available to the content providers as Web services, as shown in Figure 2-4. The Web services ensure that content providers can quickly, easily, and in expensively integrate their content into the T-Mobile portal.
Figure 2-4. T-Mobile Web services maintain user session information, automatically capture and manage billing and payment services, and allow content providers to obtain information about consumers.
This venture has been very successful. T-Mobile Online has enlisted more than 200 content providers to make the wireless Web interesting and appealing to T-Mobile consumers. Through T-Mobile Online, these content providers provide services such as e-mail, Short Message Service (SMS) messaging, news, sports scores, restaurant recommendations, directions, stock trading, banking, ticket purchases, gambling, and more. T-Mobile doesn't charge either its consumers or the content providers for these Web services. Instead T-Mobile makes money from the increased airtime the consumers use to access these third-party offerings. The Web services aren't the focus of the business model, but it wouldn't work without them.
In the examples I've cited so far, I've talked only about external integration applications. One key theme that permeates all these examples is that Web services can make it easier for your customers or partners to do business with you. Anything that simplifies business integration is a valuable commodity. Another recurring theme is that Web services do not themselves define a business model. Instead, they support existing business models, and in some circumstances they enable a new business model.
Although the external applications are interesting, most production applications based on Web services are internal application projects. As with external Web services, internal Web services should support your core business model. You can use them to improve and optimize your internal application systems to make your business processes work better. The first and foremost reason you should be exploring Web services is that they can dramatically lower the cost of application integration.
Merrill Lynch completed an internal application integration project in 2002. The idea was to build an integration bus to provide access to mainframe-based Customer Information Control System (CICS) applications. An integration bus is a common pathway that multiple applications can use to communicate. The original estimated cost for the project based on message-oriented middleware was $800,000. Then the company switched to Web services technology. Rather than purchase software licenses for the MOM technology on a host of different platforms and then build a bunch of adapters to allow the various client applications to use the MOM middleware, Merrill Lynch developed a small SOAP gateway for the CICS environment for only $30,000. Now any client environment can access the CICS environment using SOAP, and Merrill Lynch doesn't need any special software or any special adapters on any of its systems.