Software as a Service (SaaS) Definition and Solutions
Software as a Service (SaaS) topics covering definition, objectives, systems and solutions.
By Meridith Levinson
The concept of software as a service (SaaS) took hold at a time when IT executives were getting supremely fed up with the ballooning costs of packaged enterprise software. Not only did they have to shell out thousands of dollars just for the licenses, but they also had to spend tens if not hundreds of thousands more to implement the software. There were the consulting fees. And the training costs. And the extra infrastructure that was required to run the software in addition to ongoing maintenance fees. Thus, SaaS emerged from the wreckage of botched multimillion-dollar ERP and CRM implementations as a radical alternative to traditional software licensing models. SaaS promised easier, speedier and cheaper implementations. The value proposition was hard to ignore, but so were the risks. To this day, SaaS remains an intriguing option for many enterprises, and for that reason, we offer the following answers to explain what SaaS is and to help you determine whether it’s right for your organization.
Generally speaking, it’s software that’s developed and hosted by the SaaS vendor and which the end user customer accesses over the Internet. Unlike traditional packaged applications that users install on their computers or servers, the SaaS vendor owns the software and runs it on computers in its data center. The customer does not own the software but effectively rents it, usually for a monthly fee. SaaS is sometimes also known as hosted software or by its more marketing-friendly cousin, “on-demand.”
SaaS evolved from the application service provider (ASP) model. When ASPs sprang up in the 1990s, they offered essentially the same thing SaaS vendors offer today: hosted applications delivered over the Internet. The problem ASPs ran into (well, actually, they ran into many problems, not the least of which was the venture capital money that dried up in the 2000-2001 time frame) was that they tried to be all things to all people, and they buckled under the weight of their own infrastructure. In trying to serve the unique needs of each of their customers, ASPs lost the economies of scale that were necessary for them to provide their services in a cost-effective manner.
Today’s successful SaaS vendors, such as Salesforce.com, LeanLogistics and Ketera, have solved the scalability and reliability problems that dogged the ASPs and ultimately led to their downfall. (Of course, Salesforce.com did suffer some debilitating outages in December 2005 and January 2006 caused by problems in its database cluster.) Instead of trying to be all things to all people, they offer one-size-fits-all solutions. That is, all customers of a SaaS vendor use the same software. The underlying code is the same for all customers and cannot be customized. Any features or functionality that the SaaS vendor adds to the software based on a customer’s feedback becomes available to all customers. This multi-tenancy approach differentiates SaaS vendors from the original ASPs and from other vendors of hosted, “on-demand” software and gives SaaS vendors the economies of scale they need to offer their software cost-effectively—and make upgrading their customers to new versions of the software a relative cinch.
SaaS deployments are cheaper (at least initially) than on-premise installations. SaaS customers generally pay a flat monthly fee per user for the software. SaaS implementations are also cheaper because companies don’t have to buy additional hardware or infrastructure to make the software work, so there are no capital expenditures with SaaS. You also generally don’t have to hire an army of consultants to get the software installed as you often have to with traditional enterprise software. (There are, of course, exceptions to that generalization. For details, see Stephanie Overby’s article, “The Truth About On-Demand CRM.”) SaaS customers like the idea of a low up-front investment and a predictable expense stream, even though the cost advantages of the SaaS model may be a wash after three to five years of monthly fees.
There are many advantages to going the SaaS route as opposed to installing software on site. First, SaaS deployments usually take less time than on-premise software implementations simply because you’re not installing software on every user’s computer. SaaS vendors like to claim that they can get customers on their software in three months or less, but realistically, implementations can take between three and six months (sometimes more, depending on the size and complexity of the implementation). Because SaaS is easier and quicker to implement than traditional software, you can achieve your ROI faster, too—provided, of course, your users adopt the software.
Upgrades also tend to be pretty seamless (because you haven’t customized the software), and you’re always on the most recent version of the application, unlike with traditional packaged software. (Hello, Windows 98!) The SaaS vendor just pushes the upgrades and updates out to the customer base.
Many users of hosted software say that SaaS is just as secure and reliable (if not more reliable) as their internal systems. They note that SaaS vendors are heavily invested in making sure their software is secure and available 24/7 since that’s the vendors’ business.
Nevertheless, companies have legitimate concerns about keeping their data in a SaaS vendor’s systems because they have no direct control over those systems—and because of the horror stories that emerged from the ASP implosion of 2000 and 2001. When those ASPs went out of business, many of them left their customers without access to their data, and some ASPs even sold the data they hosted. This experience taught customers valuable lessons in negotiating contracts: Always make sure you’ll have access to your data and the software or source code in the event your service provider goes out of business.
SaaS can be risky in the post-Sarbanes-Oxley world—where a company’s ability to certify the integrity of its financial systems and the data contained in them is of paramount importance. Chief compliance officers tend to be particularly wary of hosted software because they’re the ones who are on the hook for the integrity of the systems used by their company, regardless of who’s supplying those systems. Consequently, some companies would rather maintain data internally because they can hold someone accountable for safeguarding it. If you decide to use SaaS, writes Galen Gruman in “The Truth about Software as a Service,” “make sure you get the same auditing and control requirements” from your SaaS vendor that you would get from any third-party provider, including “safe harbor” provisions for ensuring data privacy and the ability to audit the vendor’s controls.
While no application is bulletproof, SaaS vendors have worked hard to address customers’ concerns about security, and today the security of SaaS is much less of an issue than it was five years ago. Still, you would be wise to evaluate your vendor’s security measures, including its firewalls, encryption techniques, socket security features, intrusion-detection systems and other protections the vendor has on its servers. You might also request copies of the vendor’s security audits to give yourself even more peace of mind. However, those measures may not be adequate if your company handles particularly sensitive customer data, such as information about individuals’ health and finances.
If you’re concerned about reliability, make sure you discuss the number of transactions your vendor’s system can handle and write clear financial penalties for downtime into your service level agreement.
SaaS is not right for every company, nor do all applications lend themselves to the SaaS delivery model. The key criteria to consider when evaluating whether SaaS is right for your organization are:
the type of process or function for which you’re considering a SaaS solution
the extent to which you need to customize the SaaS solution
the extent to which it needs to be integrated with other systems (both internal and external)
the maturity of the application
In general, SaaS solutions work best for non-strategic, non-mission-critical processes and functions such as expense and travel management, procurement and employee performance management that are simple, standard, and not highly dependent on or integrated with other business functions and systems. SaaS also works well for processes that are being automated for the first time, because there are no legacy processes to replace and thus fewer change-management challenges.
If your company is looking to adopt established processes for a particular function, like CRM, sales force automation or warehouse management, a SaaS solution could work for you. But if you’re looking to differentiate your company through your customer service or supply chain practices, you’ll want to stick with a flexible packaged application. For that reason, applications that touch on the core of the enterprise, such as ERP and business intelligence, don’t lend themselves to SaaS. Similarly, if the functionality you’re seeking is core to your operations, you might want to stick with an onsite solution so that you can manage the application in the event it goes down.
If you need to customize an application, you should stick with homegrown or packaged software. Sometimes you can tailor the application’s user interface so that it reflects your company’s terminology and processes, but if you want or need to change the underlying code, SaaS isn’t the best option because customization is antithetical to the SaaS business model. Customization drives up the vendor’s costs and complexity. That’s why some vendors refuse to do any customization and those that do charge more for it. Realize that if your SaaS vendor agrees to customize its product for you, the implementation will take more time and be more difficult, and future upgrades will be more complicated. If you choose to do business with a SaaS vendor and you need customization done, find out how the vendor is going to charge you for the customization and how that customization will figure into ongoing costs.
Whether you’re deploying software in-house or using hosted software, integration is never a picnic. The more you need to integrate your SaaS solution with other systems, the longer the SaaS implementation will take and the more difficult it becomes. Indeed, complex back-end integration can be a barrier for companies interested in using SaaS because they don’t have access to the source code, which they need to make the hosted system talk to internal systems. Hosted CRM vendors in particular, however, are increasingly providing robust integration tools because they realize their systems have to hook into other enterprise systems that their customers own. But more sophisticated real-time integration with back-end systems is not yet possible with SaaS.
The good news is that SaaS applications are pretty well designed for interoperability. Because the vendors have to create software that many different companies can easily hook into, they pay close attention to the things that ease integration, such as data exchanges and application programming interfaces.
SaaS can be a good bet if you’re buying a new kind of application that the vendor is going to update frequently with changes and functionality enhancements. Buying the ability to keep on the forefront of those changes through the SaaS model may be worth your while. Keeping up with those changes might be more difficult with traditional packaged software.
By the same token, SaaS can also make sense for applications that have become commoditized, that have been around for such a long time that every company has essentially the same one and the software no longer offers companies a competitive advantage. Proprietary reservation systems in the travel industry are a good example of a commoditized system that airlines are replacing with SaaS offerings.
SaaS certainly has its advantages and place in your application portfolio, but don’t get taken in by the SaaS hype. When it comes time to select an application, figure out what your company wants from the application in question first and proceed from there. When it comes time to select a vendor, consider the basics like the company’s financial stability, its reputation and market position, and the quality, scalability, reliability, security, price and potential benefits of its product.
If you would like to read more about specific companies’ decisions to choose hosted or on-premise solutions, see these related stories: