Don't leave web services all up to the suppliers. IT departments know what end-users really need. Lisa Kelly reports on the best approaches to creating a business-oriented project.
Knowing you should be doing something with web services is very different from knowing how. The holy grail of not being tied to an operating system or programming language may be worth the quest, but how do you start on what many commentators say is an inevitable journey?
"You will be an adopter of web services," says Charles Abrams, research director at Gartner. "The technology will be incorporated into every large business application. All IT directors will need is a platform on which to build a service-oriented architecture."
Neil Macehiter, research director at analyst Ovum, says, "The key for IT directors is to understand the business problems web services can solve. The likely problem is one they are acutely aware of: integration."
Mark Quirk, Microsoft's head of technology, development and platform group, agrees, "An ad-hoc way of identifying a business need is to ask what internal information people find hard to get, then create a web service to expose or integrate this data and update the client application to access the service."
Many users remain sceptical about embarking on a web services project. "There are capabilities you may demand of integration technology such as reliability, security and manageability. Web services do not yet address all these problems," says Macehiter.
Creating business value is of paramount importance, says Howard Needham, chief technology officer of online tourism network EnglandNet. The firm used web services to transfer data electronically, so it did not have to build specific interfaces for each partner.
EnglandNet was advised to chose the .net platform by partner netdecisions and focused on recruiting the best candidates for its project. "We included two equally valuable skills-sets in our team. Our national database is fundamental to our business. People with relational database skills interpreted the needs of the data structure, while people with web services skills were brought in on contract," says Needham.
You should be prepared to deviate from the project's original path to ensure success, even if it means delays. "The interoperability gateway was not easy to maintain as clients that linked with our schema had to be XML-aware and needed constant updating," he says.
EnglandNet reassured its partners that making changes would be worthwhile. It scrapped the unsatisfactory interim product which took a year to develop and spent another eight months to perfect interoperability.
Securing web services skills is a challenge if you do not use contractors. Andreas Bitterer, vice-president at market analyst Meta Group, says, "Some sort of training in the Java 2 Enterprise Edition platform or with Microsoft's Visual Studio .net is a must. The chances are you will be using both eventually."
Transportation services firm Con-Way opted for a simpler route. "I picked up a book on XML," says Gerry Hilts, systems analyst at the company. "We grew the skills from our initial project which put a web services front-end on our tracking application, so customers could track shipments from their own website."
To counteract business scepticism, the project was based on J2EE and IBM's Websphere and kept under wraps until "it became popular and useful. Now it is official," he says.
By identifying a business need with a pragmatic eye, Hilts says having a web services front-end to applications "makes our service more valuable to customers".
He advises users embarking on a pilot project to speak to the people behind the product and evaluate the viability of the technology. "We chose J2EE because it has excellent XML libraries and tools. Any tool that varies from a W3C standard is dismissed," he adds.
Both Ovum and Gartner suggest getting suppliers involved early on. "They have expertise you can exploit. Find which supplier vision most closely maps yours," Macehiter urges, but warns, "they have a vested interest so be cautious where they want to take you".
Abrams says, "Shortlist only those suppliers with a strategic service-oriented architecture and determine how far they have got with their plans."
Jason Weisser, vice-president for enterprise integration at IBM, says any web services project should move the business towards a service-oriented architecture framework. "But building such an architecture requires discipline and governance that may not exist. There is an emotional and cultural expense," he says.
To ameliorate this, deliver some value early on. Make targets small at first, he advises.
Despite the pain, Bitterer says it is worth being an early adopter. "Once the technology hits the mainstream you will be up-to-speed on XML to tag data, Soap to transfer it and UDDI services to provide directories of web services for partners," he says. "You will be way out in front of your competitors."
Top tips for a web services project
Neil Macehiter, research director at analyst Ovum, offers the following advice:
- Look at the business requirements of your pilot project and see if web services will fit. If rigorous reliability is a requisite then it would not be appropriate
- Choose a discreet business problem that is not mission critical to pilot web services. Recognise its limitations up-front as the first project will require compromises. A workaround to ensure reliability could lock you into a platform and affect interoperability with other applications
- The lack of standards is a major obstacle. The full promise of web services depends on consensus from suppliers, such as IBM, Oracle and Microsoft, on specifications
- To minimise fall-out, use the proponents of the technology in the team as your eyes and ears at industry events to keep abreast of standards developments. Risk is reduced if specifications have broad industry consensus
- Get a good IT architect. The team needs an architectural view to provide the big picture as web services introduces new management challenges. Security is not managed at one end-point; it crosses from one application to another. Ideally the IT architect should know how to manage fine-grained components
- Business involvement is crucial. Don't engage them at the end because the business must know about any deviations from the initial goal
- To allay business scepticism, identify a deliverable, such as improved access to information, half way through which demonstrates real business value.