Software as a Service: Not without Caveats

The software-as-a-service (SaaS) model has so far been broadly adopted in the worlds of sales force automation (SFA) and customer relationship management (CRM), where lately the success of NetSuite, Salesforce.com, and RightNow has influenced traditional software makers to get busy and tweak their product portfolios. However, those same vendors, while working feverishly to SaaS-enable some of their offerings, are hoping to buy some time by pointing out that up to now, SaaS deployment has mainly been a proven solution for specific, well-defined business needs only, and this primarily within individual departments.

For a discussion of the trend toward SaaS, see SaaS-ing the Manufacturing Opportunity.

Part Two of the series SaaS-ing the Manufacturing Opportunity.

Despite the success of the companies mentioned above, many people are still skeptical about the long-term success of SaaS. Data sensitivity, privacy and security (outside the user's firewall), the system's flexibility, and concerns about recent, highly publicized outages (which translate into general system performance concerns) represent only some of the issues that will give on-premise applications a longer lease on life. In addition to such concerns, the question of whether on demand hosted offerings can be properly integrated with existing on-premise applications as well as skepticism over the usefulness of adapting SaaS or on demand solutions to unique business processes and practices top the list of doubts.

Salesforce.com and other SaaS-evangelist companies typically offer workable solutions for such standard business operations as capturing sales opportunities and leads. However, by using true multi-tenant architecture, which allows volumes of numerous customers' data to be stored on a single instance of the database on the vendor's premises (a heck of a lot of metadata to be maintained by the vendor), such applications often cannot offer companies (especially large and demanding ones) the kinds of differentiators they need to increase sales and profits or gain market share. Indeed, SFA processes are quite cut-and-dried (routine) and are not exactly revenue generators as long as their functionality is merely about capturing sales personnel's opinions on opportunities and making sure that they abide by the sales process rules.

Sales forces are quite successful at leveraging this "one-size-fits-all" delivery model, as they are still to this day the least regulated of all business process functions. This delivery model enables each sales person to quickly deploy a solution because, in their opinion (and consequent attitude), the tools they use do not impact the other parts of the organization. That is to say that in such environments, there is no point in extensively customizing the SFA system since it is not the details of the sales process that matter much. For instance, since planning implies some ability to proactively influence the outcome, those user organizations that have attempted to integrate the disconnected SFA function with the forecasting, fulfillment, and accounting aspects have uncovered additional challenges when these are attempted in a SaaS manner.

In other words, resembling the well-known "80-20 rule" somewhat, that final 20 or so percent that sets any company apart from its competitors often cannot be provided by SaaS solutions. The need for differentiation will require the enterprise to still seek out more traditional vendors who have industry-specific expertise and broader functional footprints to accommodate evolving, interdepartmental business processes. At the very least, coexistence of SaaS and on-premise applications will be the reality for many enterprises (Microsoft cites the existence of dual models, where a PC-installed application can be enhanced by online functionality, as seen with media players like Windows Media Player), so SaaS will be able to move beyond providing operational efficiency toward helping businesses become more effective. Giving users the ability to customize screen field names, as one is able to do in a Salesforce.com service, is not going to cater to true differentiation. Neither will enabling users to write JavaScript (or similar) and put the universal resource locator (URL) for the script in a custom field, nor will the use of tab access and the style sheets, which is what Salesforce.com refers to as "customization".

This resembles the "a-ha" notion of the "iPod user experience" that lets users listen and arrange music to their (distinguished) hearts' content in a new, simple, clear, and appealing way. Companies need to conduct their business processes differently from what they have done in the past if they want to set themselves apart, and this includes creating new features and interdepartmental/inter-enterprise flows. Thus, it remains to be seen how much Salesforce.com's Apex, the vendor's most recently unveiled multi-tenant interpretative language, will help in that regard. Apex, a runtime engine with Java-like syntax and the functionality of procedural language structured query language PLSQL (since the underlying database at Salesforce.com is Oracle), was designed to work with the Salesforce.com application programming interface (API). Apex has limited functionality that can only do what it was designed to do (special database triggers and stored procedures, for example), and it is not really the general-purpose programming language needed to accommodate significant custom programming. Again, the benefit of a controlled environment comes with the downside of limited tailoring. Enterprises also want more control of their applications, as they need to constantly change configurations in order to add new products, develop closer integration between their systems, and introduce best-in-class business processes.

For the above reasons, even Salesforce.com is trying to break out of the narrowly defined box that it started in as a CRM/SFA company. Its most aggressive efforts center on its AppExchange partnering platform and ecosystem of third-party applications so as to expand their functional scope and create more differentiating, opportunity-to-order business processes. Time will only tell how this strategy will work with the vendor's business intelligence (BI) and analytics and data integration partners (some of which are high-profile companies like Business Objects, Informatica, or Pervasive Software); enterprise incentive management (EIM) partners like Centive, Xactly Corporation, Cellarstone, or Perks,com (whose functional capabilities and what-if planning processes should be able to influence sales forces' behavior toward increasing revenue); product configuration and partner relationship management (PRM)/demand chain management (DCM) partners (like Selectica, Comergent, Webcom Inc., Big Machines, Firepond, etc.); marketing automation and analytics partners, and so on. Furthermore, the emphasis of some AppXchange partners of late has been on developing the financial services vertical and to subsequently build out a strategy to its closest areas such as insurance, media, banks, and so on.

