Users who expect web services to deliver joined-up computing must beware the vested interests of vendors and of their own in-house IT teams.
| ||express delivery|
| print comment|
|Vendor-centric web services strategies may not meet the needs of enterprises who run a mix of packaged software suites:|
- Business users expect single sign-on access to functions and data
- Application specialists prefer to work in their familiar environments
- Each major vendor has a different approach to web services integration
- SAP NetWeaver, for example, is focussed on leveraging R/3
- Users need solutions that make the most of multiple platforms
Glossary terms: web services, integration, packaged software, composite application, ERP, lookup tool
Corporations with multiple enterprise applications not only have to reconcile the conflicting technology approaches taken by the leading vendors. They also have to overcome the ingrained habits of IT specialists whose skills and experience have centered on dealing with discrete, homogenous application platforms.
SAIC, a Fortune 500 research and engineering company based in San Diego, California, recently experienced the tensions that can result when user expectations come face-to-face with ingrained IT practices.
The corporation's internal communications function had gained senior management buy-in for a project to build an employee portal using web services. The initiative aimed to give employees access to a number of 'self-service' applications, ranging across a number of HR-related functions such as changing emergency contact details, providing details of their skills and competencies, enrolling in benefits through a third party service provider, and allowing them to exercise options and trade the privately-held company's stock.
One of SAIC's key requirements was that employees would gain access to all the capabilities of the portal with just one log-in, regardless of which individual application was providing the data behind the scenes. "Our employees don't really care where the data lives if they go online, all they want to do is perform a function," says Ron Arnold, VP of internal communications.
But this requirement meant that Arnold ran into problems with some members of the IT department as soon as the project got under way. "Eight or nine months ago we had a really difficult time," he says. "We had big arguments about what we could do and should do."
Some IT specialists argued that the user interfaces in its back-end PeopleSoft and SAP applications offered sufficient access in their own right and didn't see the benefit of building a separate, all-in-one access point. Arnold disagreed.
"My business is customer experience," he says. "People who are immersed in code see things differently." Fortunately, Arnold was able to call on assistance from web services vendor Actional, whose technology provided much of the web services infrastructure, to help work through all the issues. "It was a very painful process they went above and beyond the call for us," he says.
SAIC's experience is typical of the kind of culture conflict that's likely to become increasingly common as organizations use web services to access multiple applications. While some IT specialists relish the challenges of cross-platform integration, others are deterred because, once they venture beyond the familiar surroundings of their preferred application environment, they find that vendors' approaches to web services differ markedly.
Each of the leading vendors are at different stages of evolution in their web services strategy, explains Bill Robins, partner in San Francisco-based consulting firm The Stencil Group, and each is following a different roadmap. SAP's approach is heavily influenced by infrastructure concerns, he says, while PeopleSoft is more focused on integration solutions (it actually talks about "redefining the economics" of integration). Siebel has its sights set on business process solutions, while Oracle, he contends, still has a database-centric view of the world.
At the same time, vendors have launched their development programs with a steady eye on their existing customer base. Customer demand for web services is still relatively limited today, and when they do begin to roll out web services strategies, vendors expect users will want to protect their investments in their existing applications. So each vendor's web services program is tailored to the specifics of its own application environment. With web services standards still to be finalized in many areas, there are many gaps that vendors tend to fill with their own proprietary technology.
Where customers operate a one-stop shop at least for their core applications this doesn't necessarily pose a problem, since they will usually follow their chosen vendor's lead. But few organizations conform to this idealized profile. Most run a heterogeneous environment, and many of them will be struggling to decide which course to follow. Do they throw in their lot with one enterprise vendors' strategy over every other, and if so which one is going to be best suited for their particular needs? Do they rely instead on the independent expertise of an integration specialist, or should they hook up with a dedicated third party web services provider?
The Stencil Group is currently researching a "decision-tree" to help these users decide on the best route forward, taking into account a wide range of factors including the volume of throughput, the investment dollars available and the customer's willingness to train developers or bring in third-party expertise. But while this kind of tool will help customers find a way through a wide array of different factors, the complexity is not going to go away overnight. "I don't think there's a simple answer," concedes Robins.
Many IT departments will be counting on SAP, as market leader, to come up with a solution they can confidently embrace even though SAP boss Henning Kagermann has recently been quoted as saying web services are "not proven" so far. The company mapped out its strategy in its Enterprise Services Architecture, unveiled at the beginning of 2003, built around its NetWeaver application and integration platform.
To understand how the new strategy works, it's best to view the company's products as a four-layer stack, explains Ori Inbar, vice president of product marketing for SAP NetWeaver. At the bottom is the core R/3 infrastructure, designed to work with multiple hardware platforms. The next layer is NetWeaver, which incorporates existing technology such as SAP's Enterprise Portal and Business Intelligence products, along with its Integration Broker product released in June 2002.
NetWeaver provides a common integration platform for two types of application in the third layer. One set is called Best Practices, which incorporates the vendor's core mySAP business applications, such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). The other, called Next Practices, includes xApps, a series of cross-functional composite applications targeted at specific business processes. Both types of applications are available to the fourth, top layer, which comprises packaged solutions.
SAP's web services strategy is most visible at the third, application-level layer, where the core SAP product sets, including ERP, CRM and Supply Chain Management, are gradually being SOAP-enabled, although today they remain rooted in SAP's existing technologies.
Users also have the option of deploying NetWeaver on top of SAP R/3 to expose the underlying processes as web services, again without the need for recoding. This is the principle underpinning xApps, two of which have so far been released. To help bring more xApps on stream, SAP has given a limited number of developers the first version of its Composite Applications Framework, the "factory" for creating xApps. The framework gives developers one interface and a unified view into all the tools in the NetWeaver stack, such as the Portal Developer kit.
These development efforts all appear laudably comprehensive, but while they ease integration with other applications, the main emphasis is on leveraging existing investments in SAP's proprietary BAPI technology. SAP remains a "very complex BAPI-centric product", points out Stencil Group's Robins. "If you've gone hook, line and sinker and got SAP on your shop floor, it's fine." But linking to other systems, either internally or beyond the corporate firewall, will cause headaches, he says. "If you have an extended ecosystem of partners that you need to participate in on a day-to-day basis, not having open systems is a real problem."
That said, Robins points out that the flipside is that customers aren't demanding that SAP rebuild its products from scratch either. Naturally, they want to preserve their existing investment not only in SAP, but also in applications from other vendors.
Each of those vendors is counting on its web services strategy at least to maintain the customer's commitment to its application, and at best give it an opportunity to extend its influence by becoming the customer's chosen integration platform. But while this approach appeals to the IT specialists who work most closely with them, vendors will find it harder to win over the wider mass of business users, who have no particular loyalty to one vendor over another. SAIC's story suggests that, rather than becoming embroiled in inter-vendor rivalry, users may instead turn to neutral third-party solutions to achieve the cross-platform functionality they demand.
More on this topic
Just how easy is it to snap on SAP's 'snap-on' xApps? ...
Packaged enterprise software vendors have begun to web service enable their products ...