Larry Ellison, chief executive of Oracle, the world’s second largest software company, is clearly unsettled. The cause of his concern? The amount of interest that web services – the latest and potentially revolutionary approach to application development and deployment – is generating among influential technology decision-makers. So far, the notoriously outspoken Ellison has been very careful neither to totally dismiss nor entirely endorse the web services proposition.
Web services, according to Ellison’s cautious public statements, is “a very important new technology”. Oracle, he says, is “fully behind web services”. In the same breath, he warns that customers should not be misled: “You can only understand [the current importance of] web services if you’ve worked in the women’s clothing industry.” In other words, web services is currently fashionable but vastly over-hyped and cannot possibly deliver on the promises being made for it by its more enthusiastic proponents.
But if Oracle’s leader has as yet failed to give his whole-hearted public support to web services, his company – along with the other leading suppliers of enterprise applications – is nonetheless channeling a considerable chunk of its massive R&D resources into exploring – and exploiting – the technology.
The reason for Ellison’s ambivalence is transparent: for suppliers of enterprise resource planning (ERP) software, such as Oracle, PeopleSoft, JD Edwards and SAP, web services poses a substantial threat. These suppliers have worked hard for years to convince customers that they can cut costs and boost the efficiency of their businesses by investing in a tightly integrated, end-to-end ERP ‘backbone’ that automates the vast majority of their business processes – a goal that can only be achieved by sourcing the ERP software exclusively from one supplier.
The alternative to this approach, integrating multiple, so-called ‘best of breed’ applications from specialist software vendors using a plethora of middleware tools, is notoriously time-consuming, complex and costly – so a pre-integrated ERP package that creates a single version of internal information is an attractive proposition to many organisations.
And many have been convinced, investing millions in an ERP backbone to run their financials, manufacturing, logistics, human resources, and other applications, from the mid-1990s onwards. But in reality, even companies with a largescale ERP implementation under their belts have still been forced to buy additional software from smaller suppliers in areas such as supply chain management and customer relationship management, and then integrate these with the ERP foundation, either by using tools from enterprise application integration (EAI) specialists such as Tibco and SeeBeyond, or hand-coding their own links.
The picture is not pretty. According to figures from IT market research company Meta Group, the world’s top 2000 companies, on average, rely on 49 core business applications and spend up to 33% of the IT budget getting them to ‘talk’ to each other.
That is where web services could have the greatest impact. By forcing developers to use fixed standards for communication between application objects, web services promises a low-cost answer to that integration headache. In doing so, it threatens to undermine the ‘single applications architecture from a single supplier’ argument completely.
As their customers have come to understand that potential, ERP companies have been forced to react, in many cases stepping back from that classic marketing arguement and demonstrating that they embrace web services – albeit tentatively.
“The concept of one system, out of the box, end-to-end was flawed,” concedes Rick Bergquist, chief technology officer at PeopleSoft. “We have had to accept heterogeneity in enterprise applications. Now we are learning to embrace it.”
Even at Oracle, the single software package argument is held to be increasingly problematic. “Our corporate strategy – led from the top by Larry Ellison – is that customers should go down the single suite route,” says Andy Cleverly, business development manager at Oracle UK. “But we’re not blind to customer issues, and we recognise that virtually all our ebusiness engagements have some integration element to them. Most of our customers already have third-party and bespoke applications, so yes, there is some difference between corporate strategy and actual engagements with customers.”
That difference will come to the fore as web services become better understood. Web services are applications that use a universal set of standards to send data and instructions to each other, using the Internet as a common backbone. Proponents argue that by building new applications and re-engineering old ones around the web services concept, organisations can create a dynamic IT environment comprising many loosely coupled software components that can share data seamlessly, with no translation required – the antithesis of a large end-to-end, integrated ERP system. Not only that, but because web services can share data with other web services residing on systems beyond corporate boundaries, trading partners can use them to exchange data and collaborate on documents, from invoices to engineering plans.
For customers that already have implemented an ERP backbone in their organisation, the web services concept is good news, enabling them to preserve their existing investment, while at the same time integrating new packaged and bespoke applications and implementing new business processes that more closely fit their specific business needs quickly and cheaply.
And while some may seem reticent, the ERP suppliers have little choice but to meet customers’ demands for more flexible, web services-oriented software. “[Among the] chief information officers and other IT strategists from some of our biggest customers, and every [one] to wants to do something with web services,” reports Kaj van de Loo, director of product strategy at SAP. “Absolutely no-one is ignoring web services. Some are just engaged in one or two pilot applications, but there are different levels of sophistication,” he says.
As that suggests, there is an wave starting here that ERP vendors cannot afford to miss. But what will it take for ERP packages to become fully web services enabled?
To some extent, much of the work has been done already: ERP suppliers have spent the past few years re-engineering their software so that it can be accessed through a simple web browser. Now, they need to expand those efforts with ways of exposing application functions through the key web services protocols: Simple Object Access Protocol (SOAP) for transferring data; the Web Services Description Language (WSDL), a machine-readable description of the attributes and abilities of a web service; and Universal Description, Discovery and Integration (UDDI), for listing the range of web services available.
Suppliers are at various stages along this path, but it is likely to be a long haul, say analysts. “In the same way that the transition to browser availability caused many application vendors to rethink the way that applications were engineered and functions were grouped together, this ability to expose capabilities as web services may also, in many cases, cause those application vendors to rethink and repackage a lot of their functionality and capabilities as well,” says Daniel Sholler at the Meta Group.
However, it is arguably not necessary for application vendors to reconfigure every one of their interfaces to be web services-accessible in the short term, because customers are unlikely to adopt web services at such a rapid pace. Instead, users should look to update applications that are most likely to be accessed from another application as part of a business process – especially when that process is in clear need of streamlining at their organisation.
The fact that many suppliers claim their efforts are more extensive than that, at this stage, is a reason for caution, suggests Michael Barnes at the Meta Group. “Numerous application vendors have approached this by saying, ‘We have always published or exposed our set of application programming interfaces [APIs]; we have a COM interface to all 500 of them, and you can get to them from Java too. So, yes, we will expose them as web services as well.'”
But in fact, says Barnes, more work needs to be done on identifying and componentising ERP software before its constituent parts can be made available through web services protocols. “[The supplier needs to have] gone through some soul searching about how to take a big complex application and to boil it down into a set of functions that would be just usable as ‘coarse-grained’ components.”
Numerous suppliers have not gone through that kind of effort, he claims. “I guess it enables them to put web services on the box, if they just say, ‘OK, we have created WSDL interfaces for all of our 500 APIs’, but it is not that useful to [the customer].”
Moreover, web services are still nowhere near as robust as they need to be if they are to enable some of the heavy-duty tasks that ERP systems traditionally perform – tasks that are mission-critical, transactional, impact on other steps in a process, and demand security and guaranteed delivery and scalability. A recent Meta Group report makes this point more bluntly: “Web services ease integration but in their current state won’t solve integration problems any more than Microsoft Word solved writing problems.”
As well as a threat, however, web services provides plenty of opportunity for the ERP suppliers. As the enterprise application suppliers adopt web services standards, they make it easier for other software vendors to build links between their own web services-enabled software and the ERP suites. But at the same time, the ERP companies can use that situation to gain back some account control that, in the past, has been lost to infrastructure and integration vendors.
While analysts at AMR Research expect integration vendors such as Tibco, WebMethods and SeeBeyond to hold onto the more complex integration projects, they believe “application vendors can and will offer a viable web service option for the small integration projects to other applications”.
To this end, in late August 2002, PeopleSoft launched AppConnect, an integration platform for the PeopleSoft environment based on web services standards. SAP and Oracle, as well as customer relationship management software specialist Siebel, have made similar announcements. But Sholler at Meta believes uptake of these platforms will be limited: “Only companies focused heavily on a single application vendor should adopt its framework for the enterprise backbone,” he says.
In addition, for those application vendors that have grown their portfolios through separate development efforts or acquisition, web services will help tighten their integration stories for their own product lines.
“The [web services] vision of the future intrigues and terrifies enterprise application vendors. It intrigues because it invites much wider and more productive use of their applications. It terrifies because it can radically change the selling and revenue model,” says Jeff Comport, a Gartner analyst. Removing the fixed cost of an application suite, he points out, will make it much easier for customers to change application providers, and as a result, customer loyalty will be much more immediately tied to the ERP suppliers providing “a continuous stream of benefits. “The changes in architecture and technology of the major application vendors,” he concludes, “are more a reaction to market pressures for lower costs for integration, configuration, and maintenance than a deliberate move to web services as a destination.”
For all that terror and intrigue, it seems that Larry Ellison of Oracle will not be moved from his sceptical position. “The idea that Oracle is going to put a web services interface on its applications, and Siebel and SAP are going to do the same, and that that’s going to make it easier for you to connect Oracle to SAP, or Siebel to SAP – that’s just the most ridiculous thing I’ve ever heard in my entire life.” It is also an idea that may live to haunt him.