Blog

Using Multi-Tenancy for Higher Flexibility and Faster TTM

2023-12-12
< back to articles Blog post image

Growing revenue through new brands, B2B2x offerings and complex partner marketplaces becomes easier for telcos by using multi-tenancy to enable faster time to market and flexibility.

The Challenge

Today, communications service providers find themselves needing to quickly launch entire new brands, not just the usual new offers or products, to grow revenue from their networks. Whether by onboarding MVNOs, adding products and services from partners, or selling their own products through partners, telcos need BSS/OSS capabilities that help them achieve faster time to market and greater flexibility in developing these new revenue sources.

The Approach

Multi-tenancy accelerates the launch of new brands, marketplaces, and other partner offers by allowing telcos to reuse existing configurations, such as integrations and sub-workflows, and infrastructure across multiple logical instances, or tenants, of their BSS/OSS. This is done while sharing the same codebase, easily referencing data, and orchestrating cross-tenant processes across multiple tenants.

Multi-tenancy is a feature of Compax full stack BSS/OSS that allows CSPs to adjust and configure each tenant independently without impacting other tenants, which is essential when a new brand, MVNO, or B2B2x offering needs to be launched. Multiple business units, customers, and/or partners can participate as tenants in this multi-tenant environment, making it faster to deploy and efficient to operate while enabling complex cross-partner and provider-customer relationships.

How It Works

In Compax, a TENANT is a logical slice of the shared deployment instance. A tenant uses the shared codebase, the database, workflow microservices, integration interfaces, and templates to the extent reuse is needed.

Specific components and configurations for a tenant may include a tenant-specific UI, including tenant-specific clients and portals, tenant-specific business processes, tenant-specific integrations, Product Catalog configurations, taxes, invoice templates, notifications, customer account structures, and more.

Access rights for a tenant can be configured so that select users can only access tenant-specific data, while power users can access the full application across all tenants.

New Tenant Rollout

Rolling out a new tenant may be preferred over deploying a new application instance in some of the following use cases:

  • To support a new business model, such as B2C vs. B2B or B2G, that requires reuse of existing functionality, such as downstream or ERP integrations, while having its own separate set of products, customer accounts, processes, and accounting
  • To comply with GDPR or other government regulations so that sensitive data is clearly separated and handled in accordance with data privacy rules
  • To support a large customer, such as a Fortune 100 or B2G account, with large invoices, custom charging rules, complex promotions, or customer-access requirements
  • To quickly start up a new brand by reusing existing functionality and infrastructure without impacting other tenants' performance

To roll out a new tenant, a team would need to:

  • Create a new tenant via a click of button in the common configuration environment
  • Set up the new tenant's specific products, options, customer account structures, charges, taxes, invoice templates, and other required elements
  • Set up WebShop and eCare components, order management, CRM, and billing operations
  • Add tenant-specific payment gateway integrations
  • Create tenant-specific GL posting rules and configure tenant-specific ERP integration
  • Set up tenant-specific users and select roles
  • Define test and production deployment environments and deployment rules for the new tenant
  • Test the new tenant and then deploy it in the production environment

All of the above can be done in a fully agile way in a matter of weeks, depending on the amount of setup and reuse required.

Multi-Tenancy Deployment Options For Different Environments

It is important to understand that multi-tenancy is not just for production deployment. In fact, it starts from the configuration environment, which is natively multi-tenant in most cases. From there, your team has full freedom to define how your tenants are deployed to more environments, such as testing, migration, and production. They can also all be multi-tenant, or some can be multi-tenant while others are a single-tenant instance. It all depends on your preferences and business needs.

However, having a core configuration environment as multi-tenant greatly simplifies the agile CI/CD cycle for all tenants, reduces infrastructure and maintenance efforts, and optimizes infrastructure costs.

The example to the left shows a shared multi-tenant configuration environment for a global company with deployments around the world. It illustrates how they are using AWS in North America (NA), European Union (EU), Asia Pacific (APAC), and Australia-New Zealand (ANZ) areas, with multiple tenants deployed for each of the areas, but with overall control for all environments' configuration and deployment managed from the centralized configuration instance.

Benefits of Multi-Tenant BSS/OSS

The multi-tenancy ability to partition your BSS/OSS functions into different tenants has obvious advantages for security, operability, and performance that are particularly useful for rapid time-to-market when launching new brands, onboarding MVNOs, and onboarding OTT partners.

As shown in the example above, it can also provide operational benefits, such as balancing the infrastructure capacity across tenants depending on the load, allowing each tenant to have their own data and configurations while sharing core functionality, and making adjustments to individual tenants without impacting other implementations while maintaining overall control.

Compax's multi-tenancy feature delivers cost benefits as well. There are no third-party license costs, the capabilities are based on proven, widely available open-source products, and the genuine SaaS model is a straightforward licensing fee with right to use of all relevant modules, enabling unlimited use for multiple lines of business or brands within the same multi-tenant deployment.