In my previous post, I explained how the adoption of SaaS increases the frequency of software releases. I described the challenge this poses to regulated companies who must validate each release to establish its continued fitness for purpose. The options available to address this challenge vary according to the specific deployment model the vendor chooses. Regulated companies would do well to understand the differences between single- and multi-tenancy deployment models. Armed with this understanding, they can ask pertinent questions when selecting vendors, negotiating contracts, and planning their internal QA activities and resource needs to keep the SaaS software in a validated state.
Multi-tenancy describes a scenario where the vendor hosts multiple customers on shared infrastructure (databases, servers, etc.). When the vendor deploys a software release to that infrastructure, all customers sharing that infrastructure receive it. This reduces the effort to execute each deployment and greatly simplifies application monitoring to ensure smooth operation.
These gains in deployment efficiency come at a cost: in a multi-tenant deployment, there is no way to deploy the release to some customers and not others. Either the infrastructure is upgraded, or it is not. For this reason, multi-tenancy deployments are triggered on a push model – that is, the vendor pushes them out to everyone at the time of the vendor’s choosing, ready or not.
For SaaS deployed on the multi-tenancy model, skipping releases is not an option. Regulated companies that must validate every release must keep pace with the vendor’s release schedule, or find themselves out of compliance. If the vendor deploys new releases monthly, then the regulated company has less than a month to perform risk analysis and plan and execute acceptance testing to stay in compliance.
Single-tenancy describes a scenario where the vendor hosts every customer on dedicated infrastructure. That infrastructure is provisioned and managed by the vendor. Single-tenancy theoretically allows each customer to run separate releases of the software; their choice to upgrade or stand pat has no effect on other customers. It represents a greater management burden on the vendor, who must cope with supporting multiple releases.
Single-tenancy theoretically affords the customer flexibility on the precise timing of deploying the release. The customer may apply the release on-demand, schedule it in advance with the vendor, or skip it completely. The customers’ validation activities need not be completely dictated by the vendor’s release schedule, as it is with multi-tenant deployments.
In practice, there are limits to this flexibility. To manage the costs associated with supporting multiple releases across their customer base, single-tenant vendors often insist on contractual limits on the number of releases the customer can fall behind. They may limit the time window for accepting a release, and force customers who miss that window to wait for the next release.
These differences between multi- and single-tenancy deployment models suggest the following questions to ask of SaaS vendors:
Asking these questions during the vendor selection and contract negotiation phase will facilitate ongoing compliance with applicable regulations. Achieving continuous validation of SaaS software is ultimately the regulated company’s responsibility, but it helps to start with a clear understanding of how your SaaS vendor will help you achieve it.
Jan 17, 2020
KSM Technology Partners
