The first is to buy a plug-in product, rather than an OEM one. The plug-in strategy leaves your existing system, data, and users in place, adding the required functionality for only selected users. While this overcomes some of the issues with the OEM strategy, it means that every "full-feature" user has to pay for a salesforce license as well as for the plug-in. That limits the amount that the plug-in vendor can charge, which means they have to do a higher-volume business to make money. This broad-market imperative means that plug-in vendors can't go deep into the vertical market customizations the way an OEM can. There are some other issues:
• Like OEM products, some of the plug-in features will be in code you can't get to, and some of the pages will not be customizable through the administrative GUI. Customization is likely to be expensive, if it's possible at all.
• Like OEMs, there will be product-longevity issues if the plug-in vendor goes out of business, sells off the product, or simply discontinues it.
The second alternative is to buy Force.com platform licenses, building out the needed functionality yourself. Platform licenses are less expensive than standard user licenses because they exclude several CRM features - which works fine if your specific requirements are focused on just a couple of the standard business objects. Following this strategy, you'd create custom objects and write business logic to get the exact feature set you need. If you want fancy GUI features (such as single-page entry that spans several business objects), you'll need to write additional code. For firms with their own development capabilities, this is a great strategy because they (1) have complete control over the feature set and its evolution, (2) pay less in monthly fees, and (3) own all of the final product. Because the CRM platform offers so much infrastructure, these projects are quick to deliver initial business value (calibrate in weeks, not quarters). If you do it right, it's never boil the ocean.
The issues, of course, are the responsibilities that come along with any development project:
• Even with the insulation of web services and encapsulation of objects, your code will break occasionally, and every feature request needs to have a budgetary request along with it. • Perhaps even more important, developing it yourself risks re-inventing the wheel. Product companies are able to leverage lessons from their customers, so the products you buy are likely to be more finely honed than any you build.
Obviously, this is just the latest twist to the classic build-or-buy conundrum. But the cloud, the infrastructure of Web services, and the commercial ecosystem provide new options that can lead to more flexible long-run solutions.