background

Software as a Service

At the SaaS layer of the stack, the cloud service provider is delivering all elements from infrastructure, through platform, to the application itself. The customer will typically pay on a “per user, per month” model. Depending on the complexity of the application, some level of engineering – e.g. customisation or integration – may be required in advance of deployment.

Theoretically, any enterprise application that a company may buy off-the-shelf and deploy on-premises can also be deployed via SaaS. In that regard, it is not as new as it is made out to be – for example, there have been hosted email services (rented on a “per mailbox per month” basis) for nearly as long as there have been email servers.

Many customers are “sold” on the idea of cloud-based applications – e.g. having a centralised service, readily deployed across multiple offices and roaming personnel, with layers of resilience – but are unsure of the ideal model for them. There are three high-level factors that must be evaluated.

Managed versus Self-service

In common with all hosting and cloud scenarios, the customer must evaluate how much of a management burden they wish to take on themselves. If they wish to manage the compute and storage infrastructure, plus the software and users themselves, a cloud solution may not be right and they would be better served by a colocation environment. If they want to a complete managed service, where all application and user management is provided for a fee, SaaS is probably the right option. Others will be somewhere in between.

Simple Application v Complex Application

This is a crucial determining factor in the SaaS decision-making process. A simple application would be email or a productivity tool like instant messaging or document sharing software. These can lend themselves very well to a SaaS model, as the deployment is usually “vanilla”. Complex applications include enterprise resource planning (ERP), customer relationship management (CRM) and line-of-business applications like inventory management, finance, and so forth. Often, the complexity of these applications means that customers prefer to buy their own application and manage it in-house. However, as SaaS has matured, the customisability has improved (see below) making it more viable for complex application hosting, especially for niche applications. For example, it is very common for businesses to use SaaS for HR applications as they are only used by a small team in the company for management with the majority of users accessing locked-down, basic functionality via a web browser.

Multi-tenant v Multi-instance

There is a subtle, but important, distinction between a multi-tenant application and a multi-instance application. A multi-tenant application is a large, monolithic, one-size-fits-all piece of software. All users/companies share the same core platform and it is only available in one “form”. This means that, if the cloud software provider upgrades the application or changes the user interface, the change applies to all users.

A multi-instance application puts multiple individual instances onto the multi-tenanted platform, e.g. it allows significantly more customisation and individual control as each customer has their own, virtual, version of the software. This means that no two instances will be alike and the customer has a level of control akin to that which they’d have if they had bought their own unique version of the application.

This may be a key determining factor, allied to the other two, to assess the “rightness” of SaaS for your business. For example, if it is a simple application like instant messaging, and you only wish for an off-the-shelf managed deployment, multi-tenanting is fine. However, if you wish to serve yourself with a complex application like CRM or telephony, multi-instance is needed or the company would be better served sourcing their own single-instance software.

pull out

Sign Up

To receive copy of the Up newsletter