Any sound investment in technology requires a business justification. Whether that justification reflects a new revenue channel or an efficiency improvement to the daily operation of a business, the person or persons responsible for the eventual decision to adopt a technology must be convinced that there is a strong value proposition for their business.

Unlike other emerging technologies of recent years (Java, XML, Pervasive Computing), the promotion of web services will not be focused solely on IT decision makers. The adoption of this technology is highly dependant on the roles and revenue models a business entity may decide to deploy. For this reason, line-of-business (LOB) executives will highly influence the rate and manner of adoption.

In order to implement web services, software architects will have to justify the business rationale of the web services model to their superiors. Thus, I begin this article by trying to explain why a business would need web services and how it would impact their business goals.

Possible business roles

In the service-oriented architecture (SOA) of web services, there are three distinct actors: the Provider, the Requestor, and the Broker. If you are a software engineer, it should be clear that any given subsystem or process could be designed to play the role of a requestor or provider or both. However, when looking at these possible nodes of participation from the vantage point of a business executive, there exists a clear need to understand the potential business models associated with each node.

Once again, from a general IT perspective any web Service -- a web-accessible software resource component -- can be a requestor of services to other distributed software components, either locally or remotely. In such a case, the software architect may decide to associate a web Service with this role to take advantage of a possible reduction in the operational or maintenance costs of an application, or to improve the flexibility of choice associated with available implementations of a given business process. All this being true, the question remains:When does a business decide to identify with the role of a requestor, provider, or broker? Furthermore, is it possible to identify with more than one such role?

Although there exist three SOA participation nodes, there are actually five possible business roles a company has to choose from. Lets take a look at each independently.

• Service Requestor: For a business to identify with this SOA role, it must find some commonality between their business activity and the actions of a requestor. There are two clear business activities that would allow a business to benefit from implementing the role of a service requestor:
• Content Aggregation is an activity where a business entity interacts with a variety of content providers to process or reproduce such content in the desired presentation format of its customers. Examples of such business entities would be any internet portal or information service provider.
• Service Aggregation is an activity where a business entity interacts with a variety of service providers to re-brand, host, or offer a composite of services to its customers. An example of such a business entity would be a mobile portal the likes of OnStar (www.onstar.com).
• Service Provider: For a business to identify with this SOA role, it must view itself as performing some degree of an electronic service. Whether that service is defined as the processing of data or the act of carrying out a specific task, the business entity must believe it is performing work for others as an occupation or a business. Since almost anything can be a service, it would be hard to itemize an exhaustive list of applicable businesses. However, we can mention a few straightforward examples:
• Independent software vendors are prime examples of potential service providers. They currently own and maintain a software asset that performs one or more tasks. These software assets could be made available as an aggregation of services or broken down into distinctly separate software service resources.
• Business processes that are proven and generalized for a diverse set of applications would be good candidates for service providers. For example, if a bank felt that its business process for loan processing was a strong enough asset to be made publicly available and was willing to support it as a business offering, then that bank could view itself as a loan processing service provider.
• Registry: If a business entity finds itself collecting and cataloging data about other businesses and then selling that data to others, it may identify well with a registry, a form of SOA Broker. Usually, a registry would collect data such as business name, description, and contact information. In UDDI terms, this SOA role is often referred to as the White Pages.
• Broker: Building on the concept of a registry, business entities may also be able to identify with the notion of a broker, which in UDDI terms is often referred to as Yellow Pages. Brokers usually extend the value proposition of a registry by offering intelligent search capability and business classification or taxonomy data.
• Aggregator/Gateway: Any business entity that provides Broker capabilities plus the ability to describe actual policy, business processes and binding descriptions would be able to identify itself as Green Pages.

Back to top

Justifications for adoption

These business roles must still offer some added value to a business before it decides to associate with a given role and adopt the technology. To this end, there are two categories of factors that would justify the adoption of web services technology. The first category pertains to those reasons that are not always associated with a definitive monetary value, and the second category pertains to revenue-specific justifications.

Non-Revenue Justifications
Non-Revenue justifications account for those adoption motivators that are important to the growth and survival of a business, but cannot be easily or not necessarily credited with a specific monetary value. Some examples are:

• Time to market.
• Improving operational efficiency through communications, and lower operational costs.
• Compression of the supply chain by exposing your internal processes to close business partners.
• Exploiting network effects by being the first to market or becoming a de facto standard.
• Improving the rate of change.
• Broader exposure of penetration into new channels.

