How Web Services Can Help Create a New Revenue Stream from Existing Intellectual Property

Imagine the following scenario:

Your enterprise specializes in providing financial services for its customers. Your company has written six very distinct financial analysis and measurement, portfolio management, asset tracking, trend calculation software, and other financial service packages. Your company believes that three of these software solutions are strategic and should not be shared. By the same token, the other three offer strong value to your customers and other financial services firms would be happy to pay your company for the use of them to improve their respective services offerings to their clients.

In this scenario your company has intellectual assets in the form of software. Some of those assets are strategic, while others could be remarketed to competitors or other organizations, thus augmenting their respective application portfolios. Instead of just leaving them locked behind your organization's closed doors, modifying those intellectual assets to be Web service compliant might open up a new source of revenue without creating any strategic or competitive threats while incurring only small costs for the redesign of the product (into a Web services offering) and small long-term costs for the management and administration of the product. Voila the use of Web services architecture has enabled your company to take advantage of underutilized intellectual capital to realize an instant revenue increase without tremendous capital or human resource investment!

Not So Fast…

Although this scenario is entirely possible and can be achieved using Web services, you'll need to ask yourself the following questions:

1. How are my competitors and potential users going to find out about the availability of my newly Web-services-enabled services?

2. Will my competitors require that additional work be done to integrate the service being provided with their own internal applications portfolio?

3. How will my competitors feel about providing possibly sensitive account information to my Web service so that my applications can provide some sort of transactional or computational service for the requester application?

As in previous examples, the lack of a UDDI directory makes it difficult for Web services to be found. This example also illustrates new problems, such as how the sharing of account sensitive information can be securely accomplished.

Again, the lack of maturity in Web services standards prevents this kind of scenario from being accomplished in an automated fashion. Yet, it is still possible to architect such a solution by hard-coding applications together and rolling in add-on secure messaging facilities.