Fee-based Web services: Terminology

Introduction

Imagine for a moment that the fictitious Trumpet Company, who supplies Direct Stream Digital (DSD) sound conversion software to manufactures of music CDs, recently decided to explore a new revenue channel by selling access to its software utilities. Realizing that there existed a broader market of amateur recording studios that could benefit from higher sound quality recordings, Trumpet needed to identify a go to market strategy, pricing models, and a delivery medium that would allow internet access to its software.

Upon completion of an identification exercise to determine the collection of software assets that they would make publicly available, Trumpet was advised by its IT staff that the next step in this endeavor was to leverage the technology of Web services and publish a service interface for their software assets. While the business side of Trumpet would concentrate on the development of pricing models for the new service and the business processes necessary to address tasks such as the fulfillment of usage requests and billing, the IT staff would begin to focus on the tools necessary for hosting fee-based services.

Unfortunately, it is in this phase of the effort where a company such as Trumpet realizes that there are still some unresolved issues pertaining to the business and deployment aspects of revenue generating Web services. During this effort that they may realize that their existing business processes do not easily migrate to the Web or that they need to come up with a entirely new pricing model. They would also begin to appreciate that they need more than just a Web application server to deploy and host their software services, they now have a dependency on a vast array of application software components that would help to enable their business processes for revenue collection.

Since my earliest involvement with Web services, I have been intrigued by the notion that today's business model for selling software is at a threshold of a new paradigm shift. This technology of Web services offers the industry the promise of selling software based on a fee-for-usage model as opposed to the typical shrink-wrapped approach. Although I would claim that the adoption of the Web services technology stack has been very strong and positive over the past year, developers have not yet achieved a critical mass of services that are freely available on the Web for consumption.

In previous articles (see Resources), I have discussed the vision of Dynamic e-business, the Web services technology stack, and potential business models for fee-based Web services. In this installment of the column, I plan to lay the semantic groundwork necessary to discuss the inhibitors and potential catalysts that are relevant to the industries adoption of fee-based software services. In the next two iterations I will build on these semantics and dig deeper into known inhibitors and potential catalysts.

Back to top

Reaching the critical mass threshold

For the Dynamic e-business vision to be achieved a critical mass of reusable Web services must first be reached. This is of course easier said then done. You are faced with the quandary of supply and demand -- Which will come first?

Many in the industry feel that there exists a strong trend towards e-sourcing, or outsourced services. Simply stated, e-sourcing is the delivery of standardized processes, applications, and infrastructure over the network, as a service (with both business and IT functionality). Differentiated from traditional outsourcing and today's hosting world, e-sourcing simultaneously serves multiple customers in a flexible automated fashion, requires little customization or integration, and provides capacity on demand, in a pay as you go model.

Analysts feel e-sourcing represents a fundamental shift in the way software will be bought and sold. Red Herring, for example, ran articles in September of 2000 and March of 2001 on the future of e-sourcing and distributed computing, respectively. Gartner Group expects Application Services to be a $25B market by 2004. Chris Galvin, of JP Morgan Chase, has stated that "subscription based services is where the Internet is heading." But how long will it take to get there and what needs to happen to reach that pinnacle?

Currently, the focus has been on the demand aspects of the critical mass threshold problem. The industry adoption of dynamic e-business technologies within the marketplace has been focused on internal integration issues. Enterprise companies have picked up on the value of Web services for internal application integration. They have begun to appreciate the immediate benefit of interoperability between heterogeneous platforms and programming languages. The ease by which existing processes can be exposed for reuses across numerous lines of business within the enterprise for immediate impact in IT expenditures pertaining to duplicated code and maintenance.

This internally focused activity is a first step in the adoption process. It represents a positive action in the effort to by-pass the inhibitor of the critical mass threshold. Once businesses begin to embrace the Web services development model in large scales then they will begin to drive the need for private UDDI servers, which in turn will allow them the option to expose a subset of their software assets for external consumption.

Based on predictions (as sited in Table 1) from analysts such as Gartner Group, the demand for fee-based Web services will become significant in about two years time after a growth in the supply of software services for the B2B and B2C market places.

Yet, there is activity today that helps to paint a bright picture for the building of a critical mass of software services that will help solve the supply and demand predicament. Microsoft who has created a Shared Development Process (SDP) to help work with professional business developers and users recently presented one example of such an activity. The goal here is to influence a consistent sharing of ideas and development thoughts for advanced next-generation XML Web services for both horizontal and vertical sections of the industry.

