Six Web Services Predictions

I continue to work on and off on the business implications of Microsoft‘s .NET play and its competitors in the web services space. I’ve made a series of off-the-cuff predictions based on some of the latest happenings; I’ll publish them here for comment.

Disclaimer: I have accepted an offer from one of the companies on this page, but this work reflects no proprietary knowledge about the firm or its operations. It’s all conjecture from publicly available information.

  1. The opening of web services interfaces to applications like Siebel and SAP will probably not hurt sales of either of those players. By lowering the cost to implement an interface, web services may increase the amount of leverage that firms using these software packages have over system integrators like Accenture, and correspondingly depress their margins. If you’ve been following how well the consulting and integration firms have been faring in the market right now, this isn’t good news.
  2. Microsoft will use value added services like Passport and .NET My Services (aka Hailstorm) to achieve developer lock-in while giving lip service to developer independence at the level of language choice. This essentially commoditizes the choice of development language and platform and is a problem for Sun, which must keep Java and related enterprise Java technologies a non-commodity choice. Seen in this light, Sun’s playing on the web services field and embracing SOAP doesn’t make a lot of sense–and explains why they have been so late to market with their own approach to this technology.
  3. Microsoft will sell some subscription web services to consumers. Its real concern, though, is selling technology to developers, and access to Passport and Hailstorm customers to other service providers for billing purposes. The new web services platform play according to Microsoft consists of developers and service providers; OEMs, as evidenced by its cross platform approach on the client side, play a very small role and are in danger of having their margins further compressed (if I can pay bills and get instant messages and Hotmail on my PDA or smart cell phone, do I really need to upgrade to the latest computer?). Microsoft hopes to sell more server software too, but right now developers and service providers are the long poles in the adoption of .NET as a platform.
  4. IBM‘s view of a web services “platform play” is server technology and enabling the service providers. This fits well with its hardware, software, and consulting competencies.
  5. Independent developers will keep alive some of the alternatives to the BigCos, in particular implementations like Mono and XML-RPC that simplify some of the SOAP + UDDI machinery and avoid paying annual tax to Microsoft. However, by their nature, these services will tend to be what this IBM paper calls “simple services … available at no charge” and will not be observable on a market share map.
  6. There will likely be interesting technical problems with implementing billing for web services if the “resource counter” model in the IBM paper is used (see Figure 4). In particular, if the server for a web service loses connectivity with the billing provider after initializing a resource session, the client runs the risk of being billed for more than its actual usage. To avoid this problem, it’s unlikely that billing will be implemented separately from providing services until quality of service issues between the service provider and billing provider are resolved. At some point in the future, a reintermediation at the billing provider level may become possible.