Home
 > Research and Reports > TEC Blog > To SaaS or Not, Is That a Question? - SaaSy Discussions (...

To SaaS or Not, Is That a Question? - SaaSy Discussions (Part IIa)

Written By: Predrag Jakovljevic
Published On: May 18 2009

The first part of this blog series described the opportunity for software as a service (SaaS) or on-demand enterprise applications, especially in the current difficult economic milieu. But before any vendor can embark on delivering a SaaS offering, it must understand several misconceptions about SaaS.

Part two then analyzed the first two of the top five SaaS assumptions that Gartner recently outlined in its research

More SaaS Facts and Fiction

The third assumption is that SaaS is priced as a utility model, which is almost always false. Although the claim is that companies are only charged for what and how much software they actually use, for most SaaS deployments, a company must commit to a predetermined contract, independent of actual usage.

If any company really wants utility pricing, then it should demand that the SaaS vendor charge, e.g., per each sales quotation, order, or shopping cart checkout (in case of using an on-demand sales configurator) or per individual case (in case of using an on-demand case management software). However, to be fair to vendors, it is interesting to note how many customers are still afraid of using this pricing model per se.

Namely, many companies are overly optimistic (if not delusional) about their future success, and they believe that they will grow rapidly. Thus, the assumed (unrealistically high) volume of transactions will make the utility pricing model prohibitively expensive. Even in today’s shrinking economy, not many companies realize that their sales transactions will dwindle and that they could even save by using a utility-priced model.

I bet that most on-demand customer relationship management (CRM) clients would opt to pay, e.g.,  US$70 per user per month instead of being charged US$1 per each created account, contact, and opportunity. If one added all new accounts, contacts, and leads that a user creates in month, I am pretty much sure that in most environments these figures would not amount to 70 bucks, at least not in this economy. Thus, even some decent SaaS vendors will then say “Fine, since you insist on a SaaS contract, this is our price per user per month, please tell us for how many users and for how many years would you like the contract signed?”

Assumption number four is that SaaS does not integrate well with on-premises software applications or data sources. This too is false, since there are two primary methods of integrating SaaS offerings with on-premises applications or data sources. The first is batch synchronization, while the second is real-time integration using Web services.

Gartner points out another way to combine the two above integration methods into an event-driven programming manner. This creates Web service triggers that are based on events occurring in the SaaS service. And yet another method involves integrating SaaS applications at the user-interface (UI) level through mashups (or hybrid Web applications).

Finally, Gartner’s fifth in its top five false assumptions is that SaaS applications cater only to basic functional requirements. As said in Part II, SaaS applications are highly configurable at the metadata level, with many customization capabilities coming inherently from within an application platform as a service (PaaS).

In the next parts of this blog series I will talk about some good examples in which complete custom applications have been built using a commercially available PaaS. However, Gartner warns that some gaps might remain for truly complex, end-to-end processes that require deep workflow or business process management (BPM) capabilities.

The Myth of SaaS Users’ Size

I could also add a sixth myth, which is that only small and medium enterprises (SMEs) are a good fit for SaaS. Indeed, many traditional larger on-premises software vendors still believe that only little customers use SaaS, which comes as a good excuse for their SaaS laggardness.

But successful SaaS players have a plethora of large enterprises as customers, even for mission-critical applications. Think of Salesforce.com, which recently celebrated its first 10 years, and which sells its namesake CRM solution Enterprise Edition to large banks, brokers, technology companies, healthcare, professional services, and so on. Companies with even 50,000 and 75,000 user implementations are Salesforce.com CRM customers.

Even relative newcomer Workday is already selling its human resource management system (HRMS) and other parts of enterprise resource planning (ERP) to firms with 20,000 or more employees. Not to mention Automatic Data Processing (ADP), which has always sold its SaaS HR/Payroll product to firms of every size (we just didn’t know what to call it in the decades before the advent of the SaaS acronym).

In fact, customer size will not matter, whereas the independent software vendors' (ISVs') product and reputation will when it comes to success in the SaaS arena. Large enterprises and midmarket customers need ever more support and higher quality of service (including service level guarantees). In turn, ISVs will have to deal with more sophisticated business partners for SaaS design, implementation, customization, and to provide a bulletproof infrastructure.

Aleks Ivanovic, chief executive officer (CEO) and founder of the SaaS vendor Webcom Inc., believes that the traditional software channels play a much smaller role in SaaS because there are no hardware pull-through sales, while software implementations have thus far been generally shorter, smoother, simpler, and therefore less attractive to system integrators (SI’s) and consultants. However, as the SaaS vendors’ solutions mature and evolve, there will be more and more room for partners because the projects are going to get more complex as a result of the following two major trends:

  1. SaaS software is becoming more powerful and as a result it is starting to address more complex business processes. Integrators with specific functional expertise start playing a greater role in SaaS implementations (e.g., Accenture, Cast Iron Systems, or Bluewolf have lately become Salesforce.com’s notable SI and consulting partners). Today’s SaaS projects go far beyond early on-demand sales force automation (SFA) implementations consisting of merely importing contacts, accounts, leads, etc., and then going live.

  2. More and more implementations consist of implementing several SaaS offerings at once. For example, Webcom’s WebSource CPQ on-demand product configurator is rarely deployed on its own, while CRM systems are also frequently no longer deployed alone. What we are seeing more often these days, and I think the trend will only accelerate, are implementations where a legacy on-premise solution is replaced by a combination of several SaaS vendors, such as Salesforce.com for CRM, WebSource CPQ for configuring, quoting, pricing and order management, and CODA 2go for the order-to-cash accounting process, as an example.


