Tenant-Specific SaaS Service Packaging with Core Extension Modules
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing SaaS computing platforms face challenges in balancing multitenant access with rich, granular tenant-specific customization, as current methods are time-intensive, unwieldy, and increase maintenance complexity, often lacking flexibility and consistency across codebases.
Innovation Solution
A computing system that generates tenant-specific services by integrating extension modules into a core platform, using an API router to present a multi-tenant interface while allowing non-destructive or destructive modifications to the core API and data model, enabling efficient customization and upgradeability.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a monolithic codebase is modified to achieve total customization for a particular tenant, then customization flexibility is improved, but maintenance complexity increases and the process becomes time-intensive and unwieldy
Solution Approach 1:
The codebase is segmented into a monolithic core platform and separate tenant-specific customization modules. The core platform remains unchanged and maintained centrally, while customizations are developed as independent modules that can be attached to specific tenants. This segmentation allows customization flexibility without increasing maintenance complexity of the core system.
Solution Approach 2:
Customization logic is extracted from the monolithic codebase and placed into separate tenant-specific modules. These modules contain only the customizations needed for particular tenants, allowing them to be developed, tested, and maintained independently from the core platform, thereby reducing overall maintenance complexity while preserving customization flexibility.
2Adaptability or versatility
If isolated customized codebases are created for each tenant, then customization flexibility is improved, but it becomes infeasible to treat codebases collectively and guarantees of conformity to defined functions are lost
Solution Approach 1:
An intermediary layer is introduced between the isolated tenant-specific modules and the core platform. This intermediary consists of standardized interfaces and contracts that ensure all customization modules conform to the defined functions of the core platform. The intermediary validates and manages the integration of custom modules, maintaining reliability and conformity guarantees while allowing customization flexibility.
Solution Approach 2:
A universal interface standard is established that all tenant-specific customization modules must adhere to. This universal contract ensures that despite isolation, all modules can be collectively treated and guaranteed to conform to the core platform's defined functions. The universality principle allows independent development while maintaining system-wide consistency and reliability.
3Ease of operation
If predetermined extensibility is built into the platform for tenant-specific customization, then ease of operation is improved, but the form of customizability is restricted and expanding customizability requires adding new extensibility across the entire platform
Solution Approach 1:
The platform's extensibility is made dynamic rather than static. Instead of having fixed predetermined extensibility points, the system allows tenant-specific modules to be dynamically attached and integrated with the core platform. This dynamic approach enables easy operation through standardized interfaces while simultaneously expanding customization scope as new tenant modules are developed and registered with the core platform.
Data Source
AI summary
Technologies are provided for generation of an executable package that provides a tenant-specific service. Generation of the executable package can be based on customization assets and a core codebase. The core codebase can define core modules that provide a core service that is common across tenants. Each core module includes one or multiple extension points. The customizations can be defined within one or multiple virtual partitions, where a virtual partition includes a filesystem or another type of non-transitory storage structure. The VP can include multiple customization resources and customization components. The customizations can permit building extension modules that can be mapped onto respective extension points of core module(s) in order to customize the common core service and yield the tenant-specific service. The core codebase can be built to generate built core modules. The executable package can be formed by combining built extension modules and built core modules.