In my previous blog I discussed about the business/technical aspects in single tenant and multi-tenant models. However, due to huge loads of information from various sources people are actually lost in deciding whether to go for multi-tenancy or not. In many cases ISVs are also influenced by the perceptions created by their peers/competitors. But one needs to understand that what works for one company does not necessarily work for another. So, the question boils down to “How do I objectively decide whether multi-tenancy is required for my business, product and domain?”
The following questions will allow you think through the various aspects that need to be considered while you make the decision on multi-tenancy support.
#1 What is the expected number of Customers on the SaaS model?
This question will help you answer if you are making the right investment at the right time. For example, let’s say you foresee only 10-15 customers in the next 1 to 2 years to be added in the SaaS model. In this case the investment of time and money to bring in multi-tenancy may not reap its full benefit. Multi-tenancy brings in lots of savings on the operational side. However, this saving is directly proportional to the number of customers on the SaaS model. Therefore, in a scenario where you have low number of customers there isn’t going to be much difference in operational cost between single and multi tenant. You might probably want to defer moving to multi-tenancy until you have decent number of customers on board.
#2 Do you have engineering budget constraints?
Of course, everybody has budget constraints. But say you have very little budget where do you want to spend the money – Do you want to spend it on engineering a multi-tenant system or Do you want to spend it on sales and marketing of your new SaaS version?
This is always a tricky question for ISVs. What is the point of building a sophisticated multi-tenant system if you don’t have money to market and sell it? Again, the key to be successful in SaaS business model is to have volume of customers. To that extent your sales & marketing will get more priority than spending on building a multi-tenant system.
#3 Do you have time constraints to release your SaaS version?
In today’s world every business is driven by time. Implementing multi-tenancy in to an on-premise product is going to take time. Multi-tenancy also brings in lot more other architecture aspects that need to be thought and planned for. For example, scalability becomes critical in multi-tenant scenario, which means every layer has to be thought through as to how it can be scaled and what technologies can be used to achieve the same. It’s not just the engineering that takes time, you product will have to go through rigorous testing on all multi-tenant functionalities as well as other non-functional requirements (like scalability, failover, etc.). Now all of this is going to take time.
The question to be asked is “Can the business wait until the multi-tenant solution is ready?”. What if you are only 2 months away from Christmas holidays and you want to release your product (say online shopping) before the holiday begins. Your business case may become obsolete if you are not releasing on time.
#4 Are you trying to experiment your SaaS solution in the market?
Some of the common questions that go through in the minds of ISVs are – Whether SaaS model will work for them? Will my customers even be interested in buying a SaaS solution? Will I be profitable in SaaS model? Can my team handle the business/technical aspects involved in SaaS model?
There is only one answer to all of these questions – Try it out!!! If you are in experimentation mode then it doesn’t make much sense to spend the time & effort in building a sophisticated multi-tenant system. Instead you may want a quick solution that can allow you to check if SaaS model really works for you.
#5 What is the scope/size of the SaaS transition?
In some cases the ISVs do not want to move their entire product to SaaS model rather they want some pieces (module/feature/reports) of it alone to be available in SaaS model. Again, in this case it may not justify spending a huge amount of time and cost in building multi-tenant solution. Instead it may be worthwhile focusing on the core product.
#6 How much of reusability are you expecting from the current product?
Some ISVs look for an out of box solution that can allow their current product to be reused as such. There are also scenarios where the product could be a legacy one due to which you may not want anyone to touch the code. Because implementing multi-tenancy requires engineering/code level changes to be done in the product. Alternatively, in a single tenant model your entire application can be considered as a black-box, which means you can 100% reuse what you have got.
#7 Are you customers extremely concerned about security/compliance issues?
You need to look at the domain/customer base that you are working with. While the adoption of SaaS is increasing every day across all industries, there are certain domains/industries that have very stringent security policies or audit compliances.
The whole idea of multi-tenancy is to share the same infrastructure/code/database/ and other resources to serve multiple tenants. This might come as objection from certain customers where they don’t like this idea of sharing. Interestingly, these customers do not mind paying for their own dedicated setup so that the environment belongs only to them. This facilitates the organizations to implement their own security policies, compliances and sometimes they may also want to audit this system. Now all of that is possible only in a single tenant model.
Please note that I am not advocating either the single tenant or multi tenant. I am only throwing light on
short term need vs. long term solution
business feasibility vs. operational efficiency
business requirement vs. over engineering
time vs. superlative solution
- Top 10 NFR in Software Architecture – Part 1 - December 1, 2022
- Top 10 Critical NFR for SaaS Applications – Part 2 - October 20, 2022
- Why enterprises should standardize Digital Application Management - July 17, 2017