Web Services Architect : Articles : Making Money out of Selling Web Services - Part I
Web Services Architect

Register for e-mail updates:

 

Making Money out of Selling Web Services ? Part I

Show me the Business Model

Mike Clark

Printer-friendly HTML version
Or purchase the extended PDF version of this article from our download site, or from Amazon.com.

It seems that we're coming to a crossroads in Web Services technology. I don't wish to paint a bleak picture, but few people in the industry have, at this time, actually sat down and considered how Web Services publishers can make money from selling Web Services. In part I, we'll look at the importance of developing a clear business model, and explore some potential revenue generating ideas. In part II we will go on to develop some models in more detail, and explore the potential for creating profitable businesses from Web Services.

By 'selling Web Services' we have in mind the development of one or more Web Services that are of such benefit to customers that it is preferable for them to pay for using them rather than develop a similar service within their own organizations. By paying for Web Services, customers contribute to their continued development and support.

ASP or not ASP

Web Services publishers are not the first to charge for service-based technology. The Application Service Provider (ASP) market, for instance, has supplied and charged for functionality available over the Internet for years. Their failure at standardization, however, is a definite disadvantage, but they also have a distinct and not so obvious advantage: a clearly defined business model:

All development starts with a requirement for a revenue stream: 'accounts package for car showrooms', for instance. The business model defines a method of charging. These, admittedly simplified, stages define the basic structure an ASP publisher uses to create a commercially viable application.

It is not until both these stages are completed that the most suitable technology is found and used. The choice of technology is based on requirements of speed and any other peculiarities that have emerged in the first two stages of the business model.

The result is that ASPs end up with a well-defined charging mechanism, clearly outlined client interface and application and a potentially profitable product.

The Web Services industry, currently, does not have a business model. A possible business model is, however, suggested in the diagram to the right.

In the case of Web Services, the ASP business model has been turned around. By defining the technology first, the technology is what seems to be driving the search for products to develop. This structure has obvious similarities with the unsuccessful dotcom strategy. Much of the dotcom discourse went along those lines:

Entrepreneur: 'I think my dotcom will succeed.'
Interviewer: 'What are you selling?'
Entrepreneur: 'I haven't decided yet.'

There is an imperative risk that the Web Services industry is falling into the same patterns of error. This direction of endeavour will, undoubtedly, change within the next few years, as many new and interesting products emerge. But by then the damage may already have been done. So what can we do to change direction?

An enormous amount of work has already been done in developing standards for creating Web Services, such as UDDI (Universal Description, Discovery and Integration), SOAP (Simple Object Access Protocol), and DISCO (Discovery of Web Services). To assure that publishing and selling of Web Services will be as efficient as the creation of Web Services, the major players of the industry must also combine their efforts in agreeing on and producing a basic business model for the commercial side of Web Services publishing. To do this, there is a need for something like a Web Services provider association. Such a body could recommend charging types and methods for Web Services publishing. Without these sorts of recommendations, a standard such as SOAP will become muddled by the vast amount of commercial alternatives that will sit above it.

Let Them Be Free

Because of the low costs in producing and publishing Web Services, the majority of Web Services are currently available free of charge. In the infancy of an industry, this is not a bad thing: it simply helps promote a new technology and the companies producing its services.

As the Web Services industry matures (it will probably take another nine or twelve months before we can say that it has properly matured) organizations will stop gaining benefits from press activity, and start to consider the possibilities of making money out of selling them. The step from a market of free Web Services to one where they cost money is, however, large and painful.

In fact, by the time we reach this stage in the development of Web Services, there may already be thousands of free Web Services on the market. They won't just come from single developers, but from large teams, attempting to make inroads into the Web Services market. The dotcom industry went wrong in a similar phase of its development, when the fundamentals of building a viable business model were often ignored. The current movement towards a market of free Web Services, therefore, sets a dangerous precedent.

As Web Services providers we need to introduce pay-to-use Web Services over the next few months. We need, however, to state immediately that we intend to charge for services. Microsoft did this when producing MSPassport. It is offered free of charge, but with the statement that it will become a chargeable product in the future. We can all decide on the best charging mechanisms, over the next year or so, before Web Services take off as a commercial venture.

Benefits of Charging

Why do we need to charge for Web Services? Apart from the obvious end revenue, charging for Web Services will serve to ensure quality, content and reliability. These are services that consumers will be willing to pay for.

Free Web Services will always be available, but we should distinguish our paid-for Web Services from them by offering products that live up to consumers' demands on quality, content and reliability. This may seem obvious, but it is often overlooked. How can we ensure that our Web Services live up to the high standards of quality, content and reliability that consumers demand?

It's not good enough to state on a help page for a Web Service that a particular service has never stopped working, or that its information is always up to date. An effective way to keep a high standard of a Web Service is to use a brokerage to check and analyse it: it will give an objective account, and assures the consumer of the quality and reliability of specific Web Services. The consumer will then also understand why we are charging for a Web Service.

Tortoise or Hare

Tortoise and Hare are Web Services types that provide two distinct categories of functionality:

1. Tortoise Web Services, for instance:

  • Wages and payroll
  • Call centre control

Tortoise Web Services have longevity built into the service. Because of the inherent complexity involved in implementing these services, customers have to commit themselves to days or months of work implementing them within their applications. The benefits are seen over a longer term in lower costs, benefits of low maintenance, easier payment terms, and little or no hosting contentions.

2. Hare Web Services, for instance:

  • SMS text messaging
  • Stocks and shares viewing
  • Faxing service

Hare Web Services are quick fix Web Services. They offer immediate satisfaction and require little or no commitment from customers. They typically take minutes or at most a day to implement.

At the moment, most Web Service providers are busily churning out Hare Web Services and this will, undoubtedly, be the case over the coming twelve months. There are, however, only so many calculators and SMS text messaging services that the industry can stand. But it is important to note that these Web Services serve an essential purpose: they build up an organization?s customer commitment.

If a customer uses one of our Web Services at this stage, and is satisfied with the service, he will want to see what other Web Services we have available. So if we want to continue and sell more complex Web Services, it is essential that we produce 'instant gratification' services to introduce our services to a large number of consumers.

In twelve months or so, however, we will see the Tortoise Web Services appearing. These services will change the direction of Web Services development, and take the industry into the realms of large corporations. What type of Web Services should we focus on to make money out of selling Web Services?

The best way for us to get into the Web Services market is to, first, concentrate on building up our organization?s profile and potential customer-base by producing Hare Web Services, and promote them on one of the available search engines at http://www.salcentral.com/ or http://www.xmethods.com/. This serves to increase our public profile, and attract customers. As we begin to establish a large enough customer-base, we should introduce them to Tortoise Web Services.

To be continued...

In part II of 'Making Money out of Selling Web Services', we discuss different charging mechanisms in detail, and look at what effects alternative directions of Web Services development will have on the Web Services market and its potential profitability.

This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com

Or purchase the extended PDF version of this article from:
our download site
Amazon.com

Adobe Acrobat format (PDF)
10 pages
Price: $25


Mike Clark is senior analyst at Lucin, and principal designer for the Web Services brokerage http://www.salcentral.com/.

Printer-friendly version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates


How useful is this article?
What's wrong and right about it?
What are your suggestions for taking it further?
Your views keep Web Services Architect focused.

E-mail us at feedback@WebServicesArchitect.com, or complete this form.
Note: fields marked * are compulsory.

Comments *:

E-mail *:

Job title:

First name:

Last name:

Allow Web Services Architect to display all or part of this message in an online forum.
I have read and agree to the terms and conditions.