Web services are a new way to think about acquiring and offering business services. To enthusiasts, they open the door to a host of benefits, including lower costs, speedier systems installation, and most importantly, greater business agility. Business services that you can connect and disconnect as needed, and pay for on a per-usage basis, are being touted as"the next big thing".

But there's no shortage of sceptics.

A few weeks ago I was in sitting with a group of German CIOs at a Gartner Executive Programs roundtable in Hamburg. One of my colleagues, Dr Marcus Blosch, started a session titled"Untangling Web Services". Within five minutes the mumbling started. What are Web services? Where are the standards? Who is really doing it? Is this just vendor hype? In fact, Marcus was about to raise just those questions and provide a course of action, which, in the end, satisfied the sceptics.

The Internet and standards enable Web services. Web services are modular business services, fully implementable in software, and delivered over the Web from a third party as and when needed.

The delivered module corresponds to part or all of a business process, such as billing, purchasing, or delivery of items. Modules can be changed or linked using standards like HTTP and XML to provide a complex business process. This allows you to use the Yahoo search engine in your own systems or have logistics information from UPS piped directly into your inventory system.

Enterprises will offer Web services by"exposing" the business functions in their existing systems and"packaging" them as Web services. For instance, a bank may offer a money transfer service to anyone who needs it, and will be reimbursed by transaction.

It's not appropriate to replace all business services with Web services. But some like those mentioned above - billing, delivery, and purchasing - are good candidates for replacement. They're all fully implementable in software and they require no human intervention once they have been set up.

But, as with the early days of any new technology, the obstacles look daunting.

Web services will not be built in a day. Six challenges must be overcome to realise Web services' promise. The first two challenges are closely related: matching what's available with your needs and establishing a close relationship with module providers.

Availability doesn't match need. There's little on the market today, but it's a catch 22 situation: there are few Web services, so users don't bother seeking a match for their requirements. This deters enterprises from investing in new Web services. And as you would expect at this early stage of development, there are no standard payment terms or end-user licences.

A way to break the vicious circle is to work with trading partners to create a Web service that co-mingles your mutual processes. Another possibility is to persuade one of your external services providers (ESPs) to build a Web service to fulfil one of your needs.

The second challenge is dealing with multiple contracts, making relationship management difficult. You have to trust Web service providers to deliver around the clock, 24x7. Moreover, you may have to trust them with your data, which often will be confidential. To short-circuit the time it takes to build a new close working relationship, it makes sense to work with an enterprise you already trust. An alternative is to work through an intermediary - a broker or go-between - trusted by both parties. Or simply stick to tried and tested Web services, where the contract terms are sufficiently precise to substitute for trust.

The third and fourth challenges concern overlaps in Web services, which introduces duplicate functionality, and gaps between Web services, which leads to a shortfall in functionality.

The fifth challenge is the problem of vendor lock-in. While it's true all Web services must be able to interoperate no matter what tools or products were used to create them, vendors are always tempted to make their own enhancements - just think of Java - but this is an unfounded fear.

The incompleteness of technical standards is the last of the six challenges. As standards are completed, they will force rapid changes to product releases and projects.