2.6 Establishing a Business Case

2.6.1 Overview

This section depicts two scenarios where Web Services technology may be a good fit. The first scenario is a membership award program, which is a common customer loyalty program, and provides a seamless integration between a credit-card bonus point system and business partners for redemption, account balance, activity tracking, and cross-selling . The second scenario is a single payment gateway that enables corporate banking customers to utilize payment services from multiple banks.

To establish a business case for Web Services implementation, some common characteristics and prerequisites of the candidates are discussed, followed by the selection criteria of a pilot project, business benefits, and some risk analysis. Typically, many corporations would start a pilot program (or Proof of Concept) to justify the business case and to mitigate the technology risks. A sample Return On Investment (ROI) model, based on the pilot scenario, is provided in the business case.

2.6.2 Candidate Characteristics

The target candidate for Web Services implementation is one where we might de-compose existing monolithic services into more atomic business services. By exposing these atomic business services, we should then aggregate business information from various sources with a business process engine into meaningful business information and customer-oriented services. Ideally, the target candidate should have the following characteristics:

Trading Partners. There may be more than one external trading partner involved. There is also a need to interoperate with back-end legacy systems and heterogeneous platforms. Otherwise, the low complexity does not justify using Web Services technology.

Reusability. The reusability of business services and customer information should be high. If the solution is very unique and cannot be reusable anywhere , then there is no business case.

Branding. Some people believe integrating two different services may lose the original branding, as either or both parties may need to compromise in some areas to accommodate technical constraints. While keeping a consistent branding, we need to provide flexibility (such as providing personalized or customized services for managed services), especially for white labeling services. The integration technology used must be flexible enough to accommodate the different constraints of the back-end services.

Technology Constraints. Back-end business services or application functionality are unlikely to be re-engineered. Thus, the technology used should coexist and leverage existing back-end services and should not require a rewrite or significant modification.

Limited Delivery Time Window. There should be a short and limited time window to deliver the system. Thus, the technology used must be easy and quick to deploy. The integration framework needs to support different protocols and message formats, including a variety of industry standards and platforms.

2.6.3 Membership Award Example

Membership award is a common customer loyalty program widely used in credit-card services. Customers who register with the credit card company Web site can redeem bonus points in exchange for gifts from the membership award site. The objective is to provide a seamless integration for bonus point redemption and partner services. Today, there is no integration among the bonus point system, the credit card company's call center, or the trading partners' system. Membership award redemption requests are usually done via fax, and the award details are often re-entered into the back-end system. Membership award information is often re-entered into the service provider's back-end system and the credit card company's call center system. Some service providers may have electronic file transfer between the credit card company and their back-end system. However, there are also integration and interoperability issues with the service providers' ERP and legacy systems, because each system requires specific data formats and different protocols for data exchange. If there are numerous service providers, the integration effort for the bonus point system would have to be substantial in order to handle multiple data formats and protocols.

In Figure 2-2, the point of sales (POS) terminal residing in the merchant's store connects to a credit card gateway, which will dial up to the Processor (such as the acquirer bank that offers merchant accounts) to request authorization and debit processing. Upon successful authentication and authorization, the Processor will process the card payment via the payment gateway with the credit card company. The current business processes do not allow any Point of Sales information (such as bonus points gained from the sales) to be captured automatically for the bonus point system. In other words, Customer Service Agents or Operations personnel from the credit card company need to re-enter the payment transaction details into their bonus point system in order to process the reward redemption requests. Nor can the Business Intelligence applications retrieve the membership award activities for the purpose of data mining or direct marketing.

Figure 2-2. Membership Award Example

Web Services technology can be used here to wrap the Point of Sales payment functionality as a reusable business service. This enables the POS or merchandise information (such as payment transactions) to be captured in SOAP messages and reused by the bonus point system. The credit card company can also make available partial contents of the customer transactions with other business service providers who need them to process the award redemption request. This not only reduces paper work, it can also expedite the processing time of the reward redemption.

The bonus point system can also make use of Web Services technology to integrate seamlessly with back-end ERP or legacy systems or to exchange membership award information with service providers via SOAP messages. This allows a flexible and low-cost means of Business-to-Business integration, without creating proprietary and dedicated interfaces.

