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.