 | |||
|
Wednesday August 29 2001 Making Money out of Selling Web Services ? Part II Show me the Revenue Printer-friendly
HTML version In part I we examined the need to build a proper business model for Web Services, and avoid the mistakes that characterise so many dotcom failures. In part II, we will look at specific charging mechanisms in more detail, and suggest some strategies for generating sustainable revenue from this emergent technology. Charging Mechanism Before selling a Web Service, we need to decide how we are going to charge for it. We can see some simple charging structures outlined below:
We don?t have to use only one of the above charging methods for our Web Service. We could combine any of the above methods to make alternative payment schemes. For instance, we could start with the ?No charge? method for a trial period before using the ?Charge per call? method. When implementing one or many of the above charging schemes, we either need to develop our own application to control the charging mechanism, or use one supplied by a Web Services brokerage. There are currently only two brokerages in existence that support charging for Web Services: http://www.grandcentral.com/, which offers a suite of services for integrating and charging for Web Services; and http://www.salcentral.com/, which offers an easy-to-implement authorize Web Services function, and allows for the charging of customers by credit card. Ratecards We can get some ideas about how to charge for Web Services from other industries. A good example is the telephone call industry. The ratecards that are used for ?phone calls work well for Web Services calls. They allow charging for calls on a sliding scale depending on number of calls purchased. Developing our own charging mechanism for Web Services might be a mistake. It diversifies the intensity of our development, when we could be concentrating on actual functionality within the Web Service itself. If we develop off-the-shelf software, we wouldn?t create a new distributing company to market and charge for its use, but we?d give it to an existing distributor, and allow it to take a portion of the profits. The same can be true of Web Services. If a brokerage does not support our preferred charging mechanism, then we should either change brokerage or collaborate with them to have it successfully implemented. Reshaping Markets ? Gaps Emerging It?s unusual and exciting when all players in an industry agree that a new technology is the right direction to go. Some of the giants of the industry - IBM, Microsoft, Sun, Borland, Macintosh and Lotus - have already adopted SOAP. In this kind of industry, however, developers? conceptions of particular products or ideas can move mountains. Microsoft is asking for six million Visual Basic developers to adopt its .NET technology. This won?t happen overnight and, while a lot of developers will assume the challenge immediately, many will be looking for alternatives. The learning curve when developing in .NET and the fact that most developers only learn a new software environment if there is some incentive to do so, are reasons why many developers might start looking around. During the next two or three years, changes to the development environment, brought about by major players of the industry adopting Web Services, and Microsoft?s .NET strategy, will mean that more developers than ever before will be looking at changing their method of developing. This will have the effect that new markets will open up, and existing ones will change. The ASP industry will, I believe, be an example of this. Developers in the industry will need to adopt Web Services quickly, if it is to keep up with an increasing consumer demand for application services that will interact with other applications and services. Another example is the vast Visual Basic industry. It is not solely driven by a striving to adopt new technology, but excels as a Rapid Application Development (RAD) tool for producing fast and efficient code, albeit at the cost of limited functionality compared to counterparts such as C++. But millions of developers have got used to these limitations and won?t adopt .NET technology as immediately as many people think. If an alternative COM-based Web Services server appeared, which would allow VB developers to turn their applications into Web Services, this could have a serious effect on the prospects of VS.NET. However, it wouldn?t necessarily be seen as an alternative, but could be taken as a progression towards using VS.NET. The Web Services market is not solely dedicated to producing functionality and selling it. It encompasses many different development platforms and as such we should be on the look out for alternative emerging markets. In fact, a major income for Web Services providers might be the services discussed above. Conclusion So how can we make money out of selling Web Services? It is essential that we, as Web Services publishers, start considering how we can charge customers using our Web Services. Web Services toolkit publishers also need to consider how to collaborate with other publishers, and make sure that a charging mechanism is in place that can be easily adopted and understood by customers. We also need to produce interesting, and sometimes controversial, ?instant gratification? Web Services. This would draw attention to the industry and give it space and interest in the general press, outside of the technical press coverage it gets today. There is a clear risk that Web Services may fall into the same errors that trapped the dotcom industry; for instance, not charging enough for a service. If we produce free Web Services, we ought to consider also producing a few Web Services to which customers need to subscribe in order to use them. Another important part is to publicize Web Services directories such as http://www.uddi.org/, http://www.salcentral.com/ and http://www.xmethods.com/. These help promote Web Services, and increase consumer awareness of the commercial aspects of Web Services. The development of Web Services is likely to witness a fundamental change in the way in which much software is developed. Like any emerging market, it needs to be handled carefully, and the commercial aspects of each step have to be thoroughly thought out before continuing. With the right sort of direction, it is likely to be lucrative for many companies. Without direction, however, it may well go the dotcom route, with free services being standard, and face difficulties turning visitors into customers. 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:
Adobe Acrobat format (PDF) Keep up to date with all the new articles and features on
Web Services Architect: |