In addition, with the use of a private UDDI service registry, the credit card company can store the service information of different service providers to enable dynamic service look-up of various membership award services. Customer and business information will then become timely , and thus the award redemption service becomes a good user experience. Besides, consumers, merchants , or service providers participating in the membership award service (or affinity program) need to preregister first in the private UDDI service registry with the credit card company. They are authenticated each time before they can use the membership award service. This registration process can facilitate better account and partner management with security and foster the growth of the user community.

Figure 2-3 depicts five business scenarios or use cases for the membership award processes. Before a credit card holder can enjoy his membership award services, he needs to register with the credit card company's call center (or Web site.) He also needs to administer his membership details.

Figure 2-3. Membership Award Use Cases

Upon successful membership registration, the credit card holder, who has just made a POS purchase using his credit card, can go to the credit card company's Web site to inquire about his membership award status. If he has enough bonus points to redeem some merchandise, he would like to make a redemption request with a service provider. Service providers will then process the redemption requests, arrange merchandise delivery to the credit card holder, and return membership award status to the credit card company's call center (or the Processor, if they share the same affinity program) so that they can update their bonus point system.

Figure 2-4 shows similar process details in the form of a sequence diagram. The credit card holder self-registers for the membership award program with the credit card company's call center. This is a typical online service, or a self-registration service exposed as a Web Service from the call center system.

Figure 2-4. Membership Award Sequence Diagram

Upon successful registration, the credit card holder can administer changes to his personal details, such as address changes. The call center system confirms the update with the credit card holder. Similarly, the credit card holder can withdraw from the membership award program online. The membership administration or update can be a typical online functionality from the call center system, or Web Services provided by the call center system (if the call center system is provided by an Application Service Provider).

If the credit card holder inquires about the current status of membership awards (such as the bonus point balance), the call center system can generate an inquiry request in a SOAP message, where the call center system can aggregate membership award information in real-time from different service providers using Web Services.

Similarly, if the credit card holder wants to redeem an award with his bonus points, the call center system can generate a redeem award request and send it to the relevant service provider for award redemption. Upon completion of the award redemption, service providers can send SOAP messages to the call center system and/or the Processor to update the membership award activities. The benefit of using Web Services technology here is the ease of integration and interoperability with multiple service providers.

The benefit of using XML Web Services is to enable interoperability and integration among Processors (in this case, banks), trading partners, and credit card company with reusable data over the existing infrastructure. It also reuses the existing Point of Sales (POS) and merchandise information (thus no duplicate re-entry) for bonus point processing, business intelligence, and award redemption. There is seamless integration with trading partners' legacy and ERP systems. It also enables flexible account and partner service management.

2.6.4 Payment Services Example

Today, buyers have many Electronic Banking systems, but they cannot use one single front-end to settle payments with multiple banks. These Electronic Banking systems also support cross-border payment. Besides, there is no agreeable data format for B2B Exchanges, buyers , suppliers, banks, or credit card companies to share and reuse.

The objective is to provide a single payment gateway to settle cross-border payments with multiple banks. XML Web Services technology enables multiple banks and credit card companies to reuse the same purchase order contents. It also enables interoperability and integration between banks and credit card companies with reusable data over existing infrastructure.

Today, most Business-to-Business transactions are exchanged in physical documents. A payment (or Documentary Credit) can be issued only if there is a physical purchase order document that is backed up by other shipping documents (showing the physical delivery and order fulfillment). Nowadays, Business-to-Business payment can be handled by credit card services such as TradeCard and Visa Commerce. Payment can be released after there is a physical delivery of goods and services. However, it is labor intensive , error prone, and may impose a time delay. In addition, if there is any exception that impacts the shipment delivery or payment, there is no proactive measure such as alerts to notify the buyer, the supplier, or the bank. Some buyers or suppliers may use proprietary electronic media to exchange trade and shipping documents, but each party may have a different data format or protocol that makes the integration and interoperability difficult. Some buyers or suppliers use Electronic Data Interchange (EDI) to exchange trading documents as well. But the operating cost is fairly high, and it requires both ends to use the same EDI standards and version numbers .

