Reality rains out the Web services party
Interoperability, standardisation, modularisation, and distributed computing are all noble causes, and analysts have universally lauded the efforts of Web services vendors in bringing the cause forward so far. At the same time, all agree that it will be some time before companies actually begin seriously using the stuff.
That's because real applications simply aren't built like this. Application interfaces must be coded, data interoperability assessed, scalability tested, and configurations optimised.
Source code must be examined, optimised, and upgraded. And, while it may be no small technical accomplishment, depending on external and unknown Web services providers for any important business component is a risk that would set off alarm bells during any due diligence process.
The alternative--establishing vendor trust before integrating modules--doesn't make sense since it would obviate the "discovery" phase of UDDI and could be better addressed by simply installing the software internally.
Businesses want stable, predictable and well understood applications that will consistently perform a specific function as they expect it to. So while Web services may have caught the attention of developers--Evans Data Corporation found that more than half of respondents planned to develop XML Web services this year--business managers have been far less enthusiastic.
"Customers are more preoccupied with running existing IT and business alignment than they are concerned about investigating every new bit of technology," says Merv Langby, chief services analyst with IDC Australia, who believes Web services are a critical enabler of distributed computing but believes it could take 18 months or more before they're seriously considered by most companies.
"Vendors continue to put a disproportionate emphasis on the technology sale, as opposed to articulating the value proposition in business terms. Web services is the best philosophical link to allow businesses to maintain the best of what they've got whilst using the best of what is new. But customers tell us time and again they're in no way keen to give up an established line of business applications. If people don't buy technology for its own sake, they certainly don't buy technology architectures for their own sake."
Therein lies the biggest problem with Web services: for now, they lack enough clear business benefit to justify the risk they entail, or the investment in time and development resources that they necessarily involve.
These days, moving to Web services is like taking the first swig of a new batch of moonshine from the still: it might give you a great buzz-but it might also blind you. If you aren't keen to hand a bottle of this potentially lethal brew to your managers, avoid the temptation to let Web services hype make you promise too much.
Articulate a clear business case, and maintain a healthy sense of scepticism that puts considerable weight on the fact that Web services are still very much a work in progress.
Go into it with your eyes open, avoid overcommitting too early, and regularly reassess your technology platform to make sure Web services are delivering according to your expectations.
"People are seeing Web services as a technology answer, but they haven't asked the business question it's supposed to be answering," says Compuware's Pritchard.
"Realise that if you're doing this now, you're either an innovator or an early adopter. There's got to be a plan for it, including risk analysis and management and fallback positions. These are all business decisions, and not pure IT decisions. You really have to ask yourself why you're doing it."