Another example exists with Visualize, Inc. (www.visualize.com), a small financial ISV that provides visualization software. They have already worked with IBM to use SOAP and WSDL to Web service-enable one of their software packages used by brokerage firms. They are now working on the next phase of the effort, which is to discuss with their customers the different business and pricing models that would be acceptable under an e-sourcing agreement. Meanwhile, Visualize is working with IBM on the deployment and provisioning environment necessary to support a new revenue channel.

Back to top

Terminology for fee-based services

When I talk to customers about this topic of software services and the value of embracing this technology as either a provider or consumer of services, I have observed that terminology also presents another inhibitor to the adoption of fee-based services. To meet this challenge I find it helpful to establish a common vernacular. The best starting point is the much-overused word: service. According to the Fourth Edition of the American Heritage® Dictionary of the English Language, a service is a facility that provides the public with the use of something, such as water or transportation, or in this case, software. Building on this notion is the concept of a software service, which I describe as a granular software resource or component that can be used as a building block for distributed applications within an intranet or for the assembly of microflows and business processes. A software service can accept requests to perform a specific set of tasks and respond to such a request using open messaging standards to insure interoperability. Additionally, a software service may itself be an aggregate of other software services.

Taking these definitions a step further, the pragmatic definition of a Web service would then be that of a specialized software service that is consumed by distributed applications over the Internet. American Heritage defines a utility as a commodity component that is provided for general consumption and designed for a variety of practical uses. It would follow then that a utility service is a commercialized commodity service or in this case a specialized fee-based Web service that performs a generalized and well-defined task in support of larger business needs. An example would be a metering service that was publicly available for a fee (see Resources).

A service oriented architecture refers to three participants: the provider, requestor and broker. I tend to extend the vernacular to include the owner of the software asset, such that:

• Asset owner is the person or entity that owns a particular Web service and the associated intellectual property pertaining to the software resource.
  • Hosted service providers are a type of asset owner. Business entities in this category are usually companies that have a software asset that has been enabled for Web services, who have selected a business model like subscription and now need a deployable environment to be hosted and managed. This role is best suited for small ISVs, who prefer to delegate the actual hosting aspects of the service to an entity that is more adapt at managing the infrastructure and quality of service issues associated with such a role. Visualize, Inc. would be such an example.
  • Independent service providers are another type of asset owner. Business entities in this category are usually companies that wish to establish their own environment for Web services and maybe even create a private UDDI node to publish those services to the Web. This role is best suited for enterprise customers.
• Service consumer is the requesting application or another service provider playing the role of an aggregator that will consume at least one, fee-based software service (function/operation).
• Service broker is a role that could be addressed by possibly two companies. The first could be any business entity interested in exploring the opportunities around directory services or yellow pages for reusable software components. The second would be vendor who can provide the necessary UDDI and hosting assets needed to provide a public UDDI service (green pages).
• Service provider is the person or entity that is actually implementing the hosting environment for the asset owner. The service provider may be the same as the asset owner, as in the case of an independent service provider. A service provider is the entity that is responsible for the deployment environment and provisioning aspects related to making a fee-based Web service available for sale. Figure 1 refers to such an environment as a utility server, a concept to be discussed in more detail later.
• Software Asset Mall (SAM) is a business entity that provides deployment and hosting facilities for 2 or more an asset owners (hosted service providers). In such a case the operator of the mall will collect revenue based on a combination of possible (but not exhaustive) service fees: hosting charges, transaction surcharges and access registration. A utility server is also necessary to meet the deployment and provisioning needs of a SAM.

Back to top

Recap

So, to recap, I have present a few inhibitors to the adoption of fee-based Web services. To solve the supply and demand problem developers must reach a critical mass of software services, and the quickest way to do so is to leverage reusable assets from ISVs as well as legacy software within vertical enterprises. To speed up this race to the threshold you must also settle on a common language for describing the business of software services.

In my next column installment, I will focus on the xSP Marketplace and Alternative Business Models with specific focus on the obstacles these topic areas present to the adoption of fee-based Web services.

Resources

• Learn more about SOAP, WSDL, and UDDI.
  
  
• Read in developerWorks about Metering and accounting Web services.
  
  
• Read about other IBM business Web services.
  
  
• Check out the tools in the Web Services ToolKit on alphaWorks.
  
  
• Read about Dan's description of Dynamic e-business and the models that it supports.
  
  

About the author

Comments

Back to top

Trademarks

Table of contents

• Introduction
• Reaching the critical mass threshold
• Terminology for fee-based services
• Recap
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

We want to know you!

Update your My developerWorks profile and start connecting with others

Special offers