Figure 2-5 depicts a complex business scenario for Business-to-Business payment services. An international buyer has a supply chain management system hosted in a data center managed by an outsourcing (or out-tasked) service provider. The buyer is making online purchases via Trading Exchange A and Trading Exchange B with suppliers from different parts of the world. Each Trading Exchange has many service providers (or suppliers) and uses different banks to settle payment upon delivery of goods to the buyers. If credit cards (in this case, B2B corporate cards, not consumer credit cards) are used to purchase merchandise, the buyer's bank (either Bank A or Bank B) will clear payment of the merchandise with the credit card company.

Figure 2-5. Payment Services

Web Services technology can play a key role in facilitating B2B payment services. In this business scenario, the Trading Exchange may have a UDDI or ebXML service registry that stores service provider information, their merchandise, and their corresponding business services. Buyers can browse the merchandise from the service registry, and make a purchase by invoking an online order request service. This allows a SOAP call to the remote order management system to confirm a trade order or to decline the order if it is out of stock. Upon completion of order execution, the service provider's system may return an order acknowledgement or order delivery in a SOAP message to the buyer's procurement system.

Upon delivery of merchandise, the buyer's back office system (finance module) can settle the payment using a B2B credit card service. It will also generate a payment instruction in a SOAP message to the credit card issuer bank, which will then clear the payment with the credit card company. As service providers may be using different messaging protocols and data formats, they may use SOAP or ebXML messaging to exchange trading documents or payment instructions. The benefit of using SOAP or ebXML messaging is that they are able to integrate with the buyer's or service providers' back-end systems. Trading documents encapsulated in XML structure within a SOAP message can be easily transcoded into a format that can be understood by the back-end ERP or legacy systems. Thus, the integration effort can be lower and reusable for other Trading Exchanges. It does not require all service providers to use the same vendor solution or to adopt a proprietary data format.

Figure 2-6 depicts five business scenarios or use cases for the payment services. Upon browsing the service registry (aka online catalog), the buyer can select the merchandise and issue an online purchase order. In this example, the buyer uses a B2B payment service from the credit card company to place an online purchase order. Upon delivery of merchandise, the buyer can issue payment instructions to the buyer's bank (Bank A). The buyer's bank will then authorize the payment and advise the supplier's bank (Bank B). Bank B will then notify the supplier about the payment instructions. Finally, the credit card company will act as a clearing agent for Bank A and Bank B.

Figure 2-6. Payment Services Use Cases

Figure 2-7 shows similar process details in the form of a sequence diagram. The buyer issues an electronic purchase order to the supplier in a SOAP message and also copies the purchase order to the buyer's bank for reference. Upon successful delivery of merchandise, the buyer would like to make payment by issuing payment instructions to the buyer's bank. The buyer's bank in turn relays the payment instructions to the supplier's bank in a SOAP message. Upon receipt of the payment instructions, the buyer's bank will authorize payment with the credit card company, because the buyer is using B2B payment service from the credit card company. The supplier's bank will also notify the supplier about the receipt of payment instructions from the buyer.

Figure 2-7. Payment Services Sequence Diagram

Then the buyer's bank will initiate clearing the payment with the credit card company and the supplier's bank. Upon completion of clearing the payment, both banks will update the payment status and notify their corresponding banking customers (the buyer and the supplier, respectively). The notification may be in the form of alerts sent to their email addresses or mobile devices in SOAP messages.

The benefit of using Web Services is to enable high-value cross-border payment using a credit card. As a result, banks can enjoy seamless integration with buyers and suppliers' back office systems using reusable system components over the existing infrastructure.

2.6.5 Business Case Prerequisites

To establish a business case for Web Services implementation, there must be a clearly defined business problem. A Web Services initiative is usually driven by addressing specific business problems or pain points, such as cost reduction or integration issues. Typically, a business case will include a pilot or a small Proof of Concept to illustrate the cost-benefits and to mitigate technology risks. The pilot project can also act as a "lessons learned" experiment before Web Services becomes a technology strategy.

Executive sponsorship is mandatory, even though this is a small Proof of Concept. Besides, the Web Services candidate should be scoped with a target delivery time frame of not more than six months. There should be a ready-to-go task force. The internal project team should be equipped with Web Services technology training, awareness of the implementation process, or case studies.

