How Web Services Can Help an Enterprise CreateOvercome Competitive Pressure

Now that you have a basic understanding of how the PSA marketplace works, let's take a look at how two competitors could use Web services to expand their product sets in order to create competitive pressure and/or respond to competitive pressure. In the example illustrated in Figure 5-4, two PSA companies make use of third-party Web services application suppliers to augment and expand their respective product offerings. Step 1 shows ISV "A" adding a project management services that enables it to compete directly with ISV "B". In step 2, ISV B responds by adding a Time and Attendance service (enabling it to directly compete with ISV A) and On-line Analytical Processing (step 3)—responding to the original competitive threat and raising the bar for competition by adding a new capability to its product offering. Step 4 shows ISV A adding On-line Analytical Processing, thus creating parity between the two ISVs. But step 5 shows ISV B on the offensive, adding two new features to its offering. This competition can go on ad infinitum (or at least until there are no new Web services to be added in order to compete in the PSA marketplace).

It is very important for business executives to understand the model illustrated in Figure 5-4. Let us look at what is actually happening:

• The third-party services are application "objects" that can be wedded to, and extend the functionality of, the ISV's core products. These modules can be fluid in nature (they can come and go as intermittent services) or they can be hard-wired to the core application and made always available. The vendors choose how they will offer the new service; the customers choose vendors that provide the payment terms they desired.

• The requester application and the service application negotiate the kind of service desired, the price, and other terms and conditions—while the customer sees nothing other than a new service being provided. This negotiation implies that the ISV and the third party either reach an agreement in person on how compensation will take place for the service or put instructions for that negotiation in the WSDL code used by each software package, and the two software products negotiate the terms and conditions for service provisioning.

By using this Web services model, ISVs (or end- user enterprises) can realize two distinct benefits: (1) they can assemble applications quickly in order to respond to competitive pressure or to take competitive advantage; and (2) the programmatic negotiation of business terms for services can greatly reduce administrative costs between software suppliers—reducing people and administrative overhead related to Web services provisioning. Accordingly , ISVs and enterprises can save money by reducing people costs related to contract negotiation and payment structuring/monitoring.

The argument that Web services can help an organization create or overcome competitive pressure rests on the fact that Web services enable competitors to "assemble" applications in new and different ways. This assemblage model enables them to quickly and flexibly create new go-to -market applications by using application "objects" to assemble "compound" applications.

Not So Fast…

Like previous examples, this ISV example relies on the availability of a UDDI directory to find Web services. And it relies on a fairly sophisticated use of WSDL to negotiate the business terms and compensation method to provide the Web service to the original requester. As part of this negotiation, micro-payments (small payments for services rendered) may apply. Finally, because these are "run-the-company" vital applications, neither the service providers nor their customers can afford to take chances with the reliability or security of the transactions that take place between requester and service applications.

The above scenario could work if the Web services described were structured so that they didn't make strict use of the official Web services protocols or methods —for instance,

• If the ISV and the third-party Web service solutions provider were to hard-code their application locations (then they could work around having to use UDDI).

• If people were to actually get involved in structuring the business arrangements, rather than relying on WSDL to do so (Programs could be written to track the use of the service as well as to bill the requester accordingly).

• If security were augmented by a "plug-in" security package, such as industry-standard Kerberos or Public Key Infrastructure security methods.

• If a reliable network and system infrastructure could be constructed (for instance, a virtual private network to ensure reliable and secure transactions).

As you can see from this example, Web services hold great potential to automate program-to-program communications, but several shortcomings must be overcome. Note that for every shortcoming there is a potential work-around that would allow an enterprise or ISV to use Web services today to build such solutions. These work-arounds tend to be manual in nature. Over time, though, Web services standards will mature, and all of the services described above can be made automatic.