OEM Architecture

You can rebrand and white label Sisense to make it suit your company's application or web site. You can also embed Sisense directly into your web site. Delivering analytics to customers through white labeled Sisense and/or embedded Sisense rely on strict data governance to ensure that your tenants get access only to their own assets and data.

This type of governance can be achieved using a few different OEM architectures:

• Single tenant
• Multi-tenant
• Hybrid
• Sisense cloud

The selected architecture depends on your requirements, preferences, and the resources that you can dedicate to the deployment. Sisense provides the flexibility to support OEM deployments in the way that you want to work.

This topic outlines a few different ways to support OEM and it describes the benefits and disadvantages of each.

Single Tenant

A single tenant architecture provides a dedicated Sisense server for each tenant. This deployment architecture is suitable when there may be restrictions that mandate that data of different tenants cannot be located on the same physical machine.

Advantages: Highest level of security and dedicated resources per tenant

Disadvantages: Low resource utilization, high hardware costs, and complicated asset change management

Typically Best for: Tenants with strict security regulations, such as financial or healthcare institutes, and tenants that need a high level of schema and dashboard customizations

Data Models

Typically, you will have your own instance of the server, including default Live models and ElastiCubes. The Live models and ElastiCubes can be identical between the servers, or customized for each of the tenants. The data for each tenant is completely separate as each server has its own assets, including configuration, users, and data models.

Dashboards

Single tenancy offers a high level of customization per tenant. Each tenant has their own dashboards which can be modified to accommodate the tenants' specific needs, without affecting any other customers.

Other Assets

Single tenancy also provides a very high level of governance and security for each tenant. You can be assured that no tenant can access assets of another tenant. Additionally, the system behavior of one tenant will not affect other tenants. If there is a heavy system load caused by multiple queries or reports generated by one tenant, it will not have any effect on the other tenants.

Considerations

Underutilization: A tenant's server may be underutilized if it is not used throughout the day. Or, if most of the users reside in the same time zone, the server may be idle for long periods of the time. Additionally, a Sisense server is a high performance server and is capable of supporting a large number of concurrent users. If a tenant doesn't have many users, the server may be underutilized, even during work hours of the tenant.

Maintenance: If you need to make a change to your data model and dashboards that you provide to tenants, then all the changes will have to be made on each one of the servers individually. For example, if you want to create a new dashboard and share it with all of their tenants, you will have to copy the dashboard to each one of the tenants' servers. This could be very time-consuming if done manually. However, you could use the Sisense REST APIs to automate the deployment process, which would simplify this process.
process.

Multi-Tenant

Option 1: Shared Data Models and Dashboards with Row-Based Data Security

Advantages: Low hardware costs, high resource utilization, simple asset change management

Disadvantages: Tenant resource usage may affect other tenants

Typically Best for: Tenants with identical data models and dashboard requirements

The first type of architecture for OEM deployments utilizes shared Sisense servers for multiple tenants, and shared data models and dashboards. Segregation between tenants is achieved by using row-based data security within Live Data or the ElastiCubes. All of the customer data resides in a shared data model, but each of the tenants gets access only to their own data.

This methodology makes it easy to maintain system assets, and handle changes that occur during the life-cycle of the asset. Modifying the data model schema is done only once in the shared data model for all users. Changing the shared dashboards is also done once for all users.

This methodology is well suited for customers providing a service based on identical data sources and reports. For example, a customer analyzing shopping statistics for tenants on a shared shopping portal will take data for all of the customers from the shopping portal analytics data using each tenant's credentials. But all of the data has the same exact structure, so the generated dashboards are common analytics of this data.

This methodology provides good utilization of server resources, and ensures that asset maintenance remains easy.

The server is shared by multiple tenants, so they are also sharing resources. High resource usage by one of the tenants (for example, generating multiple reports or heavy builds that require a lot of CPU) could affect other tenants.

Option 2: Dedicated Data Models and Dashboards per Tenant

Advantages: Low hardware costs for small number of tenants, complete isolation and security (no shared assets)

