SaaS vs On-Premise and what that means for everyone involved

The approach to delivering large enterprise vendor software has traditionally been on-premise. In this particular method, the client would use in-house servers and infrastructure within the company network to install and manage the software packages. This would typically involve the procurement and running of racks or blades of servers in a data centre. The internal technology teams would need to manage these environments from the basic procurement and set up of the hardware right through to the first line support of the applications, with the necessary help desk, service tracking, hardware and OS upgrades and so on. Other things like disaster recovery and security would need to be considered and handled. All this requires a significant investment in terms of money and manpower. For all but the largest organisations this would take a large percentage of the cost of running the business. The recent emergence of cloud computing and Software-as-a-Service (SaaS) is disrupting this traditional approach, but it equally throws up new problems and challenges.

Cloud computing is the practice of using a network of remotely hosted servers, accessed via the Internet or private gateway to store, manage, and process data, rather than a local server on a company’s private network or a personal computer. The cloud paradigm enables ubiquitous access to shared pools of configurable system resources and higher-levels of service from the provider, and can normally be swiftly provisioned with minimal management effort. SaaS extends the use of cloud to enable the vendor to provide additional services around the cloud hosted software, such as; configuration, upgrades, user management and general maintenance. The two terms are often confused but simply put, SaaS is a type of cloud computing.

Sophisticated enterprise software normally requires a degree of maintenance and on-going user support. When this type of software runs on-premise, the client would need an in-house IT service group that liaises and interacts with the remote vendor’s support group. Users raise internal tickets which the IT support group respond to, and raise back to the vendor where appropriate. The vendor needs to provide remote advice and support through the IT support team and can often talk the IT support staff through various steps to resolve the problem. This might involve use of error logs and in some cases telephone conversations and help desk interactions. For security reasons, the vendor would not have direct access to the client’s production servers. These types of scenarios can be time consuming and are not particularly efficient for the end users. The quality and experience of the internal IT support “middleman” would be vital to ensure a smooth process. IT resources can leave the company, get promoted or take vacation. There is potential for key-man risk. A major advantage in a SaaS deployment is that the vendor has direct access to both the production server and the users. There is no middleman. Problem resolution is much swifter.

With cloud computing solutions such as Azure, AWS and Google Cloud, environments can be swiftly ‘spun up’ and shutdown. This is useful during upgrades and test cycles and generally during project implementations. Existing environments can also be up-scaled or down-scaled easily. As the use of the system grows, the underlying infrastructure can grow with it. Likewise, if a server is not needed it can be switched off, reducing costs immediately. Many in-house data centres have racks of redundant servers, wasting costs, power and space.

The use of Cloud and the emergence of SaaS has risen considerably over recent years and momentum is growing. The worldwide public cloud services market revenue reached $260 billion in 2017, up from $216 billion in 2016. SaaS revenue grew 21% in 2017, reaching nearly $60 billion. The forecast for further growth is significant and it’s easy to see why.
Catalysts for growth are many:-

  • Faster implementation
  • Ease and speed of setting up new environments and upscaling
  • Scaling cost management against running internal data centres
  • More efficient and direct support services
  • Global reach
  • Use of shared services
  • Swifter upgrades
  • Flexibility of infrastructure needs

Of course, some challenges remain when moving to SaaS, on both the client and the vendor sides. For the clients, who have typically run enterprise software on-premise, there are several potential stumbling blocks – both politically and technically. There could be some internal resistance to change and the potential reduction in internal IT headcount that would ultimately take place. The reduced direct costs are welcome at a senior level but not necessarily at ground level. The other challenge is one of security and data transfer. Often, the cloud deployed software must integrate and interact with in-house data and systems. Data has to be transferred to the cloud in a secure and swift manner. This could require changes to well-established IT security policies and technical set up, such as firewalls and data usage policies. Data bandwidth to the remote cloud software is also a factor and would need to be comparable to in-house network speeds to be accepted by the users.

For the vendor, cloud and SaaS is an effective way to sell and deploy enterprise solutions and has great benefits including faster implementation and more efficient support. However, software vendors need improvements and fundamental changes to their traditional organisational structures in order to provide such a service. In house Dev Ops teams are required to provide the services previously provided directly by the vendor. New teams and processes need to be put in place to make this happen effectively. Suddenly, the vendor is looking after a client’s confidential, mission critical data. This requires many internal capabilities and policies. Firstly, the privacy policy of the vendor needs to reflect this change. Security policies need to be upgraded, or in some cases, put in place from scratch. Various regulatory standards would need to be implemented, such as ISO 27001 and SOC-2. The recently introduced GDPR rules impose further restrictions and controls around holding third party data. On the technology side, encrypted, secure data transfer tools need to be developed and implemented. Data breach, cyber security and penetration testing need to be done on a regular basis. Disaster recovery strategies would need to be implemented. The software itself needs to have technical foundation to make it easily accessible over the internet. Thin-client, multi-tier architectures are much more suited to cloud deployment than more traditional, fat-client software packages where more technical complexity of user interaction would need to be overcome.

For the clients, it’s clear there are multiple benefits, efficiencies and cost savings to be had. The biggest challenge with any transformational change is culture – if the whole team aren’t bought in then life can become very difficult – and the cost of getting it wrong is unthinkable!

For the vendors, there are also a great many benefits, but the road to success is not easy. It’s not simply a case of notifying the marketplace that your software can run in the cloud! Technically this may be true, but your clients will expect a whole lot more.