Opinion: Why Web Services Matter

Share this content

Web services offer enormous potential for the CRM industry, argues Soren Pallesen, Head of Product Marketing, E.piphany EMEA

Web services are garnering tremendous attention in the enterprise application industry, but as with all hot new technologies, it’s difficult to separate the hype from reality.

The truth is that Web services really can provide exceptional value to the CRM buyer; the challenge is to understand how this technical innovation drives business value. Moreover, buyers need to understand which vendors can fully exploit the promise of Web services, and which are too entrenched in legacy architectures to fully incorporate modern technologies.

“Web services” is a general term for any application that provides an application service to other applications by exposing its functionality through common Internet standards. An example might include Microsoft’s Map Point, which can be accessed by Web sites and applications to provide maps and driving directions; E.piphany’s sales automation solutions integrate to Map Point to provide sales people with directions tied directly to a prospect’s address in the application.

Web services is also used to describe those Internet standards used to integrate a Web service with the applications requesting its service. The most promising and widely embraced of these standards are the Simple Object Access Protocol (SOAP), which enables Web services by passing a message (i.e. a request for a service or a fulfillment of that request) written in Extensible Mark-up Language (XML) over the Internet-standard Hyper Text Transfer Protocol (HTTP). To simplify, XML is analogous to a letter, while HTTP is the envelope; SOAP is the combination of the two.

So what’s so special about this simple idea of enabling applications to communicate over the Internet using common standards? What’s special is the simplicity – for the first time, the information technology industry is aligned around a common set of standards which eliminate the traditional complexity of integrating applications built around proprietary protocols.

Traditional rivals are all supporting a common set of standards. A sign of this convergence came in February 2002, when IBM and Microsoft, along with Accenture, BEA Systems, Fujitsu, Intel, Oracle and Sun Microsystems, formed the Web Services Interoperability Organization (WS-I) to ensure the compatibility of Web services developed by different application vendors. Customers will benefit from this cooperation as the integration of their applications and those of their customers and partners is vastly simplified.

Now that we have defined Web services, we need to understand the role they play in CRM. Generally, we have identified three major areas where Web services can be applied to create value in CRM:
- Integrating with customers and partners;
- Integrating internal applications; and,
- Enabling a new class of component-based applications.

Using Web services to integrate systems between companies, their customers and their partners enables a wide range of new business processes and efficiencies. For example, a retail operation might integrate their inventory management application to the sales automation systems of their suppliers.

That way, as inventories become too low, the supplier knows immediately that more products must be manufactured and shipped to the retailer. Further expanding on this model, the manufacturer could integrate their applications to their suppliers’ systems to automatically order more raw materials for the manufacturing process. While this application of Web services is compelling, inter-company Web services integration will most likely develop slowly amongst more pragmatic companies.

Web services can also be used to integrate enterprise applications internally within an organisation. For example, a company might implement a new contact centre application, but still manage orders in a legacy mainframe system. By exposing the mainframe’s order management capabilities as a Web service, the contact centre agent can place an order or request an order’s status without having to access the mainframe directly. This type of integration was traditionally handled through much more complex and proprietary integration technologies and integration costs often skyrocketed as companies struggled to integrate disparate systems from different vendors.

With application vendors all supporting common Web services standards, companies will find it far easier and less expensive to integrate enterprise applications. Component-based applications represent a powerful enterprise application architecture whereby applications consist of numerous components, rather than a single monolithic code base.

“Component” is an industry-standard term for a small unit of software that performs a specific function, but can be linked to other components to create an enterprise application. Configuring and implementing component-based applications is easier, as component services can be assembled like Lego blocks to meet specific customer requirements. Additionally, customers can roll out functionality incrementally rather than implement one large, risky project.

Similarly, upgrades can be done much more selectively as individual components can be upgraded independently of the rest of the application.
Web services technologies play an important role in enabling component-based applications. With Web services, components can be implemented as Web services and communicate through standards such as SOAP, or other standards such as Java RMI.

This Web services assembly of applications becomes especially interesting when third party components are bundled into a component-based application. For example, a sales automation application could be implemented as a series of components from a CRM vendor, but incorporate a product pricing Web service custom-built by a third party vendor or integrator. In this model, customers benefit from the ability to mix and match component Web services from various vendors and custom projects.

While Web services have enabled substantial progress in integrating legacy systems into modern CRM strategies, many legacy CRM architectures will preclude vendors from delivering the true value of Web services to their customers. The challenge for many older vendors with legacy architectures is that their applications exist as a monolithic code base, rather than as components.

Accordingly, it is difficult for them to expose granular functions as Web services, or incorporate other Web services into their application processes. This limitation will be most problematic in the third area of Web services adoption we discussed – component-based applications. As a result, many vendors with older architectures will simply support limited Web services integration.

So how can you tell if your vendor is ready to fully deliver on the promise of Web services? Start by asking some important questions:
* Does the vendor support standards such as XML/SOAP?
* Are the vendor’s applications built as interchangeable components or a monolithic code base?
* Can granular functional components form the vendor be exposed through Web services?
* Are the vendors applications written in a modern code base that is well suited for Web services integration (e.g. Java or .Net from Microsoft)?
* Can the vendor provide detailed examples of how its functionality leverages Web services at a very granular level?

Web Services hold tremendous promise for the CRM industry. Customers stand to benefit from new business processes with customers and partners, easier internal application integration, and the dramatic benefits of component-based applications. As industry giants like IBM, Microsoft, Sun and BEA continue to promote common Web services standards, the success of customers leveraging Web services becomes even more assured. At the same time, customers adopting Web services should be certain to assess their vendor’s ability to adequately support Web services.


Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.