Disadvantages: High hardware and operational costs for large number of tenants, more complicated asset change management, tenant resource usage may affect other tenants

Typically Best for: Tenants who require customized data models

This architecture for OEM deployments uses shared Sisense servers for multiple tenants, together with providing dedicated data models and dashboards for each tenant. In this deployment, multiple tenants use the same server. Typically, the OEM has default data models and dashboards, and creates a dedicated copy of them for each of the tenants. The data models and dashboards can be identical copies for each of the tenants, or customized per tenant. The OEM uses access control for data models and dashboards to ensure each of the tenants only has access to their own data. Typically a user group is created for each of the tenants. All of the tenant's users are assigned to the same group. The relevant data models and dashboards are shared with the tenants group. In this way, the asset access control layer ensures that users of each tenant only has access to their own data.

This methodology is well suited for customers whose data sources aren't identical. It allows for customizing the data import process so that the data preparation and ETL processes can handle the specific customers data structure, and transform it to the desired target structure. This methodology is also well suited for tenants who have different reporting needs. While the tenant is initially provisioned with default data models and default dashboards, customizations can be made per tenant, without affecting other tenants. It is easier to accommodate the specific needs and requirements of each tenant.

In this use case, the OEM needs to manage multiple copies of data models and dashboards. Making a change to a data model schema or to dashboards needs to be replicated across all of the tenants. When there are many tenants, the cost of making changes to assets is high.

This methodology provides better utilization of the server, and can reduce the cost of ownership as multiple tenants are sharing the same server. But as with the previous option, shared servers means that multiple tenants are also sharing server resources. The behavior of one tenant may affect other tenants using the server.

With this solution, you need to consider how the system scales to support your future needs, to support additional tenants. For example, there are limitations to the number of ElastiCube s that can be deployed on a single machine. Although initially you enjoy shared server resources, as you add more tenants, you might have to provision additional servers, increasing the hardware costs of this solution.

Option 3: Dedicated ElastiCubes per Client and Shared Dashboards

Advantages: Low hardware costs for small number of tenants, isolation of data between tenants, minimized dashboard maintenance overheads, high resource utilization

Disadvantages: High hardware costs for large number of tenants, tenant resource usage may affect other tenants

Typically Best for: Tenants whose data needs to be kept separate from each other for security needs, or due to data pipeline processes in place that cannot be changed while the data models and KPI requirements for each tenant are exactly alike.

In a slight variation to the second architecture, if each tenant's data models have similar structure and each tenant has similar KPI needs, you can reduce the overload of maintaining dashboard repetitions by keeping the data models separate, but share the dashboards among tenants. This way you do not have to maintain multiple sets of the same dashboard for many different customers in addition to a large quantity of different data models. This architecture for OEM deployments uses shared Sisense servers, a separate data model per customer, and the same dashboards for multiple tenants. The OEM uses access control for data models to ensure each of the tenants only has access to their own data. Typically, a user group is created for each of the tenants. All of the tenant's users are assigned to the same group. The dashboards are shared with everyone. Based on the logged-in user, the Dynamic ElastiCube Plugin will switch the dashboard to query from the relevant underlying data model. In this way, users of each tenant only get access to their own data.

This methodology is well suited for customers whose data sources are identical but security or other constraints require the data models to be separate.
In this use case, the OEM only needs to manage one copy of the dashboards. Making a change to a dashboard is instantly replicated across all of the tenants. When there are many tenants, the overhead of making changes to dashboards is low. While you still have to maintain copies of the data models for each tenant, the Sisense APIs can be used to automate the deployment of new tenant data models.

This methodology provides better utilization of the server, and can reduce the cost of ownership because multiple tenants share the same server. But, as with the previous option, shared servers means that multiple tenants are also sharing server resources. The behavior of one tenant may affect other tenants using the server.

With this solution, you need to consider how the system scales to support your future needs, to support additional tenants. For example, there are limitations to the number of ElastiCube s that can be deployed on a single machine. While initially you enjoy shared server resources, as you add more tenants, you might have to provision additional servers, increasing the hardware costs of this solution.