As for Apex, it is also built on a multi-tenant architecture, which means that each customer's code is segregated from the codes of every other customer, even though all customers are running on the same instance of Salesforce.com. While this segregation of code instances should increase the ability of individual customers to customize their systems, some AppXchange partners have expressed concerns about it potentially cannibalizing their businesses and the need for their solutions.

Most recently, in mid-December 2006, Salesforce.com announced its AppStore vision and monetization strategy for the AppExchange (Apex) marketplace. Customers will be able to use AppStore as a single source for trying, buying, and deploying on demand applications on the AppExchange. AppStore will eventually provide a complete package of commercial services and revenue-sharing programs for developers and partners (a zero-touch sales model, managed entirely by Salesforce.com). Developers and partners will then be able to use AppStore as a global distribution network to market, sell, invoice, and deliver the applications they have built using the Apex programming language and platform made available on the AppExchange. AppStore is hoped to be the catalyst that unlocks the value of Apex and the AppExchange, accelerating the vision for the creation, delivery, and success of basically any application on demand. The idea here is that AppStore should make the purchasing of on demand applications for customers as easy as buying music on iTunes, whereas for partners, it is hoped that AppStore will remove the burden and expense of building out a sales and distribution channel. Additionally, the global AppExchange incubators will help companies develop new products on the Apex platform, and will also help to accelerate the success of existing AppExchange partners. Ten companies have already signed up for the AppExchange incubator program including Appirio, Avankia, Centive, Convenos, DomoDomain, InsideView, InvisibleCRM, Right90, VerticalResponse, and Xactly.

Salesforce.com pledges to provide AppStore services to partners for a revenue share percentage of closed deals that will vary depending on the level of services provided. AppStore services are currently scheduled to be offered in a phased approach throughout 2007: Standard Referral in the first quarter of 2007, Premium Referral in the third quarter, and AppStore Checkout in the fourth. Customers who purchase Salesforce.com applications should make their purchase decisions based upon features that are currently available on the existing Apex platform, and they will not be charged additional fees for using AppStore services. As previously announced, the next release of the Apex platform is currently scheduled to be available in conjunction with the release of Salesforce Winter 07, and the Apex programming language is currently scheduled to be available during the first half of 2007.

More Caveats

Coming back to the list of actual or perceived limitations of SaaS, two other major concerns are how integration between off-premise (SaaS) and on-premise data and content will be securely routed and managed, and what happens to the wealth of sensitive data and accumulated information when the customer cancels the SaaS arrangement with the vendor. Also, many territorial information technology (IT) managers will not be pleased with the idea of relinquishing parts of their "IT fiefdoms" and having to rely on an outside host's ability to impeccably run their data centers, even if the host is a viable business. At the end of the day, the major question remains whether SaaS deployments are really ready to support complex, global organizations around the clock and on stringent service level agreements (SLAs) or not.

These issues, combined with a new and growing market awareness, may explain the findings of some recent studies indicating that over 60 percent of enterprises currently still prefer the perpetual licensing model on-premise over subscription-based options. In fact, most of Salesforce.com's AppXchange partners still have sound on-premise businesses, and typically claim that only 10 to 30 percent (at most) of revenue comes from the Salesforce.com alliance. Also, most SaaS vendors are positioning themselves as software plays even though they are really blending software and consulting services, whereby the understanding of these services and their economics (both those of the master vendor and of its partner ecosystem) is still being devised. For now, this positioning is largely in the form of fixed set-up and consulting fees before the customer can embark on the pure subscription service. Accenture's relationship with Salesforce.com is both a blessing and a curse in that this partner represents a serious endorsement of the SaaS delivery model, but one should still expect some notable consulting price tags for certain implications even in the SaaS environment.

As for software licensing, the most common way today remains for the customer to pay a fixed fee according to the processing power of the machine (or machines) being used, or another widely used alternative whereby the user enterprise (licensee) pays a fixed fee according to the number of users (or seats) accessing the software (see New Approaches to Software Pricing).

To be fair, both approaches are relatively stable; the customer can budget using a formula while the vendor receives a big chunk of license revenue up front and a steady flow of annual maintenance revenue (usually 15 to 20 percent) thereafter. It is a steady, profitable model that customers and investors both understand, and habits are difficult to break.

Another downside of a hosted model is the long-term cost of "leasing" the service for the customer. One of the primary benefits of hosting is the initial negation of up-front costs associated with (since one still has to cleanse data, test and integrate systems, train users, etc.) more rapid implementation of a production system. SaaS does indeed cancel out the need for separate server hardware or hosting, and it reduces upgrade costs, as it does the cost of bug fix and patch application, tuning, and other maintenance and support traditionally done by the user enterprise's internal IT staff. However, after a certain period of time, the subscribed-to system will begin to cost more than an in-house production system would, and the customer has no ownership of anything at the end of the day. The appeal of SaaS is immediate gratification coupled with reduced initial financial pains, as would be the case with renting an apartment, furniture, or appliance as opposed to buying one.