Given the handsome return on investment figures supplied by analysts and IT vendors, the case for organisations building tighter electronic links with their partners and suppliers seems compelling. According to IT economist Paul Strassmann, for one, collaborative technologies can allow organisations to slash administrative costs and pass these benefits on to their customers in the form of lower prices.
However, to reach this collaborative nirvana, hundreds of millions of dollars have been spent on technologies that today only provide a fraction of the functionality required to build the collaborative communities of tomorrow. Fred Meyer, chief strategist with business integration specialist Tibco is cautious about the technology shifts necessary to achieve end-to-end, business-to-business process flow. "Some parts of this work could take twenty, thirty or even more years," he says – not wholly encouraging for the many vendors that hope ‘collaboration' will be the tag on which they make new sales.
Clearly, says Meyer, creating the collaborative enterprise requires a lot more than simply jamming applications together through an application programming interface, expecting data to suddenly flow effortlessly between applications and calling that a collaborative framework. The technical problems are far more fundamental.
Major hurdles
One of the main inhibitors to building a collaborative infrastructure is that today's packaged applications were developed for a more self-contained environment. "The current enterprise application model is becoming obsolete. Each application was designed to stand alone as the centre of a user's universe," explains Rod Johnson, an analyst at AMR Research. This is quite the reverse of what collaboration is meant to be about. "They were built on a technology stack that doesn't address our multi-vendor world," adds Johnson.
This leaves organisations with their first major hurdle – integrating these islands of technology with other systems both within their own businesses and externally. In the past, application integration vendors have focused on providing ‘adapters' designed to integrate an organisation's core business application software into one seamless whole. Once organisations have achieved this, they are then in a position to link these internal applications with those of their trading partners.
More recently, the focus has moved to integrating systems at a process level, rather than at the data level, and a number of newer integration technologies have sprung up around the business process management (BPM) concept. Later, as organisations' understanding of business process integration matures, analysts predict they will move on to concepts such as real-time integration and web services. At present, however, many organisations are still in the early stages of getting their own systems in order, let alone integrating their processes in real-time with those of their suppliers and partners.
Real-time integration, claim analysts, can create extraordinary efficiencies in the supply chain, and, increasingly, in the way the supply chain is linked to customer-facing applications. By having access to disparate systems in real-time, enterprises can quickly react to events in the supply chain so they do not impact performance. PC maker Dell, for example, uses this principle to revise its forecast every few hours and notify suppliers accordingly. In theory at least, this collapses the time it takes to react to changing conditions and so reduces latency. Real-time messaging – a technology originally developed for Wall Street share traders – is the fundamental building block on which these ideas rely. To be truly effective, however, real-time messaging needs to be combined with a highly distributed, massively scalable broadcast mechanism that reliably provides users with the information they need.
|
||||
Integration stack
Another core component of the technology stack is the application server. Application servers, from vendors such as IBM, BEA Systems and Oracle, act as the glue that harmonises the activities each application undertakes. In fact, application server providers now argue that their products have sufficient integration capabilities to do away with some of the need for enterprise application integration. Even enterprise resource planning (ERP) vendor SAP has now announced it is entering this market. Laura Ramos, an analyst at Giga Group believes the motives behind the announcement were to do with the accelerating shift in organisations towards automating the integration of business processes. "SAP has stated that the main driver behind this move was growing client demand for a way to interact with partners and customers across the firewall, tying business systems together with human and process elements," she says.
On top of the application server and integration stack, portal technology has received renewed attention as a delivery mechanism for providing role-specific collaborative information and applications. To be effective, however, it needs to sit in a separate layer to other technologies. This market has been inundated with vendor propositions from a number of technology areas: BEA, IBM and Tibco whose heritage lies in the integration market; portal ‘specialists' such as Plumtree; and application vendors such as SAP, Oracle and PeopleSoft.
Ultimately, believe analysts, the portal will be just one type of delivery mechanism for web services, essentially a means of componentising applications so that enterprises can pick off those bits of functionality they need to assemble applications to suit a particular purpose, or ‘web service'. However, building the required infrastructure for web services presupposes that a lot of continuously evolving and sometimes conflicting standards are in place.
In presenting the ‘service' to the user, Java pioneer Sun Microsystems argues that using products based on the J2EE (Java 2 Enterprise Edition) standard on the server side is vital to ensuring that web-based applications or services of any type can be readily presented to the user. Microsoft, meanwhile, is pushing its .NET architecture as an alternative to J2EE. Unlike past wars of this kind, the consensus view is that both J2EE and .NET will co-exist in much the same way as the Unix and Windows operating systems have done for a number of years. From a user perspective, it is not an agonising ‘either/or' technology decision.
|
||||||||||
The analyst community has got pretty excited about the prospects for web services. Consultant Patricia Seybold for example says: "Because web services adhere, by definition, to a common set of high-level interfaces, they can be mixed and matched to create Internet-enabled applications." Many of the capabilities that are referred to today as web services are simply existing application functionality (such as a transaction monitor or an order entry system) with published web services description language (WSDL) interfaces that can be registered in a Universal Description Discovery and Integration (UDDI) directory, communicating via XML and Simple Object Access Protocol (SOAP). But vendors are less sure of the potential of web services. Both Meyer at Tibco and Harvey Seegers, CEO of integration company GE Exchange Services (GXS) agree that, in reality, web services are little more than ‘a tick in the box' to convince analysts that a vendor has a strategy for the future.
Shared knowledge
In terms of agreeing on B2B standards, the closest any industry sector has come to date is in the development of applications that support RosettaNet, a set of standards for the high-tech industry that describe Partner Interface Processes, or PIPs. Each PIP specification includes a business document and a business process – documents can be read in XML-capable browsers and passed between systems that support the standard. It is possible the work done by RosettaNet is enough to allow the rapid creation of new standards for other industries but this is a slow process. In the UK house-building industry, for example, suppliers such as Travis Perkins and Redrow have developed eBuild-XML, an agreed method of exchanging basic documents like orders and invoices.
At present, however, most collaborative initiatives centre on internal data sharing, or knowledge management. Today, portals are being deployed on a ‘roles basis', where the user receives information and applications related to their function and which can, in some cases, be customised to suit individual needs. Even collaboration at this level is proving more difficult than organisations first anticipated as they attempt to bring together a range of applications as diverse as instant messaging and content management. Instant messaging, for example, provides a great way for individuals to hold private ‘conversations' while engaged on conference calls. But which of the instant messaging providers – Yahoo, MSN or AOL, to name just a few – should enterprises standardise upon? Even when these issues are resolved, users will still find it difficult to track down the information they require for particular projects. Research from management consultancy PricewaterhouseCoopers indicates that people waste hours of time searching for the information they need.
As these technologies coalesce, choices will become clearer but today's market immaturity means the prospect of deploying portals externally to partners or suppliers as part of a wider collaborative effort is limited. Issues around trust, the on-going problem of integration among different versions of the same software, let alone re-defining roles in the extended enterprise, are enough to deter all but the most ambitious managers. "Once you're outside the firewall, complexity increases geometrically," says Rob Hailstone of market research company IDC.
So is the notion of end-to-end processing and ubiquitous data sharing achievable through technology? Perhaps not yet, is the answer. Prem Puri, global solutions executive at technology giant IBM, offers a salutary anecdote: "It took the aircraft industry ten years and hundreds of millions of dollars to collaborate and share information about seats and pricing. It set out its collaborative intent in 1993, but is only now trying to put standards for communication together. In achieving true collaboration on a technology level, there is still much to do."
|
|||
|