Using Multi-Tenancy for Higher Flexibility and Faster TTM

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 it’s by onboarding MVNOs, adding products and services from partners, or selling their own products through partners, telcos need BSS capabilities that helps 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 (e.g., integrations, sub-workflows, etc.) and the infrastructure across multiple logical instances – tenants – of their BSS, while sharing the same codebase, easily referencing data, and orchestrating cross-tenant processes across multiple tenants.

Multi-tenancy is a unique feature of CompaxDigital full stack BSS that most importantly allows CSPs to adjust and configure each tenant independently without impacting other tenants, which is essential when you need to stand up a new brand, MVNO or B2B2x offering. Multiple business units, customers and/or partners are participating as tenants in this multi-tenant environment, which makes it faster to deploy and efficient to operate, and enables complex cross-partner and provider-customer relationships.

How It Works

In CompaxDigital, 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 the reuse is needed.

New Tenant Rollout

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

• To support a new business model, e.g., B2C vs. B2B or B2G, that will require reuse of the existing functionality, such as downstream or ERP integrations, while having its own completely separate set of products, customer accounts, processes and accounting
• To comply with GDPR/other government regulations so that sensitive data is clearly separated and is handled in accordance with the data privacy rules
• To support a large customer (large invoices, custom charging rules, complex promotions, etc.), e.g., a large Fortune 100 or B2G – for example, in cases where you need to give your customer access to some of the tenants’ functionality or to separate a large customer for performance optimization reasons
• To quickly start-up a new brand by reusing existing functionality and existing infrastructure without impacting other tenants’ performance

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

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

All of the above can be done in a fully agile way in a matter of weeks, depending on the amount of set up 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—testing, migration and production, for example. They can also be all multi-tenant, or some can be multi-tenant, and some will be 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 your 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’re 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

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

As shown in the example above, it also can 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.

CompaxDigital’s multi-tenancy feature delivers cost benefits as well. There are no third-party license costs, our capabilities are based on proven, widely available, open-source products. And our 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.