The Pros and Cons of SaaS vs On-premises Deployment
Choosing the right deployment model requires considering many aspects, including integrations and upgrade cycles. In this post, I compare the Saas (Software as a System) and On-Premise deployment models.
Clients commonly ask us to help them decide whether a SaaS (Software-as-a-service) or an On-Premises deployment model would be best. This happened recently in a software selection project for a mid-sized life sciences client.
There are many factors that a business must consider when deciding if SaaS will provide advantages. And with the rapid growth of SaaS, it’s a decision that more and more businesses are going to be making.
The use of SaaS has skyrocketed over the past few years. Gartner estimates total SaaS spending will exceed $22 billion in 2015, an increase of more than 57 percent from the $14 billion spent in 2012.
Reduced total cost of ownership (TCO) is the primary and most attractive benefit driving SaaS adoption. SaaS vendors have long touted the benefits of multitenancy, a software architecture that allows many users to share a single application instance while retaining their own separate information.
Multitenancy cuts costs by allowing vendors to patch and update the software for many users simultaneously and allowing many users to share the underlying infrastructure.
But the SaaS deployment model is not without its own challenges.
I remember reading once that up to 20 percent of attempted SaaS deployments fail due to serious problems with data integration.
And that is just one of the problems facing the rapidly-growing movement toward SaaS. It is extremely important for businesses to carefully analyze the advantages and challenges of the various deployment models in all phases of a system lifecycle before adopting one.
Is SaaS right for you? Here is a look at the pros and cons.
|Aspect||Single-tenant SaaS||Multitenant SaaS||On-premises|
|Implementation||Relatively faster to implement as it leverages a ready-made platform which has already been provisioned, implemented, and tested by the vendor.||
|Customization||Customization is relatively easier compared to Multitenant SaaS if application provides the flexibility.||Customization may not be possible as the application instance will be shared by multiple users.||Most flexible option for customization. Vendor involvement minimal.|
|Support & Maintenance||
||You own the responsibility for upgrades, which are often expensive and time-consuming.|
|Security||With high-end vendors, SaaS systems can be highly secure with expert supervision of network and server security.||Additional time and software for security required.|
|Validation for Regulatory Compliance||Vendor will provide baseline validation for your review.Enforcing regulatory requirements is easier compared to Multitenant SaaS due to complete control of the environment.||Vendor will provide baseline validation for your review.||You will be responsible for the full validation effort.Enforcing regulatory requirements is easier compared to Multitenant SaaS due to complete control of the environment.|
|Integrations||Integrations with other corporate systems can get complicated because data will often be sent over the internet. SaaS vendors should have well-defined web services as integration points.||Integrations can be relatively simpler over the intranet. Data transfer between systems will be faster.|
|Scalability||As the enterprise grows, solutions can be easily scaled up with little time and effort. Similarly, solutions can be scaled down without wasting resources.||Needs longterm planning and commitment of resources for scaling.|
A detailed analysis to compare costs of different deployment models across vendors must be performed in order to determine the lowest-cost deployment model. The following format is a good a way to document and compare longterm costs.
|Vendor||Number of Users||Deployment Model||Initial Cost||Implementation Cost||YoY Maintenance||5-Year Outlook|
Which deployment model will be best for your situation depends on a variety of factors, including:
- Availability of skilled resources during implementation & support phases.
- Criticality of the data stored.
- Size & culture of the organization.
- Nature of integration requirements.
- Control over the environment for customizations.
- Regulatory constraints.
In the case of our recent client, public SaaS was not an option because of the regulatory requirements around validation of the system per the client’s documented procedures. Additionally, On-Premises application support had been a major challenge for this client due to constraints related to skilled IT staff. So we recommended Private SaaS as the solution.
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!