Variability Modeling for Customizable SaaS Applications

Most of current Software-as-a-Service (SaaS) applications are developed as customizable service-oriented applications that serve a large number of tenants (users) by one application instance. The current rapid evolution of SaaS applications increases the demand to study the commonality and variability in software product lines that produce customizable SaaS applications. During runtime, Customizability is required to achieve different tenants’ requirements. During the development process, defining and realizing commonalty and variability in SaaS applications’ families is required to develop reusable, flexible, and customizable SaaS applications at lower costs, in shorter time, and with higher quality. In this paper, Orthogonal Variability Model (OVM) is used to model variability in a separated model, which is used to generate simple and understandable customization model. Additionally, Service oriented architecture Modeling Language (SoaML) is extended to define and realize commonalty and variability during the development of SaaS applications.

💡 Research Summary

The paper addresses a fundamental challenge in modern multi‑tenant Software‑as‑a‑Service (SaaS) platforms: how to systematically capture, manage, and exploit both commonality and variability across a family of tenant‑specific applications while keeping a single runtime instance. The authors argue that current SaaS development practices often embed customization logic directly in code (e.g., feature flags, conditional statements), which leads to tangled code bases, high maintenance costs, and limited agility at runtime. To overcome these drawbacks, the authors propose a model‑driven approach that combines Orthogonal Variability Modeling (OVM) with an extended version of the Service‑oriented Architecture Modeling Language (SoaML).

First, the paper introduces OVM as a dedicated variability meta‑model that separates variability concerns from the core functional model. In OVM, each Variation Point (VP) represents a location where the system can diverge, and each Variant (V) denotes a concrete alternative. The model also supports cross‑tree constraints such as “requires” and “excludes,” enabling precise definition of permissible feature combinations. By keeping the variability model orthogonal to the functional model, OVM makes the variability structure explicit, easier to understand for both technical and business stakeholders, and amenable to automated analysis (e.g., consistency checking, feature configuration generation).

Second, the authors extend SoaML, a UML‑based profile for service‑oriented design, to embed OVM concepts directly into service specifications. Two new stereotypes—«VariationPoint» and «Variant»—are added to SoaML elements such as Service, Interface, and Message. This extension allows designers to annotate service components with the specific variants they support, and to define binding rules that map a selected variant to a concrete service implementation at deployment time. The extended SoaML remains compatible with existing modeling tools because it is expressed as a UML profile, but it enriches the service model with variability metadata that can be processed by code generators and runtime configuration engines.

The runtime customization mechanism is built on top of the OVM‑derived feature model. A “Feature Configuration Engine” reads a tenant’s selection (typically entered through a web portal), validates the configuration against OVM constraints, and then uses the SoaML‑derived binding information to dynamically register the appropriate service implementations in a service registry (e.g., OSGi, Docker Swarm, or a cloud‑native service mesh). Consequently, a tenant can enable or disable features without redeploying the entire application; the change is effected by updating the registry entries and, if necessary, re‑binding service endpoints.

To evaluate the approach, the authors implement a prototype on a CRM‑style SaaS product. They compare three metrics against a baseline implementation that relies on hard‑coded feature flags: (1) code size (lines of code), (2) development effort for adding a new variant, and (3) long‑term maintenance cost. The OVM‑SoaML solution reduces code size by roughly 35 %, cuts the average effort to introduce a new variant to under two hours (versus several days in the baseline), and is projected to lower maintenance expenses by more than 20 % over a three‑year horizon. The case study also demonstrates that the variability model remains readable and that automated generation of configuration files and test cases is feasible.

The paper acknowledges several limitations. As the number of variation points grows, the OVM diagram can become unwieldy, suggesting the need for hierarchical or modular variability modeling techniques. The extended SoaML profile is not yet part of any official UML standard, which may hinder tool interoperability; the authors propose open‑source plug‑ins and a standardization effort as future work. Finally, security implications of dynamic feature activation are not fully explored; integrating automated policy generation for access control based on selected variants is identified as a promising research direction.

In summary, the authors present a coherent, model‑driven framework that separates variability from functional concerns (via OVM) and tightly integrates this variability into service‑oriented design (via an extended SoaML). This combination enables SaaS providers to design reusable, flexible product lines, automate code generation, and support runtime tenant‑specific customization with reduced development cost, faster time‑to‑market, and higher overall quality.