There has been much debate over the benefits of single-tenant vs. multi-tenant architectures in software-as-a-service (SaaS) environments. And while those in favor of single-tenant will often tout customization as a key advantage, we believe this is short-sighted, especially when you consider some of the common concerns and complaints among on-premise customers.
Who Decides What Enhancements are Made?
All on-premise vendors maintain a product “wish list”, which includes those capabilities requested by customers. naturally, at the top of the list are customization requests from the largest customers. Development teams and product managers review the list, and determine which capabilities go into the next release and which ones don’t. Their decisions are based partly on the needs of the market, and partly on the company’s need to launch the new version on time. In other words, most on-premise customers have little or no influence over what goes into the next version. That privilege is reserved for the largest and most profitable clients, or internal stakeholders on the vendor’s side.
Upgrade Disruptions Can Be a Nightmare
Major releases are planned an average of every 18 to 24 months, and include most of the items that are needed to address customer demands (especially customization requests from the largest customers), combat competitive issues, incorporate advanced technologies, etc. The reason for the extended time between releases is that vendors know that the upgrades will be complex, and will cause massive disruptions to users. In some cases, these disruptions are so severe that customers consider other alternatives (i.e. competitive or SaaS solutions) instead. So, the vendors want to combine as many possible enhancements into a single upgrade, thereby making these disruptions infrequent.
Vendors Need to Avoid Multiple Releases At All Costs
Development teams for on-premise solutions have one thing in common – they will all do everything possible to prevent having more than one version of a product. The dreaded “special release” to satisfy a favored customer or win a big deal is avoided whenever possible. But the needs of the business – and more importantly, those of the customers – often call for multiple versions. Managing these then becomes a nightmare for development teams, as well as the customer support and field service organizations. It is also often the precursor to a failed product, and an inability for the vendor to remain viable.
Where Single-Tenant Falls Short
Proponents of single-tenant infrastructures will claim that they rectify this problem, providing an advantage over both on-premise and multi-tenant SaaS offerings. All SaaS solutions – whether single or multi-tenant – eliminate the need to go through cumbersome upgrades. All upgrade work is performed by the SaaS provider, and the advantages in terms of time and cost savings can be tremendous. However, in single-tenant scenarios, clients who request their own version of the solution may experience a downgrade in support services and future customizations as the vendor’s business grows. Why? Because a successful vendor with hundreds of customers simply won’t be able to support hundreds of different versions of its offering.
The bottom line is, from a customization standpoint, there really is no difference between an on-premise and single-tenant SaaS.
Why Multi-Tenant is More Customizable
On the other hand, a multi-tenant vendor can concentrate all development resources on a single version of the product. This is a far more productive – and more profitable – approach, allowing for greater frequency of upgrades and faster delivery of the features customers demand. In a way, SaaS vendors facilitate a continuous customer advisory board, collecting client feedback on an ongoing basis, and instantly taking action based on it. For example, while on-premise or single-tenant SaaS vendors may deliver upgrades just once every two years, multi-tenant SaaS vendors may roll out new capabilities dozens of times each year. And, unlike on-premise or single-tenant tools, these upgrades are pretty much transparent to the end user.
Customization capabilities are often built right into the product itself, in the form of flexible set up options. But, most importantly, the inherent design of true multi-tenant SaaS offerings makes them not only highly customizable, but very easy to integrate, without the need for extensive code changes.Customization in Single-Tenant vs. Multi-Tenant SaaS Architectures Click To Tweet