SHARE
Follow this article on Twitter Facebook LinkedIn Bookmark and Share
Home >> Information Architecture >> Messaging and Collaboration

5 myths of SaaS

5 myths of SaaS

By:  Jeffrey Kaplan  On: 22 Mar 2009 For: Computerworld US(NA) Creator

A surprising number of IT and business decision makers remain unclear about software-as-a-service. Here a five commonly held myths about SaaS

Despite a growing track record of success, software-as-a-service is still misunderstood by a surprising number of IT and business decision-makers. It's time to put to rest some misconceptions about SaaS. Let's bust the five most common myths.

Myth No. 1: SaaS is a peripheral trend. Take a look at the numbers, and you'll see that SaaS is becoming a mainstream movement. My firm, ThinkStrategies, has been conducting SaaS customer surveys in conjunction with Cutter Consortium for four years, and our latest survey, in October, found that SaaS usage had jumped from 32 per cent of respondents in 2007 to 63 per cent in 2008.

Equally important, over 90 per cent of the survey respondents who were using SaaS said they were satisfied with the model and planned to renew their subscriptions and expand their use of SaaS offerings. Moreover, they said they would recommend SaaS to their peers. Those are satisfaction and referral levels that traditional software vendors can only dream about.

Myth No. 2: SaaS offers just one type of application. In fact, SaaS tools vary in form and function as much as the overall assortment of software available today.

Although all SaaS, by definition, is available via subscription and is designed so a single code base can support multiple users, there are countless ways in which SaaS is packaged and priced. In fact, our online directory of SaaS providers now lists more than 950 companies that offer SaaS across 80 application, industry and technology areas.

Users can also configure a growing number of SaaS applications to meet their individual needs. While SaaS can't be customized to the same extent as traditional applications, that isn't necessarily a bad thing. Many enterprises have customized their in-house applications to such a degree that the software can no longer be fully supported by the vendors, nor can it be easily upgraded.

The business and IT decision-makers I talk with are recognizing that a high level of customization can be counterproductive.

Myth No. 3: SaaS just offers skinnier versions of more sophisticated applications. There's no question that most SaaS applications have succeeded because they are simpler to deploy, use and maintain than in-house applications are. But that doesn't mean users are sacrificing functionality when they move to SaaS offerings.


Sign up for our Newsletters












Print |  Views: 1130   |   Rating:offoffoffoffoff  (0 votes)
Rate this article on a scale of
1 to 5 stars,5 being the best.




Jeffrey Kaplan Jeffrey Kaplan is a contributor to the International Data Group (IDG) News Service, which publishes global technology stories from bureaus around the world to more than 300 publications in more than 60 countries.

Related Content

Salesforce.com further integrates with Google
Salesforce.com further integrates with GoogleThe toolkit, which lets programmers connect their applications or data into Google Apps and other Google services, strengthens the already tight relationship between the two vendors
Integrating the contact centre: SOA best practices
Integrating the contact centre: SOA best practicesThe ability to integrate contact centre applications into complex workflows enables organizations to support customer interactions across multiple channels, such as the telephone and the Web. Follow these guiding principles to extend SOA to customer-facing applications in the contact centre.
Software-as-a-service gets a green light
Software-as-a-service gets a green lightA survey of IT professionals by RBC Capital Markets shows a substantial number of companies are ready to move ahead with an on-demand model for CRM, among other applications
Why Projects Fail
"why projects fail" is always a popular topic with those of us who write about it. my favorite reason, if one can say that, is poor requirements. variations on this are: incorrect requirements that are used and not caught until test or implementation; requirements that seem to keep changing, and requirements that were right to start but delivery took too long. the last one is really a p
blog comments powered by Disqus