Five Points to assess fitment for a SaaS solution

[Former Member]

SaaS is gradually emerging as the fastest growing segment among the different Cloud Consumption models. SaaS increases the business-agility of an organization by offering ready-to-run scalable solutions based on industry best-practices through a subscription based model, thus helping SaaS-consumers to reduce their TCO by slimming down their IT footprint with significantly lesser efforts for upgrade or maintenance etc. However, in my opinion, it may be prudent for organizations to assess the fitment of any SaaS solution on the basis of the 5 points below –

1. Adherence to Regulations – There can be legal guidelines for hosting business-sensitive data on any server or data-center without adequate security measures. I have seen in few documents that suggest that according to Payment Card Industry Data Security Standard (PCI DSS) standards all credit / debit card holder information must be stored behind the company’s firewall which again should be configured according to PCI DSS standards and assessed during PCI DSS audits. Hence for such organizations, it may not be possible to host such sensitive data on a third party’s data-center / server in an attempt to consume a SaaS solution, by compromising on the security controls, data protection standards etc. Similarly organizations in the healthcare industry may think twice before running some of their business applications through SaaS due to the requirements around privacy of patients and confidentiality of clinical investigations. For instance, a SaaS supplier offering SaaS services to the US health care and insurance sector should ensure that the SaaS solution supports compliance with HIPAA obligations. Besides, some countries can have regulations around where data can be stored and moved with respect to their national boundaries and hence they need to be circumspect about the data location within a SaaS vendor’s infrastructure, before choosing any SaaS solution. Another case can be that a public company which is under the purview of the Sarbanes-Oxley Act may require that the SaaS vendor receives a certification on relevant auditing standards, which ensures that the vendor has appropriate controls in place to meet the customer’s audit requirements.
2. Requirements for Customization – From a ‘Buy Vs Make’ perspective, a SaaS solution is tilted more towards the ‘Buy’ rather than ‘Build’. This can be particularly true under a multi-tenant model where all subscribers have identical schemas, thus limiting customization options for each customer (trade-off between scalability and customization). Hence, an enterprise should be willing to adapt their current business processes to the SaaS solution standards. Besides, since the SaaS vendor is expected to continuously build in the best practices into their solution according to the industry standards, the solution can be subject to change. For example, new releases by SuccessFactors are made available to all the tenants (instances), although by default, all new functionality is switched off unless an enterprise decides to enable any of those new functionalities. But if any organization has complex customization requirements, then a cloud-based standard SaaS solution is not recommended in my opinion. For example, an enterprise with fairly complex customization requirements for its HR processes may prefer an on-premise SAP ERP HCM solution over a SaaS option via SuccessFactor’s Employee Central. On the other hand if enterprises have already invested in an SAP ERP HCM on-premise solution, it make sense to opt for SuccessFactor’s Talent Management or Workforce Analytics to complement its core HCM solution, rather then making an investment of time & effort to implement the same on-premise.
3. Provisions for Data Isolation – SaaS solutions are inherently multi-tenant. Hence enterprises should check with the provider on the type of data isolation offered by the SaaS provider, in order to avoid any risk of commingling of data. Since competing organizations (from the same industry) can be subscribers to the same SaaS solution of a given vendor, it is recommended that the SaaS subscribers understand the type of data segregation offered by the SaaS provider. After going through some of the SaaS related articles on the Net, I have come across different approaches of multi-tenancy: a) Database per Tenant (offering the highest levels of data isolation) – this model required more hardware and maintenance efforts on behalf of the vendor, thus making it a more costly solution when compared to the other models, b) Distinct Database Schema per Tenant where each tenant has its own set of tables that are grouped into a schema within the same Database (e.g. in SuccessFactors tenants are logically separated at the database level, complete with their own database schema, though the schemas are identical), and c) Shared Database with Shared Schema amongst multiple tenants with each tenant data segregated by a tenant-id within the physical data records. This third model offers the least amount of data isolation, and is also the least costly one as the hardware requirements are at a minimum. Hence as we move from one model to the other, we can observe that there is a trade-off between costs and data security features.
4. Performance Assurance – A SaaS solution typically resides on the vendor’s (or another third party’s) data center and the connection between the on-premise systems and the SaaS solution is typically over the internet. Thus the performance of the SaaS solution should be measured before putting any mission critical application on the SaaS. I feel that enterprises should primarily check for the response time or availability levels (i.e. assess the fail-over features or fault tolerance designs of the underlying architecture) of the SaaS solutions, and try to document establish well defined SLA’s (service level agreements) with the SaaS vendor through formal contractual agreements. This is important, since unlike an on-premise solution the organization would have far lesser control on the SaaS infrastructure. The DOU or Service contract between an organization and the SaaS provider must cover for service-level agreements (SLA’s) that guarantee the expected levels of performance (response time, availability etc.) and should also document the mitigating actions as well as the remediation measures e.g. penalties that the vendor will be subjected to, in the event it fails to meet the SLA’s. It is important for an organization to check with all stake holders (including representatives from the ultimate end-users of the SaaS application) on the acceptable performance levels of the solution, before agreeing upon the SLA’s with the vendor.
5. Integration Efforts – Many organizations have a hybrid cloud strategy, where cloud-based SaaS solutions need to be integrated with on-premise applications—making integration critical. SaaS vendors that offer API’s for easier integration offer distinct advantages over others. According to my understanding the SAP HANA Cloud Integration (HCI) is SAP's integration strategy for integrating on-premise SAP ERP solution with SaaS solutions like SAP Customer OnDemand, SuccessFactors BizX etc. Through HCI, SAP offers predefined set of integration content, thus enabling organizations (those who have registered on HCI) to implement their integration project with lesser time and efforts. In absence of HCI, integration can be achieved through an on-premise SAP PI solution, though it would have its typical procurement lead time followed by development. Another commonly used integration tool is IBM’s WebSphere Cast Iron Cloud Integration tool. If one looks into some of the literature around Cast Iron,then one would understand that WebSphere Cast Iron Cloud integration includes several reusable Template Integration Processes (TIPs) that contains templates for most of the common SAP-to-Cloud integration scenarios. WebSphere Cast Iron Cloud integration also provides data cleansing & migration capabilities, which enable organizations to move data from on-premise SAP systems to Cloud applications and thus expedite their SaaS implementation. In summary, any SaaS implementation project would have an integration phase where multiple skilled resources working over a period of time may be a requirement. Thus every organization should estimate the budget and efforts required for SaaS integration, before choosing a specific SaaS solution.

Before I conclude this blog, I would like to mention that the suggestions or thoughts that have been put up here are my personal opinions about SaaS implementation check-points, based on my self-study / research of several articles / white-papers and blogs etc.