SaaS Opportunity Does Not Guarantee Success

Thus, while many see a large and growing market for SaaS applications (whereby even the currently sluggish economy will likely bolster and accelerate the on-demand market) and the opportunity for aspiring SaaS vendors is right now is far from being an easy endeavor. Namely, developing SaaS solutions successfully involves a “helluva lot more” than simply putting an application on the Web. SaaS is a completely different ball game than the traditional on-premise one, and just rewriting an old on-premise application will not work.

I concur with Amy D. Wohl’s assertions in her recent blog post:
“Note that offering a SaaS version of your application that is less than the real thing will not work, particularly if you are the standard bearer in a big market segment. The customers will find it less than satisfactory and a new SaaS startup will find your mistake their lynch pin to guarantee their market success. SaaS customers, thanks to the web, know the alternatives and want the real thing. We can't count on marketing in little curtained cubicles to less-than-knowledgeable customers any more.”

When asked about the rewrite issue, David Dobrin, president and founder of B2B Analysts Inc. said:
“It's really complicated, but the simple answer is that there is no way. You get no edge when you rewrite your product for SaaS, and you run into enormous business model problems. Suddenly, you have three times the up-front costs and the time you have to wait before you make money on your product is doubled.

Repeat: there is no edge. The last thing you want to do is build the same product on the web, since you want to exploit web capabilities. So you have no edge there. Your customers are already trained to buy on-premise, so they see no point in buying from you. Your entire organization has got on-premise DNA, which in this context, is pretty much as incurable and deadly as HIV. If you've got the money and the cloud bug, start over.”

But even for those who get the drift and want to start from scratch, unfortunately there is no magic bullet yet, just a long and painful learning curve. The good-old (and daunting) “Build vs. Buy” cost analyses apply at every step, from deciding on the solution’s expertise (functional footprint), architecture, plumbing tools, hosting mode, platforms, etc.

Even when all these decisions have been made and the SaaS product is delivered, then come the serious preparation tasks for technical operations of a SaaS business, such as quality testing of software, management of the product’s release cycles (i.e., how to manage maintenance windows, upgrades, and new functionality without affecting customers), performance (uptime) monitoring of the Internet hosting service infrastructure, reliability, replication and recovery, compliance and auditing, contract management, customer service, and so forth. Most of these operational issues are naturally quite different than in the on-premise software arena.

Key SaaS Technical Considerations

But let me backtrack first to the very beginning (a new SaaS product’s initial idea) and postulate the necessary decision-making steps thereafter. I recently attended an excellent Webcast sponsored by OpSource, a leading provider of Web operations solutions (managed hosting with value-add SaaS plumbing components) for SaaS companies. The presentation on the key technical considerations for SaaS aspirants came from Scio Consulting International. Scio is a SaaS-enablement professional place that offers SaaS business and technical consulting, SaaS product development services, and SaaS infrastructure management and operations.

First of all, an appropriate SaaS feature set must be aligned with the future SaaS company’s vision and strategy, and all that with the Web-based mindset. Namely, the future SaaS vendor has to answer whether there is already an existing on-premise version of the application, and who the target customer for the SaaS application would be (i.e., would it be the same as for on-premise or it is a new target segment?).

Also, what is the purpose of creating a brand new SaaS solution? Is it an opportunity to enter new markets, to expand the current reach, or a way for the vendor to stop losing clients? The vendor’s executives should hereby also consider how the product would handle and provide business analytics (and metrics) as well as mobile devices.

Once the functional footprint (scope) is decided upon, the company has to identify gaps within its in-house skill sets and define how to fill them. One should differentiate here between the skills for product building and operating.

The first group of skills entails product management, Web architecture design and development, Rich Internet Application (RIA) user interface (UI) design, infrastructure architecture, and Web testing.  The operating skills focus on Web-based marketing and sales, infrastructure management, Web application management and performance monitoring, and Web-based customer service and technical support.

Part IIb of this blog series will continue with more major technical considerations before any vendor can embark onto delivering a SaaS offering. In the meantime, your comments and feedback with regard to the opinions and assertions expressed thus far are welcome.

If you are applications users, how important are the abovementioned considerations in your software selections? For both users and vendors, what are your SaaS experiences (both in using and delivering a solution)?
 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.