There are compelling reasons for ISVs to embrace Web services technology. First, Web services can provide a simple, cost-effective and standards-based approach to integrating software applications within the enterprise. A top complaint from Enterprise users of packaged applications is that they are tired of having to invest in heavyweight EAI projects to make these products work. Web services can significantly ease this problem.
Second, Web services can allow ISVs to expose additional product functionality as services, making the application more flexible and more valuable. In fact, this can open up whole new markets for products. We?ve seen this happen with early adopters like BMC, Interwoven, FileNet and Primus, and this has won great favor with their users.
Going forward, the real question for ISVs is not whether to embed Web services functionality, but how to do this. Compared to Enterprise users, ISVs face some unique challenges. First, they need a solution that is genuinely platform-agnostic, and that can run on all the platforms and in all the IT settings that are supported by the ISV?s products. Most Web services products fail this test. Second, ISVs need a solution that displays faultless interoperability. For example, an ISV with a Java-based product needs to be sure the Web services it offers can be consumed by .NET.
In my view, shared by many analysts, about 50% of packaged application vendors will have Web services functionality in their products by 2004. This has a profound consequence for enterprise CTOs: these applications will act like a Trojan horse, proliferating Web services. Upcoming releases of your packaged ERP, CRM, SCM, BI and other applications will likely contain hundreds of Web services interfaces, tempting your IT staff with a simple point-of-integration so that, in turn, they will create yet more Web services. Be prepared by starting to think now about how you will organize, catalog and control Web services.
This was first published in June 2003