2.6.6 Selection Criteria of a Pilot Project

The above two scenarios are examples of potential pilot projects that may be selected for the business case. There are five key factors when determining whether the business scenario is suitable as a pilot project:

Business Value. The target pilot project needs to have considerable (non-trivial) business value or have a positive impact to the company's bottom-line cost or revenue. Some pain points can be chosen as the basis for a pilot project if Web Services technology can address them in short-to-medium- term . For instance, a company is currently receiving customer information from business partners via backup tapes or file transfer. This may be labor intensive and costly, especially when there are large numbers of partners. By replacing the tape media or file transfer with Web Services technology, the company can improve timeliness and reliability of data, which can be translated into quantifiable business value, such as cost saving.

Thought Leadership. The vendor (or architects within the company) should demonstrate thought leadership in Web Services areas. The architects or resources from the vendor (or within the company) should also exhibit some working knowledge or perhaps subject matter expertise in the vertical solution (for example, financial services).

Choice of Solution Options. From an IT investment perspective, it is too risky to bet on a single vendor product. The software vendor solution set should interoperate with other Web Services products.

Process. A Web Services architecture framework, methodology, or development tool should be available and adapted , supplemented by a sensitive development methodology. Implementation is often made successful with appropriate, though not excessive, processes.

Service Support. Service support from the vendor should be available locally. For example, Asian companies find that U.S.-centric vendors lack local service support, and they often need to pay expensive overseas trips for expertise.

2.6.7 Business Case Risk Analysis

Business Risks. Implementing a business service with Web Services in a narrow time window (for example, six weeks) may be too risky if the company does not have prior experience in Web Services. For the first time pilot, it is more pragmatic to implement Web Services for a longer time window (for example, at least four months).

If Web Services technology is used to implement new business models, the business risk is increased two-fold or more. In case of failure, it is difficult to tell if the business model or the technology implementation work. Thus, it is useful to address one area at a time (for example, use a proven business model with Web Services).

Technology Risks. Web Services standards are changing, and it may be too risky to bet on an early release, especially when the company is large and slow to implement technology changes. For example, Apache SOAP evolved from 2.0 to Apache Axis within a year. It is evolving so fast that customers with a slow implementation schedule may begin with Apache SOAP 1.1 implementation for a year, but by the time the system is deployed, the market is ready for Apache Axis.

To mitigate the risk, customers may partner with a Web Services thought leader vendor who can assure backward compatibility and agility for new upgrades.

Implementation Risks. Human resources with a good understanding of Web Services technology and large-scale integration experience are hard to find. One of the best alternatives is for the customer project team to collaborate with Web Services consultants so that they can be mentored.

Risk Mitigation. Common technology implementation risks are point-to-point or proprietary interfaces (for example, EAI integration is proprietary and often point-to-point), inconsistent Quality of Services (for example, scalability, support, and maintainability for screen-scraping-based solutions), and the security risks associated with tactical screen-scraping or point-to-point interfaces.

To mitigate these implementation risks, Web Services (using asynchronous messaging) provide reusable interfaces using open standards, not point-to-point. Web Services solutions can be easily scalable and available (refer to Web Services design patterns in Chapter 4 Web Services Architecture and Best Practices). Besides, Web Services-enabled legacy systems and mainframes are maintained "as-is" (run-time bindings for XML-RPC), and no system infrastructure needs to be changed. There is also an established security framework to address different levels of security threats.

2.6.8 Benefits of Using Web Services

There are three major benefits of implementing Web Services technology:

Interoperability. Web Services technology is a low-cost technology tool to meet time-to-market requirements. It provides better integration and interoperability for cross-platform systems and legacy back office applications. In contrast, EAI is usually proprietary, and does not easily interoperate with another EAI if they are from different vendors.

Reusability and Maintainability. Business services can be exposed as Web Services. These become highly reusable, and are platform- and vendor- independent. The service calls and interfaces are also easy to maintain. In contrast, EAI products and screen-scraping technology are usually platform- and vendor-dependent .

ROI. Web Services technology can be deployed within weeks or months, with lower cost of integration and maintenance. Return on immediate cost savings can be measured.

2.6.9 Return on Investment Model

