Software as a service (SaaS) is a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers do not pay for owning the software itself but rather for using it. They use it through an API accessible over the Web and often written using Web Services or REST. The term SaaS has become the industry preferred term, generally replacing the earlier terms Application Service Provider (ASP) and On-Demand.
The concept of "software as a service" started to circulate in 2000/2001 and is most notably associated with Tim O'Reilly's Essay on the "The Open Source Paradigm Shift"[1] as well as firms such as WebEx Communications, and Remote Business.[2][3][4].
The camelback acronym "SaaS" now in widespread use was coined in it's popular CamelCase form for a conference organized by the non-profit Software Development Forum[5] in March of 2005[6].
As a term, SaaS is generally associated with business software and is typically thought of as a low-cost way for businesses to obtain the same benefits of commercially licensed, internally operated software without the associated complexity and high initial cost. Consumer-oriented web-native software is generally known as Web 2.0 and not as SaaS. Many types of software are well suited to the SaaS model, where customers may have little interest or capability in software deployment, but do have substantial computing needs. Application areas such as Customer relationship management, Video Conferencing, Human Resources, Accounting and Email are just a few of the initial markets showing SaaS success. The distinction between SaaS and earlier applications delivered over the Internet is that SaaS solutions were developed specifically to leverage web technologies such as the browser, thereby making them web-native.
The key characteristics of SaaS software, according to IDC, include:[7]
SaaS applications are generally priced on a per-user basis, sometimes with a relatively small minimum number of users, and often with additional fees for extra bandwidth and storage. SaaS revenue streams to the vendor are therefore lower initially than traditional software license fees, but are also recurring, and therefore viewed as more predictable, much like maintenance fees for licensed software.
The reason for moving away from the term ASP or application service provider is that ASPs host applications with HTML frontends added as an afterthought.
This gradual shift in the terminology is also a direct reflection of the change in the business requirements demanded by clients. The focus in SaaS is more on what the customer wants rather than what the vendor could give.
Early SaaS approaches are application service providers (ASPs) who run a turnkey application on behalf of their clients. But ASPs generally do not build the application themselves; rather, they take an off-the-shelf application (such as a messaging platform, an enterprise resource planning tool, or a customer relationship management package) and run it for customers in a secure, uniform environment.
SaaS vendors typically use a multi-tenant architecture, meaning that multiple customers are running the same software, but with a virtually separate data. ASPs by comparison, deploy one application instance on a server for each customer. However, in recent times ASPs are moving towards using virtual environments for each user\customer which involves a separate instance of each application. It's reasonable to assume that multi-tenant architecture simplifies application management for the vendor. The multi-tenant model also simplifies the value for all customers since upgrades are instantaneously available across the entire platform.
The traditional rationale for outsourcing of IT systems is that by applying economies of scale to the operation of applications, a service provider can offer better, cheaper, more reliable applications than companies can themselves.
The use of SaaS-based applications has grown dramatically, as reported by many of the analyst firms that cover the sector. But it’s only in recent years that SaaS has truly flourished. Several important changes to the way we work have made this rapid acceptance possible.
Architectures for SaaS can generally be associated with one of four primary categories, or "maturity" levels.[11] Although the definition of these maturity levels arose from Microsoft, the styles and levels are agnostic of implementation mechanism, and purely identify tangible architectural concepts that any web-native SaaS application can relate to.
The first level of maturity is similar to the traditional application service provider (ASP) model of software delivery, dating back to the 1990s. At this level, each customer has its own customized version of the hosted application, and runs its own instance of the application on the host's servers.
At the second level of maturity, the vendor hosts a separate instance of the application for each customer (or tenant). Whereas in the first level each instance is individually customized for the tenant, at this level, all instances use the same code implementation, and the vendor meets customers' needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users.
At the third level of maturity, the vendor runs a single instance that serves every customer, with configurable metadata providing a unique user experience and feature set for each one. Authorization and security policies ensure that each customer's data is kept separate from that of other customers; and, from the end user's perspective, there is no indication that the application instance is being shared among multiple tenants. As multiple customers' data share one instance at this level, one customer's data can be logically/virtually separated from that of other customers. That is multiple customers' data may be saved physically into same data file. However, through the virtualization of an application, one customer can never see another customer's data.
At the fourth and final level of maturity, the vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer's data kept separate, and with configurable metadata providing a unique user experience and feature set for each customer. A SaaS IV system is scalable to an arbitrarily large number of customers, because the number of servers and instances on the back-end can be increased or decreased as necessary to match demand, without requiring additional re-design of the application, and changes or fixes can be rolled out to thousands of tenants as easily as a single tenant.
Because of the development and operational difficulty associated with both the more mature levels of architectural style as well as the mission-critical auxiliary components required of all SaaS applications, certain vendors have focused on creating tools to aid in SaaS development and operations. These vendors provide other ISVs commodity components that aid in the ability to convert an existing web/web service or wap-based products into a SaaS application as well as tools that reduce the amount of time and effort required to create a SaaS application from scratch.
These tools can reduce time to market and engineering cost and effort involved in converting a traditional on-premise software product into a SaaS solution or in building and deploying a new solution as a SaaS solution. Examples of enablement components range from pieces of software that provide functionality such as subscription management, to full-fledged SaaS platform products that provide a technology stack and application container for deploying a SaaS application.[12]
SaaS was originally considered a potential security and operational risk. Many businesses wish to keep their information technology operations under internal control. However, there is a counter-argument that the professionals operating SaaS applications may have much better security and redundancy tools available to them, and therefore the level of service may be superior in many cases. SaaS applications pose some difficulty for businesses that need extensive customization. SaaS vendors have made progress however, with both customization and publication of their programming interfaces. In addition, the availability of open source applications, inexpensive hardware and low cost bandwidth combine to offer compelling economic reasons for businesses to operate their own software applications, particularly as open source solutions have become higher quality and easier to install.
With products below the $100 range and its focus on the mid market, direct selling can become an expensive undertaking. SaaS companies are seeking alternatives by selling through VARs (Value Added Resellers) and similar alliance partners. But since SaaS is not only a different delivery mechanism but a different business model and different technology as well, selling through channels has its own challenges. A recent white paper published by the SIIA (Software & Information Industry Association) explains such differences to traditional software in more details