Software as a service
From Wikipedia, the free encyclopedia
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), On-Demand and "Utility computing".
Philosophy of SaaS
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 Relations 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:
■ network-based access to, and management of, commercially available (i.e., not custom) software
■activities that are managed from central locations rather than at each customer's site, enabling customers
to access applications remotely via the Web
■application delivery that typically is closer to a one-to-many model (single instance, multi-tenant
architecture) than to a one-to-one model, including architecture, pricing, partnering, and management
■centralized feature updating, which obviates the need for downloadable patches and upgrades.
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.
ASP versus SaaS
The reason for moving away from the term ASP or application service provider is that the ASP generation
was merely traditional client-server applications with HTML frontends added as an afterthought. These
applications were hosted by third-parties who ordinarily did not have application development expertise,
but were only managing servers. Because the applications were not written as net-native applications,
performance was poor and application updates were no better than self managed applications. By
comparison, current net-native SaaS applications or independent portions are updated regularly, many
This gradual shift in the terminologies also is 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 as was the case in an ASP.
Early SaaS approaches were application service providers (ASPs) who ran a turnkey application on behalf
of their clients. But ASPs generally did not build the application themselves; rather, they took an off-the-
shelf application (such as a messaging platform, an enterprise resource planning tool, or a customer
relationship management package) and ran it for customers.
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, merely deployed one application
instance on a server for each customer, just as a customer would deploy internally. This inability to scale
this kind of business model may be cited as one of the reasons for the failure of the ASP model. 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 instantaneous available
across the entire platform. The notion that one customer (tenant) can excessively burden the service is
baseless and absent of fact. The largest current deployment of SaaS is by Wachovia, using a SuccessFactors
solution with 85,000 users, and the company anticipates an additional 25,000 users over the next two
Drivers for SaaS adoption
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.
Everyone has a computer: Most information workers have access to a computer and are familiar with
conventions from mouse usage to web interfaces. As a result, the learning curve for new, external
applications is lower and less hand-holding by internal IT is needed.
Computing itself is a commodity: In the past, corporate mainframes were jealously guarded as strategic
advantages. More recently, the applications were viewed as strategic. Today, people know it’s the business
processes and the data itself—customer records, workflows, and pricing information—that matters.
Computing and application licenses are cost centers, and as such, they’re suitable for cost reduction and
outsourcing. The adoption of SaaS could also drive Internet-scale to become a commodity.
Applications are standardized: With some notable, industry-specific exceptions, most people spend most of
their time using standardized applications. An expense reporting page, an applicant screening tool, a
spreadsheet, or an e-mail system are all sufficiently ubiquitous and well understood that most users can
switch from one system to another easily. This is evident from the number of web-based calendaring,
spreadsheet, and e-mail systems that have emerged in recent years.
Parametric applications are usable: In older applications, the only way to change a workflow was to modify
the code. But in more recent applications—particularly web-based ones—significantly new applications
can be created from parameters and macros. This allows organizations to create many different kinds of
business logic atop a common application platform. Many SaaS providers allow a wide range of
customization within a basic set of functions.
A specialized software provider can target a global market: A company that made software for human
resource management at boutique hotels might once have had a hard time finding enough of a market to
sell its applications. But a hosted application can instantly reach the entire market, making specialization
within a vertical not only possible, but preferable. This in turn means that SaaS providers can often deliver
products that meet their markets’ needs more closely than traditional “shrinkwrap” vendors could.
Web systems are reliable enough: Despite sporadic outages and slow-downs, most people are willing to use
the public Internet, the Hypertext Transfer Protocol and the TCP/IP stack to deliver business functions to
Security is sufficiently well trusted and transparent: With the broad adoption of SSL organizations have a
way of reaching their applications without the complexity and burden of end-user configurations or VPNs.
Availability of enablement technology: According to IDC,  organizations developing enablement
technology that allow other vendors to quickly build SaaS applications will be important in driving
adoption. Because of SaaS' relative infancy, many companies have either built enablement tools or
platforms or are in the process of engineering enablement tools or platforms. A Saugatuck study shows that
the industry will most likely converge to three or four enablers that will act as SaaS Integration Platforms
Wide Area Network's bandwidth has grown drastically following the Moore's Law (more than 100%
increase each 24 months) and is about to reach slow local networks bandwidths. Added to network quality
of service improvement this has driven people and companies to trustfully access remote locations and
applications with low latencies and acceptable speeds.
SaaS Maturity Levels
Architectures for SaaS can generally be associated with one of four primary categories, or "maturity"
levels. 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
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-architecting 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.
Factors Limiting SaaS adoption
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.
SaaS Sales Channels
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.