Enterprise applications that use a software as a service (SaaS), cloud delivery model have been prevalent in the marketplace for nearly two decades. Once-common concerns such as cloud reliability and data security have subsided as SaaS applications have grown to support mission-critical financial, human resources, customer management, and manufacturing services across organizations of all sizes. Many of the senior enterprise software vendors have shifted to a SaaS-based delivery model, as have most of their younger competitors, and with good reason. Done correctly, standardization of their customers on a common platform with a consistent feature set streamlines a vendor’s development process and lowers support costs. However, there are still some important factors to consider as the proliferation of SaaS applications explodes. This article identifies five key questions a CIO who is considering a business-critical application invest solution should ask of their SaaS vendor.
One: Are They Experienced?
There was a time when some SaaS vendors maintained hardware in their own data centers to support their early cloud-based delivery models. Today, it is more common for SaaS vendors to leverage one of the big public cloud providers to host their applications so that they can realize otherwise unattainable scalability, high availability and disaster recovery capabilities for their products. This shift to public cloud infrastructure and platforms have forced some SaaS vendors to change their underlying application architectures. For this reason, it is important to evaluate how good the vendor is at actually running their application in their chosen cloud. As any CIO who has moved workloads to the cloud knows, doing so in a manner that delivers all the benefits (scalability, high availability, disaster recovery) of the cloud while effectively managing the additional complexities (security, performance, containerization, etc.) can be challenging. This typically is not an issue for mature enterprise-class SaaS vendors like Salesforce, Workday, Dropbox, or Zen desk. However, smaller vendors, such as those offering important departmental applications, may not operate with the same level of cloud maturity. This lower maturity could contribute to problems like those experienced by popular services like Trello and Wix during the AWS’ February 2017 Simple Storage Service issue.
"To many CIOs, SaaS applications offer the allure of rapid implementations with fast return on investment in the form of measurable business value. In reality, there are sometimes some unforeseen challenges to rapid SaaS adoption, which leads to slower than expected realization of business value"
Two: Consume, Configure, or Customize?
Modern SaaS delivery models generally come in the three flavors: Pure consumption, where the application is used as-delivered with no additional features or functions beyond the same standard capabilities available to all users; configurable, allowing the customer to pick from among standard configurations to better align application functionality with business processes; and full coding platforms, like those from Salesforce and Service Now, which allow for extensive customization or modification of the application, or even development of entirely new stand-alone applications. Asking your SaaS provider which of these models aligns with their application delivery model is helpful. There are three reasons for this. First, extensive customization of a SaaS application can negate one of the primary benefits associated with SaaS –the SaaS vendor’s responsibility to perform all application updates - because maintenance of extensive, local customizations will be your responsibility, not the vendor. Second, developing customizations in the application platform might affect your application licensing costs, so get a clear understanding of these details before customization begins. Finally, full platform SaaS products may offer “application stores” of pre-built customizations that can be installed into the new application platform. These applications might bring additional, desired capabilities without the need for custom development of your own. Ask your SaaS vendor what the most popular add-on applications are for their platform and consider making those applications part of your ecosystem.
Three: How Fast Will My Investment Deliver Value?
To many CIOs, SaaS applications offer the allure of rapid implementations with fast return on investment in the form of measurable business value. In reality, there are sometimes some unforeseen challenges to rapid SaaS adoption, which leads to slower than expected realization of business value. Specifically, three factors can drag down rapid realization of SaaS application value unless you identify them and plan for them early in the implementation plan.
• Identity and Access Management (IAM): How quickly can the SaaS application be incorporated into your enterprise IAM system? How long will it take to define the roll-based access controls required to deploy the application? These are frequent progress killers during a SaaS implementation.
• External Data Integrations: These can consist of on-going data sharing between the SaaS application and other enterprise systems, or one-time data movements to seed the SaaS application with required data. For external data sharing, which external systems will the SaaS application need to integrate with, and how will those integrations be accomplished? “Using the API” is the usual response but what will be required to actually access the API in a secure, per formant, and scalable way?
• Training and Support: Even the most hotly anticipated new SaaS application risks failure if the users become frustrated trying to use it. Asking the SaaS vendor for examples of successful training and support plans for during and after deployment can pay big dividends.
Four: How Do You Handle the Fundamentals?
Twenty years ago, most CIOs took for granted the standard enterprise support underpinnings provided by their infrastructure and operations teams. Fundamental protections like regular application backups, and SLA-backed recovery options, may, surprisingly not be part of your SaaS vendor’s delivery model. For example, while industry CRM leader Salesforce does take regular backups of their customers’ application data, restoration of that data in the event of a recovery scenario will cost you $10,000 and should only be considered “after you have exhausted all other reasonable efforts to recover the data”. Further, the policy states that the recovery “process must be performed manually and usually takes a minimum of 6 - 8 weeks to complete.”While Salesforce clearly states this policy and recommends several third party solutions that provide much more flexible recovery options, this level of transparency may not be the case with all SaaS providers. Therefore, asking your SaaS provider some fundamental support questions like these can ensure that your assumptions are in alignment:
• Disaster Recovery: How often is my application data backed up? How would I initiate a recovery in the event of data corruption caused by human error, errant data loads, etc.? How long should I expect recovery of my data to take?
• Availability: How do you notify customers when performance or functional problems are occurring within the application? Most of the major SaaS players have dedicated sites for this, but smaller SaaS providers may not.
• Security: How do you notify your customers if a data breach occurs within your environment? How soon do you notify after the breach is detected?
• Enforceability: What mechanisms are in place to enforce vendor’s disaster recovery, availability, and security terms and conditions are being adhered to?
Five: What Data Do You Collect About Me?
All SaaS vendors collect data about your usage of their systems in the form of technology stack metadata and event logging. These application metadata sources collect metrics that are important to the SaaS provider, and which help the SaaS provider deliver their application to you in a reliable, scalable, and cost-effective way. However, you may want to ask the SaaS provider about the level of detail to this application metadata and for what that data is used. For example, even though a SaaS vendor won’t look into your application data to track your sales, the vendor may track the number of API calls you make to a service that is part of the SaaS application’s sales workflow process – essentially giving the vendor insight into whether your overall sales volume is trending up or down. Even less intrusive application metadata like the growth rate of the underlying storage assigned to your account still gives a SaaS vendor a broad view into whether your business may be expanding, or contracting. So a few questions about what types of customer-specific metadata are collected about your company and how that data is used is probably worth asking.