Shared tenant models are complex to pull off. They are hard to architect and design, but we chose to put in the work to build it anyway because they offer the balance and flexibility you deserve.
We know that your processes are complex, and demand flexibility. You do not need a quick and dirty solution, but a platform that can meet your needs and perform at an enterprise level both today and for a long time to come. That is why we took the hard way, we crafted Gov2biz on a shared tenant architecture.
In the short run, you may not even notice the difference, but over the life of your software use, it can make the difference between landing on the moon and getting stuck on a treetop.
Simply put, “you” are the tenant. You, along with all the data, documents, meta data, processes, and all the infrastructure, technology, and functionality to support you are collectively called a “tenant.”
Though it is an “under-the-hood” aspect, the tenant architecture is a fundamental design decision on any software product and platform. It is something that cannot change without a massive (read impossible) redesign. So, when choosing a specific product, you are also choosing its constraints.
Typical to SaaS products, is a multi-tenant model where all clients “live in the same place.” This is great for the SaaS provider, but comes with a downside for you. You are exposed to several constraints that you will not otherwise have, such as: lower flexibility in product fitment, control etc. While a multi-tenant model works great for routine, run-of-the-mill type software e.g. email, calendaring, chats etc. They are really constricting for enterprise grade apps that perform business functions.
The other extreme is a single tenant where every customer sits in their own silo. As every customer is in its own silo, every update must be applied to every single customer separately, and tested separately. {On for computer science majors}. As this is cumbersome, this disincentives updates as the number of customers for any product increases. And the updates become few and far between, and eventually stop.
In a shared tenant model, the core, unchanging functions, and subsystems are shared across tenants. Some examples include: webservices for external address validation, database lookups for list of states, to more complex functions like workflow engines. However the customer specific functions, and the core customer data lives in a separate environment. This creates the perfect balance : flexibility, and stability.