I can see a lot of people getting burned over web services, the same way a lot of people got burned over ASPs. The similarities between the two are uncanny — particularly the volume of utter claptrap written and spoken about both by so-called industry analysts.
Once upon a time, an analyst used to be someone with deep expertise and industry knowledge in a specific field. Today, it's someone who has an off-the-cuff opinion about everything. These jacks-of-all-trades are skilled in just one thing; the art of sounding utterly plausible while remaining totally ignorant of the topic on which they are expounding.
I know this because I've been guilty of it myself often enough. But if there are two topics on which I can talk with authority, they are ASPs and web services, thanks to more than three years dedicated to researching, writing about and engaging with the pioneers in both industries. So if you want to discover how to avoid getting burned over web services, read on.
Familar ground
The reason why so many misleading statements have been made about both ASPs and web services comes down to simple human nature. Most people prefer to deal with the familiar. Even in the technology business, we want what we're used to, so long as we can have next year's model. So whenever something new comes along in the technology business, the first reaction of most people is to relate it to something they already know.
This works well enough most of the time. A new processor from Intel? Same as the previous generation, but faster. A new server from IBM? Just like before, but more resilient. A new handheld from Compaq? Just like the Palm Pilot, but with colour and Windows.
The only time it doesn't work is when a completely new form of technology comes along that disrupts the existing status quo. [1981] A microcomputer from IBM? Just like a minicomputer, only smaller and less powerful. [1995] A new way of viewing information on the Internet? Just like Compuserve, without the convenience of ready-made shortcuts. [2001] WiFi wireless LAN technology for accessing the web? Just like GSM, but less manageable.
First iterations
You get the picture. The comparisons don't work, because the first iterations of these new technologies seem to have all kinds of disadvantages — if you look at them as versions of what went before. As souped-up versions of last year's technology, they were all complete non-starters. But that was because they were not there to enhance the prevailing technology. Their destiny was to wipe it out.
In the meantime, people get burned, because they believe what all the analysts and established vendors are telling them about this new technology. Look at the ASP model, which the industry establishment defined as a new way of outsourcing existing applications. The trouble is that the ASP model rarely works if you try to apply it to conventional applications. Yet many thousands of businesses thought they would make their fortunes if they invested a lot of time and effort in doing just that — and failed. In fact, there were so many failures that mainstream opinion these days believes the ASP model is dead and buried.
Now web services is getting the same treatment. Web services enable a completely new way of building applications from componentised online services. But that's not what the established industry would have you believe. Ask any analyst or vendor today, and they'll tell you that the purpose of web services is to make it easier to integrate existing applications together.
The trap is set. Follow the crowd, and you'll invest huge amounts of money and resources in web services as an enhanced form of enterprise application integration (EAI). Then you'll get burned. You'll find that customer take-up is slow, that the technology doesn't deliver the benefits you expected, and that the exponential growth all the analysts were promising you never materialises. For some of you, this will be a bitter deja-vu experience, because you went through exactly the same thing with the ASP model.
Obsolete applications
This will happen because web services do not exist to patch up the shortcomings of present-day applications. They will make them obsolete. Web services architectures break down software into discrete parcels of functionality that can be assembled on demand to meet business needs. These components, delivered as online services, are loosely coupled together in a way that makes it easy to modify the makeup of the application by adding, substituting or subtracting individual functions or processes.
Once businesses find out that they don't have to pay integrators to construct massive, inflexible software edifices to automate their businesses, the market for today's monolithic packaged software applications will crumble faster than a sandcastle when the tide comes in. Which is why today's established software vendors and the analyst community that serves them don't want anybody to spend much time thinking about that vision of the future. They'd much rather get you to put your money and effort into web services integration — a phrase that, if you ask me, is a contradiction in terms.
Unfortunately, since mainstream opinion is — by definition — what most people think, few readers of this column will choose to take my advice. Most of you will have forgotten you ever read it by the time its message becomes blindingly obvious to all and sundry. You won't need me then, anyway, because every analyst will be saying the same thing.
more columns