Revenue Justifications
Revenue justifications allow a business to reach new customers, expand existing partnerships or build new ones, and expose existing offerings to new delivery channels. This category of adoption motivators are the sweet spot for potential service providers. Although the following may not be an exhaustive list, my team has been hard pressed to come up with additions. I welcome any ideas from readers, of course.

There five potential revenue models for Service Providers: transactional, membership/subscription, lease/licesnse, business partnership, and registration.

The Transactional model refers to the pay-per-click or fee-for-use model. It is the most primitive of all the models. Once a business relationship exists between two trading partners (a service requestor and a service provider), the provider needs to determine how it will obtain agreement on terms for usage of the service. One possible method is the pay-as-you-go approach. Here the notion of a charge per transaction is possible using payment instruments like credit cards. Now it is possible for web services providers to address this revenue method via the service interface they provide, but that is a business consideration that must be made at design time. Another possible method for establishing terms for usage is that of the out-of-band relationship. Simply stated, the terms of the business relationship are agreed upon prior to use of the service. Since the technology of e-contracts is not yet mature, a dependency on an established business relationship prior to the use of the service must exist. Using this method, the Service Provider needs to just audit the usage of a service and bill for it on a periodic basis. In either case, the two trading partners must establish a mutual agreement associated with the fee for services rendered.

The Membership or Subscription model refers to the revenue model that pertains to an established user account with specific terms for usage. A user may register for usage based on period regardless of quantity or based on quantity alone. A service provider may create tiers of membership levels to allow for the targeting of specific classifications of users. Similar to the Transactional model, the service provider must decide whether its service interface will deal with the aspects of managing this revenue model or if its will manage their revenue through out-of-band relationships.

The Lease or License model refers to the revenue model that would be common amongst larger business partners who would require large volumes of usage and expect a more customized agreement. Here, a service provider may charge by volume of transactions or maybe the volume of requesting "components" (seats) within the service requestor. In this case an out-of-band relationship is a given assumption.

The Business partnership model is a new concept. Although we have yet to come across an example of this model, the dot.com hype in 2000 provided enough evidence that such a model could be required. Essentially, this model refers to the establishment of terms through out-of-band or prior usage-based system, on the bartering of services, equity, or even a percentage of gross revenue of the requestor.

The Registration model refers to a revenue model that would apply more readily to a UDDI Gateway or Green Pages business. Here the concept of collecting revenue based on a pay-to-be-seen concept is feasible. The premise stands as if a service provider wants to be published they will be willing to pay a registration fee.

Clearly, the revenue and non-revenue categories offer a significant level of justification to build a business case for the adoption of web service technologies as long as the service providers offering is a sound business concept.

Hypothetical adoption
The revenue models presented here and the justification categories are all general and applicable to any market segment. In an attempt to offer an example, I ask the reader to consider the domain of image conversions and the hypothetical business entity of Sharpe Images (SI) and its image conversion product, Convert-It. SI recently lost a bid to a large insurance company who was looking to e-source all of its image and document conversion needs. SI's product was well positioned and the most flexible amongst all the competition.   However, Convert-It was an installable product and was not available as a software service. With some foresight the business executives at SI realized that they needed to address this e-sourcing requirement if they were to win the business. They decided to host their product themselves and proposed to the customer a leasing deal based on projected volumes of transactions.  Not only did this proposal win SI the account, it provided a new delivery channel to users on a pay-as-you-go basis.

Back to top

Summary

As businesses seek to embrace the technologies of dynamic e-business, they must be able to associate their business with specific a SOA role. In most cases they will also need to provide a justification of for their adoption of the technology from a business perspective. In this article we declared five different SOA roles for a business and provided an two categories of business reasons to adopt the technology. In the next issue, I will discuss the nature of a dynamic e-business.

Resources

• Read my first column in this series, web services architect, Part 1: An introduction to dynamic e-business.
  
  
• Read the web services Architecture Overview.
  
  
• Checkout real world adoption scenarios for dynamic e-business.
  
  
• Review the Extensible Markup Language.
  
  
• Learn about the Simple Object Access Protocol.
  
  
• Learn more about Universal Description, Discovery, and Integration by visiting its homepage.
  
  
• Look to see who is part of the XML Protocol Workgroup.
  
  
• Download the IBM WSDL Toolkit from alphWorks.
  
  
• Download the IBM web Services Toolkit from alphaWorks.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Possible business roles
• Justifications for adoption
• Summary
• Resources
• About the author
• Comments