Exploring a new revenue channel by selling access to sound conversion software over the Internet is a business objective of the fictitious Trumpet Company, who supplies Direct Stream Digital (DSD) sound conversion software to manufactures of music CDs.
As Trumpet's IT staff began to peel back the layers of technical issues around the deployment of fee-based Web services a few key questions began to bubble to the top. What software is available for the deployment of software services under a variety of revenue models? Which vendors have development tools available today to help ease such and effort? How does Trumpet build a system that will allow for the provisioning of a variety of usage models for a diverse array of service consumers?
These questions helped the fictitious company realize that there are still some unresolved issues pertaining to the deployment aspects of revenue generating Web services. They concluded 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.
In my previous two column installments, I described some of the inhibitors impacting the adoption of fee-based Web services (see Resources). In this installment, I will point a few catalysts that are imperative to jump starting this new revenue channel.
From the perspective of the service consumer, a utility service is a commercialized software commodity. However, from the perspective of the service provider, this commodity is really an aggregation of a number of different software components. While some of the components may have a published service interface based on a binding language such as WSDL, others may require a more traditional tightly coupled interface. From a service provider's perspective there exists a set of software services that are more granular in nature and support the needs of a Web service deployment environment, I refer to these catalysts as enabling services. This category is comprised of building blocks for fee-based Web services, which are just one type of software service.
In general, the term enabling services pertains to the collection of software components that are necessary for a service provider to enable fee-based Web services. For example, before an asset owner agrees to have a service provider deploy and host his Web service, the asset owner will want to feel comfortable that the service provider can provide an infrastructure that can support features such as billing, metering, and provisioning. From the perspective of service providers, they just want to provide an infrastructure that contains a set of locally installed enabling services as well as access to such services that are remotely available.
As depicted in Figure 1, enabling services can be characterized as a conceptual stack of four different categories of software services: Core, Infrastructure, Application and domain services. A few examples of enabling services are offered in Table 1.
Figure 1: Categories of enabling services
Core services are Web services that are critical components of any distributed enterprise architecture. services that fall into this category include security and trust management, event notification, data management, and transaction coordination services.
Infrastructure services provide higher levels of functionality targeted at specific pieces of an e-business infrastructure. Here you find services for implementing commercial transactions, broker services, data warehousing, managed workflow and licensing.
Up to this point in the layer cake diagram, I have been describing categories of enabling services that are typically local to the service provider's hosting environment. Basically these installable services are software components that can be are part of a deployment environment (that is, the utility server) or purchased and installed separately. In either case, they reside locally within the hosting environment.
Application services represent software services that provide narrowly focused pieces of functionality that may leverage the capabilities provided by both the Core and Infrastructure services layers. An Address Book service, for example, may build upon security, data, and transaction management services. Or a language translation service may build upon lower-level transcoding and licensing services.
Table 1: Examples of enabling services
| service | Description | Type | Category |
| Security | User authentication, signature verification, and data encryption services | Installable | Core services |
| Key management | Digital certificate management service | Installable | Core services |
| Transformation | Message and protocol transcoding including XSLT and ebXML/EDI | Installable | Infrastructure services |
| Logging | Generalized logging of auditable activities including tracing and critical events | Installable | Infrastructure services |
| Clock | System time services | Installable or remote | Application services |
| Calendar | Date services | Installable or remote | Application services |
| Authorization control | Providing resource access control pertaining to the consumption of services at the component and operational levels. | Installable | Infrastructure services |
| User management | User address, preference data, contact list, inbox, calendar, wallet, etc. | Installable | Infrastructure services |
| Tax calculator | Local tax calculator that supports international as well as local tax rules. | Installable or remote | Domain services - finance |
| Credit check | Credit worthiness validation | Installable or remote | Domain services - finance |
| Payment services | Payment authorization and capture supporting a range of payment instruments (checks, credit-cards, etc). Plus support for accounts receivable reports and inquires. | Installable or remote | Domain services - Finance |
| Account management | Associating user accounts with fee-per-usage plans for specific services -- provisioning. | Installable | Infrastructure services |
| Billing | Account centric bill generation with flexibility for billing periods, billing locations, and invoice types (paper, e-mail, etc). | Installable or remote | Application services |
| Order management | Providing support for tracking service requests. This includes the ability to perform status inquiries. It would be applicable to purchase orders as well as managing any request for services that would be fulfilled in an asynchronous manner. | Installable or remote | Application services |
| Fulfillment | A generalized fulfillment service that can interface with shipping providers such as UPS and FedEx. | Installable or remote | Application services |
| Currency conversion | Real-time currency conversion calculator. | Installable or remote | Domain services - finance |
| Service credentialing | Analogous to the Better Business Bureau this service would act as a repository for complaints for Web services. And provide a rating for such Web services. | Installable or remote | Domain services |
| Metering service | Providing the instrumentation necessary for auditing service usage as well as availability of the service. This would be important in a hosting environment where the hosting entity would want to bill for usage. | Installable | Infrastructure services |
While installable services provide vendors with a new channel for their software, remote services provide them with greater revenue opportunities by leveraging alternative pricing models for remote usage. The final category of enabling services, domain services, can be deployed as either an installable or remote service. These domain services classify those services or suites of services targeted toward specific application or business domains, such as financial and travel services.
The taxonomy approach here is for descriptive and comprehensive purposes. The key message at this juncture is that enabling services provide a business opportunity for software vendors and they are an important portion of the criteria necessary for the development of the fee-based Web services marketplace. The bottom line is that as enabling services become more pervasive it will then become easier for service providers to build hosting environments from pre-existing loosely coupled software services. Such an increase in service providers that support fee-based Web services is a near term necessity if the industry is to begin to sell software as a service. enabling services can be a catalyst to that effort.
The utility server that I referred to earlier represents another key catalyst to the evolution of fee-based Web services as it attempts to address the needs to the fictional business entity, the Trumpet Company.
Essentially, those businesses interested in publishing fee-based Web services today must take one of three possible paths with respect to the deployment and management of their services for revenue generation:
- They could choose to build their own environment.
- They may decide to seek out a vendor who provides an out-of-the-box deployment environment, a utility server.
- They could open an account at a software asset mall (SAM), which uses a form of a utility server to deliver its solution.
However, a current inhibitor is that service providers as well as software asset malls do not currently exist with the capability to meet the requirements of asset owners seeking to exploit this new channel for selling software.
A utility server provides a framework to support the selling of software on a fee for usage basis. It is a hosting environment upon which a software asset owner can deploy, run and manage fee-based Web services. An Independent service provider as well as a software asset mall could use such a server. The sever contains the categories of enabling services and specifies all the necessary features service providers and service consumers would require for the deployment, management, registration and consumption of fee-based software services. It would also support a minimal set of revenue models and at best be flexible enough to support customized revenue models.
A casual stroll through the basic use cases of a utility server will help us get more comfortable with the concepts depicted in Figure 2. In this diagram, I introduce five actors associated with the uses cases:
- Service provider administrator
- Service consumer
- Asset owner
- Certificate authority
- System
Figure 2: Basic use case model
This use case scenario pertains to the configuration of the server environment for the asset owner. The configuration details here are above and beyond those handled during installation or deployment of the software asset into the application server. Specifically, this use case deals with the creation of a profile for the asset owner as well as the definition of a microflow (the intermediary steps necessary to carry out an invocation of the service). For example, the system provider administrator would need to create and prime an asset owner profile so that the asset owner will be able to remotely access and provision his/her software assets. One could imagine a profile creation wizard to simply the task for the administrator. Additionally, a visualization tool would be helpful in the definition of a microflow pertaining to activities such as authentication, metering and billing.
The objective for this uses case is for the service provider administrator to install the actual software assets of the asset owner into the hosting environment. Application development tools assumed to be part of your typical application server already address this use case scenario. Aside from the pre-condition of the creation of an asset owner profile, the service provider must also receive all source and binary code necessary to run the software asset. This includes but is not limited to a WSDL file and/or SOAP deployment descriptor files. The utility server should not concern itself with the mechanism for the delivery of the actual software asset. However, it should address the seamless installation and validation of the software.
The asset owner and the service consumer represent two users of the utility server. Depending on the security model chosen for the utility server, Digital Certificates may be required for these users of the system. After satisfying the pre-condition of a mutual Certificate Authority, both users would be able to request certificates allowing them to access features of the system. The objective of this use case is to incorporate certificate requests into the portfolio of tasks supported by the utility server.
As utility servers emerge the area of provisioning may very well be the differentiating feature. The objective of this use case scenario is to allow the asset owner the ability to select from a list of supported fee-based revenue models and for each model, describe and associate the usage policies allowed for each asset hosted by the system. Here is where the asset owner gets to define units of usage as well as price per unit and other data elements that are revenue model dependent. It is feasible to imagine the utility server to allow the service provider administrator the capability to control which revenue models are supported as well as allowing the list of supported models to be extended.
The objective of this uses case is to allow a potential service consumer to register for the usage of hosted Web services. Basically, it addresses the aspect of policy agreements. Theoretically, the industry would like to move towards programmatic policy agreements, but an initial and acceptable step would be that of a manual (online) registration to achieve the same end result, an agreed upon contract between the asset owner and the service consumer. The utility server could provide a browser UI to fill out the necessary registration form information. You can imagine this being a unique URL for each asset owner (like a myServices page) or simply a collection of all services hosted by the server. Once the consumer creates an account via the registration process, he/she would then create a contract for each hosted service he/she would like to consume. This iterative process would allow the service consumer to select from a list of usage polices being offered by the asset owner for each desired software service. The result would be an authorization record associated with the asset owner and the service consumer accounts pertaining to a specific Web service operation. This authorization record would contain a unique contract that included the selected usage policy as well as terms and conditions for such usage.
This use case describes the actual use of the service. This equates to nothing more than a basic SOAP based RPC call from the requesting application to the service provider. However, for fee-based Web services the invoked service most likely will represent a collection of activities ranging from authentication and authorization to metering and accounting. Therefore the utility server needs to allow for the publishing of more than discrete Web services, it must publish a service interface that represents the workflow of consumption, which would be defined by the requirements and guidelines of the asset owner and service provider, respectively. This workflow (or microflow) must be interpreted and audited by the utility server.
The purpose of this use case is to allow for the delivery of an invoice from the serviced provider to the service consumer. Based on frequencies defined in the profiles of the asset owners, the system would iterate through the profiles and submit requests to a Bill Presentment service to generate and send invoices. This Bill Presentment service may be itself a fee-based Web service consumed by the service provider.
So to recap, in the previous two columns, I presented 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 developers must also settle on a common language for describing the business of software services. Furthermore, business entities must be able to change culturally to define and accept new ways of doing business, such a pricing methodologies and customer support structures. For those businesses that seek to defer the hosting of their software services to service providers, they must manage closely all links to the customer relationship and remain the "owner" of the customer.
Additionally I presented in this last column entry on the topic of fee-based Web services two types of catalysts for adoption. These catalysts are dependencies for any successful deployment of fee-based Web services. Namely a deployment platform such as the utility server described herein that will provide for the provisioning, execution and management of fee-based Web services; and enabling services which will help to ease the creation of deployment environments for service providers.
So, on behalf of the fictitious Trumpet Company and all those business entities that would like to explore this new revenue channel around fee-based Web services, I would like to encourage a few industry players to lead the way and ignite this market. What is needed?
- A vendor who will sell a generalized deployment environment that supports a common set of revenue models for Web based software services
- One or more business entities that can justify a business opportunity around the concept of a software asset mall.
- Understand the terminology behind fee-based Web services.
- Learn about the inhibitors to fee-based Web services.
- Read about metering and accounting Web services.
- Read about other business Web services.
A 13 year veteran of IBM, Dan Gisolfi holds a Masters Degree in Artificial Intelligence from Polytechnic University, and a BA in Computer Science from Manhanttanville College. Prior to 1999, his career was focused on software and product development ranging from Expert Systems, OS/2, and Secure Internet Payment Systems. As a member of the jStart (jump-Start) Emerging Technologies Team, he keeps his hands dirty in both the business and technical aspects of customer engagements. From Business Development Manger and Evangelist to Solution Architect and Contract Negotiator he gets to wear many hats. As jStart Team Lead for Web services, he is helping IBM drive the adoption of this emerging technology through real business solutions. You can contact Dan at gisolfi@us.ibm.com.