There are a few approaches to measure the ROI of adopting and implementing Web Services:

Sunk Cost. Implementing new technology may incur sunk cost, which may not generate ROI. You may like to treat such investment as part of your infrastructure cost. In such a case, this includes investment cost for training and technology skill transfer. With appropriate senior management support, the sunk cost does not expect any ROI or cost savings. However, this approach may be difficult in the current economic atmosphere.

Soft ROI. This denotes a nonquantitative analysis of different investment options, and compares the business benefits. Management needs to be convinced of the vision and its associated long-term benefits.

Product ROI. Based on a specific scenario, you may want to identify the manual processing cost, internal implementation cost, legacy system marginal/upgrade cost, and Web Services implementation cost. In such a scenario, management may expect you to compare this with other alternatives such as using screen scraping or EAI technology for integration.

Soft ROI Example

Assumptions. Table 2-1 depicts a comparison of implementing the Membership Award scenario using Web Services, a proprietary screen scraping, and EAI technology. There are certain assumptions made for each technology option in the table.

Table 2-1. List of Assumptions While Comparing the Return on Investment Using Web Services, Screen Scraping, and EAI

	Web Services	Proprietary Screen Scraping	EAI
Fixed cost (for example, base software tool cost)	US$50,000	US$100,000	US$300,000
Number of screens/functional units	1 Web Services call	200 screens	5 adapters are needed
Unit cost for screen scraping a screen	US$80,000	US$56.25/day	US$24,000
Reusability for other similar services	Yes	No Need customization	Yes Need customization
Subtotal (development cost per partner per site)	US$130,000	US$111,250	US$420,000
Cost for two partners/sites	US$130,000	US$222,500	US$550,000

Figure 2-8 illustrates the development/implementation cost and deployment time frame for each technology option. Web Services technology is relatively more scalable and less costly (development/implementation cost), and has a shorter deployment time window (deployment time frame).

Figure 2-8. Soft ROI

Product ROI Example

Scenario. This sample scenario assumes we are implementing the Membership Award program using Web Services technology. We are comparing using Web Services technology, home-grown proprietary API, and EAI approaches.

Assumptions. There is no major architecture change if using Web Services (for example, there is no need to install an additional hardware component or upgrade legacy systems). Some basic training or a technology awareness workshop of Web Services is conducted . Two developers and one project manager are the available resources. Additional software licenses for EAI need to be purchased for the EAI option. The data center cost is about 12 percent of the hardware and software cost per year plus service staff cost.

Implication. The total cost will multiply if more partners are involved and the integration framework must be cloned or replicated. Web Services will have a higher reusability and lower deployment cost.

Table 2-2 shows an example of the case. In this Membership Award example, different implementation cost components using Web Services, proprietary API, and EAI technologies are estimated and compared. The Web Services solution approach has a lower total cost. It has a lower development cost because the integration effort is smaller using open standards, and the reusability of existing infrastructure and functionality is high.

Table 2-2. Comparing Implementation Cost by Web Services, Screen Scraping, and EAI

	Web Services	Proprietary API	EAI
Baseline cost. Manual Processing Cost if no enhancement with these technology options	US$1,000,000 p.a. (service running cost)	US$1,000,000 p.a.	US$1,000,000 p.a.
Infrastructural cost (for example, hardware and software upgrade)	US$50,000	US$50,000	US$300,000 (EAI licenses)
Internal development cost	US$80,000 (4 man-months)	US$160,000 (8 man-months)	US$120,000 (6 man-months)
Internal implementation cost	US$40,000	US$80,000	US$40,000
Professional services, such as mentoring or consultancy services	US$40,000 (3 man-weeks)	N/A	US$27,000 (2 man-weeks)
Managed services, such as service support cost, outsourced cost, and data center processing cost (if not hosted in-house)	US$240,000 p.a. (support staff) US$100,000 p.a. (data center/support services)	US$240,000 p.a. (support staff) US$200,000 p.a. (data center/ support services)	US$240,000 p.a. (support staff) US$500,000 p.a. (data center/support services)
Other costs, such as training	US$100,000 training	N/A	US$100,000 training
Subtotal (first year)	US$350,000	US$530,000	US$817,000