Multi-tenancy is a software architecture that uses a single application to serve multiple customers (or tenants). Multi-tenancy allows you to create one application, then deploy it to as many customers as you want. This means you don’t have to recreate a separate solution for each end user.
Since multi-tenancy serves multiple customers, you will need to secure your solution in a way that prevents tenants from viewing each other’s data. We’ve seen this done well with online banking. The bank’s application is created once, but each end user receives individualized, secure information via multi-tenant security. Your embedded analytics solution should follow the same protocol. It should be robust enough to deliver value through a single solution, but versatile enough to deploy your solution to multiple customers.
To properly sure up your multi-tenant security application, you need to consider two key areas.
Key Consideration #1: Customer-Centric Solutions
Your team might receive a list of requirements that call for bespoke solutions, which are tailored to each user’s needs. Perhaps your customer wants your team to apply a particular styling with very specific layouts for end users. Configuring your embedded analytics solution in these cases should be fairly straightforward. You can reapply the definitions and configurations from your existing application’s framework or ecosystem to your new embedded analytics solution.
Key Consideration #2: Focus on the Data
Data is at the heart of every embedded analytics solution, and multi-tenant is no exception. You want to make sure that your data connection – or the data you’re delivering to your end users – is firewalled or constrained for each specific user. Separate tenants should not be able to see each others’ data.
Getting Your Data into Your Embedded Analytics Solution
You know you need data, so what’s the best way of getting it into your product? Does the answer depend on how you’ve defined your database? Finding the right answer means asking questions to drill down into what’s most important for your customers.
- Is your customer’s database shared by each unique tenant?
- Are the schemas or table definitions in your solution unique for each tenant?
- Has your application team created tables with just tenant IDs for filtering against?
Most applications teams structure their data differently based on individual business use cases, but there are some general guidelines that will apply to virtually all use cases:
- You should be able to connect to different data models and make sure your users can see just their specific data.
- You should be able to tokenize your data connections so you’re not bleeding data between tenants.
- You should have the capacity to filter data.
- You should deliver everything through a security mechanism.
- Multi-tenancy is a software architecture in which a single application serves multiple customers (or tenants).
- Multi-tenancy also means you can deliver a valuable solution once and there is no need to redo for each of the user endpoints.
- Embedded analytics solutions should allow for flexibility to connect to these different data models and show only their tenant-specific data.