Posted on 23 July 2008 by James Blake

Software-as-a-Service solutions tend to differ from on-premise ones and to understand the true costs of a system the differences in approach need to be considered. 

Often on-premise solutions will be comprised of a series of different technologies or point products that may all come from the same vendor, or even different ones. 

Each component fulfils some part of the desired functionality, often with some element of overlap with the other components.  The components are focused on the technology of some partial aspect of the solution, not the business need driving the need for the solution in the first place.  All these components then need to be integrated together to provide the solution to the business need.

Unfortunately, component solutions often do not play well together, especially when they are sourced from different vendors. Even if a majority of the components come from the same vendor they may not work together, especially if the vendor has acquired the technology through acquisition.

In order to get the fragmented series of components to operate as a whole either an integrated provisioning and reporting overlay needs to be built to fit in with the way the customer works or the customer must compromise or adapt some of their business practices to fit in with the system. Collective experience of failed government and commercial integration projects shows that the first of these options rarely works and the second, making users adapt their already complex working lives, results in deviations from policy and procedures as users find ‘shortcuts’.

Outside of the information technology sector, an organisation’s core business is rarely that of supplying IT services.

Trying to build a business solution based on technology components is often a distracting, expensive and frustrating business.  While each component may have a compelling user interface and reporting system when operating together, the organisation has to choose either a fragmented approach to policy enforcement and reporting, or accept a low level of granularity.

Trying to build a solution from multiple point solutions doesn’t just involve increased management and integration costs, it also requires time spent investigating different the vendors and how they integrate together, followed by due diligence and meeting with each individual vendor.

On-premise solutions also involve on-going migration costs - hardware and software goes end-of-life every few years.  The customer may need to pay upgrade costs for the latest version of the solution and professional services costs to migrate data to the latest format.

Software-as-a-Service may, at first, seem more expensive when compared with a single on-premises component  - but when the true costs of vendor investigation, due diligence, tender process, component integration, management and other soft costs such as loss of productivity due to a mis-match between the business requirement and the actual reality offered by the fragmented solution – SaaS looks much more compelling.

SaaS solutions rely on constant innovation and providing working solutions for customers to enable customer retention.  SaaS is a subscription model, if the solution fails customers move elsewhere.  This is in contrast with on-premises solutions where the large capital expense of purchase and the difficulties of integration are mammoth hurdles. Once an organisation has overcome these issues, it often feels itself compelled to continue with a solution, even if it is sub-optimal, to try and get as much value as possible before having to start the whole painful process again.  

The barriers of entry to a SaaS solution are low and the barriers for exit are low too – the financial and business risk for trying a SaaS service are, in most cases, minimal.  With on-premise solutions, you won’t normally find out if it works in a production environment until after you have incurred the expense and pain of implementation.

It is hard to just compare the cost of a SaaS service against that of a set of on-premise components by spreading the aggregate subscription cost of the SaaS solution across the lifetime of the on-premise components.  If the business solution is needed on an perpetual basis, migration and renewal costs also need to be factored in.
 
So, in summary, when comparing costs for a SaaS service against an on-premise solution, consider the following:

  • How many component point solutions are required to give the required coverage of the business problem?  Consider the cost of researching vendors, the tender process and any evaluations (including employee time to work with the vendor during installation).
  • Does either the SaaS or on-premise solution offer additional features that can be of use in future projects?  For example, a customer choosing Mimecast for email continuity obtains a solution for email Data Leak Prevention, archiving and discovery by default.  Consider the cost of deployment of these additional features going forward -, it might be a project for next quarter or beyond but you can save yourself a lot of future pain and money by making the right choices now. 
  • What is the cost of staff to replicate policy information among all of the disparate management interfaces of on-premises point solutions?  If a unified provisioning and reporting interface is being constructed, - what is the cost of building this interface and what is the cost of lost features due to the loss of granularity.
  • What is the cost of paying several different support contracts for multiple vendors? What are the human costs of logging and tracking calls to several different vendors when an issue occurs? What is the cost of investigating which on-premise solution is responsible when an issue occurs?

For many organisations, no price can be put on the ability to focus on their core business and not be bogged down with technology integration issues – this is the priceless enabler that SaaS provides.

Category: Software-as-a-Service