The number of tenants that subscribe to and pay for a service, and the cost of the SaaS computing infrastructure are the main factors that drive service pro tability. In many application domains tenants' requirements for service vary. Service variability is the degree of the actual variability provided by the Service Provider over the variability required by the tenants for the service. With growing number of tenants, the likelihood of facing more diverse tenants' requirements increases. We conducted a study of how choices regarding service architecture a ect service variability and the cost of supporting a service. We identi ed positive and negative impacts of service architectural choices on service variability and on Service Provider's costs. We illustrated how the knowledge of those impacts can help Service Providers analyze service pro tability based on di erent service architecture models, leading to more-informed decisions regarding adoption of SaaS.
Service variability is the degree to which Service Provider can accommodate
tenant-speci c requirements into a service. The Service Provider tries to
accommodate these requirement variations into the service so as to better t the service
to the tenants. As the un t costs for the tenant decreases, the relative economic
advantage of the SaaS business model increases [
To come up with a SaaS solution that maximizes pro ts, a Service Provider must weigh the revenue from selling a service to potentially many tenants, against the cost of SaaS computing infrastructure to support the service. Given interdependencies among factors that collectively determine pro tability of service o ering, the task is not easy.
We conducted a study of how choices regarding service architecture a ect service variability and the cost of supporting a service. We identi ed positive and negative impacts of service architectural choices on service variability and on Service Provider's costs. We illustrated how the knowledge of those impacts can help Service Providers analyse service pro tability based on di erent service architecture models, leading to more-informed decisions regarding adoption of SaaS. Our study is qualitative. In future work, we will extend it with quantitative analysis and models that more precisely correlate SaaS costs and bene ts, giving more accurate insights into pro tability of SaaS from service variability perspective.
The paper is organized as follows: We rst describes the architectural choices of SaaS relevant to service variability in Section 2. In Section 3, we introduce the architectural models and further analysis the scenarios related to service variability in Section 4. Section 5 is on related work and Section 6 is our conclusion. 2
2.1
1. Static Binding Variability Techniques (SBVT) - Static binding techniques
instrument service code for adaptability to tenants' variant requirements at
the design time. During (pre-)compilation or build time, variant
requirements are bound to the variation points in service code to produce a custom
service. Commonly used variation techniques include preprocessing (macros),
Java conditional compilation, commenting out feature code, design patterns
, templates and parametrisation, and build tools (e.g., make or Ant). XVCL
[
As new tenants are on-boarded and requirements of existing tenants or service functions change, service must be adapted to accommodate evolving needs of tenants. Service adaptation has to be done without a ecting existing tenants. 1. Service Level Encapsulation (SLE) - For Service Level Encapsulation, a service is implemented with identi ed shared service components. There is clear separation of components for each service, but not between tenants. The tenants who are using the service can be temporary a ected during service modi cation but the tenants who are not using the service will not be affected. 2. Tenant Level Encapsulation (TLE) - For Tenant Level Encapsulation, a service is implemented with speci c service components for each tenant. There is clear separation of components for each tenant. During service modi cation, only the speci c tenants are a ected. 2.3
A service can be hosted on single or multiple application instances. Application instance is a software process (executable application code) running on an infrastructure platform. 1. Shared Instance (SI) - For Shared Instance, tenants access a service through a common application instance. The Service Provider considers this option typically to maximize resource utilization. 2. Dedicated Instance (DI) - For Dedicated Instance, each tenant accesses the service on its own dedicated application instance. The Service Provider considers this option due to high variation in tenants' requirements or for compliance to service level agreements.
A summary of the architectural choices is shown in a tree structure in Fig. 1. 2.4
The architectural choices for service variability impact the degree, costs and bene ts of the service variability. Table 1 summarize these relationships. 1. Degree of Service Variability - The degree of service variability is the extent and scope to which variations in service requirements can be handled. To understand the possible variations in service requirements, we use the entity-controller-boundary pattern to break down each service into its service components. Each service can be represented by interactions among a set of service components in terms of boundary, controller and entity components. Boundary components are used to interface externally with information elements and can varies with the elements and its representation termed as Interface Variability. Controller components manage the interactions among components. The composition of components including the ow of interactions and processing logic can varies among tenants result in Composition Variability and Logic Variability. Entity components represent the data of the service and can varies in the type of data elements and its structures. We termed this as Data Variability. The variations in service requirements for each service is the sum of all the variations of its service components for that service. A service is able to achieve high degree of service variability if it has the ability to handle high variations of service requirements. 2. Costs and Bene t of (Pro tability of investing in) Service Variability - The cost incurred includes the cost for designing or re-designing the service binding in service engineering and service packaging. It also includes the infrastructure cost for service hosting to support service variability. High degree of service variability can be better supported by static binding (service engineering), dedicated instance (service hosting) and tenant level encapsulation (service packaging). However, these decisions requires higher costs in terms of design e orts and computing resources to run the service. The bene t of managing service variability is to increase the revenue by widening the tenants base. By being able to support higher degree of service variability, the tenant base can be increase easily. In a given situation, the Service Provider needs to make decisions to minimize the cost of service engineering/service packaging/service hosting and maximize the revenue (by widening the tenant base), ultimately a ecting the pro tability of a service. 3
SaaS Architectural Models di er in how the service code is managed during service engineering, service execution and service hosting. For the purpose of this paper, we assume three architectural models. The Fully-Shared model is based on a shared application instance and service components being shared by tenants
Understanding Service Variability for Pro table SaaS 13 during service execution. The Partially-Shared model is based on shared application instance but as compared to Fully-Shared model the software components in Partially-Shared model can be tenant-speci c (TLE) or service-speci c (SLE) or both. For example, the boundary components can be tenant-speci c while the controller components are service-speci c. The No-Shared model is based on each tenant having own, dedicated application instance and the service components are tenant-speci c. The Fully-Shared model can only adopt dynamic binding techniques while the Partially-Shared and No-Shared models can adopt both static and dynamic techniques. Table 2 summarize these relationships.
The approach to determine the architectural model depends on the variations of service requirements, architectural choices and the cost/bene t analysis of the Service Providers. Fig. 2 illustrates this approach.
Service Provider wants to employ SaaS solution that maximizes pro tability of selling her application as a service. Therefore, the Service Provider needs an architectural model for a service that would lower the cost of the service o ering and widen the tenants base. 1. Lowest cost - The Service Provider chooses the architectural model that incurs lowest cost to maximize pro ts. In particular for service variability, the Service Provider has to make decision to support service variability with the lowest cost. Based on Table 1 and 2, the Service Provider is likely to go for the Fully-Shared Model to minimize the cost. However, the lower degree of service variability imply that some tenants with high variations of service requirements cannot be met. 2. Maximize Revenue - The Service Provider needs to ful ll the tenant's expectations to widen the tenants base and increase revenue. The tenant expects their requirements to be ful lled as if the service is single tenant. The higher degree service variability implies greater extent of the tenant's requirements that can be ful lled. The Service Provider can go for No-Shared Model. The associated higher cost incurred by the Service Provider imply that the tenants have to be able to a ord the higher fee. 3. Tenant On-boarding (Low degree of service variability) - The Service Provider wants to on board as many tenants as possible. However, the bene t of on boarding new tenants (increased revenue) should be weighed against the cost of adapting the service to possibly new requirements (i.e., the cost of service variability). In this example assuming there is an initially small number of tenants (e.g. 30 tenants) with low variation of requirements. In this case, the Service Provider chooses the Fully-Shared model to minimize the cost of service variability. If InfraSharedCost(30) is the shared infrastructure cost of supporting 30 tenants and CostDVTDesign(30) is the cost to implement the dynamic binding variability techniques, then the cost of o ering an application as a service is:
Understanding Service Variability for Pro table SaaS 15 4. Tenant On-boarding (High degree of service variability) - Assuming there are 50 more tenants (more diverse requirements) interested in the service with 30 existing tenants. The Service Provider can provide dedicated service instances for new tenants and applying both static and dynamic binding techniques to cater for variant requirements. In this case, the Service Provider needs to evaluate the overall cost of providing dedicated instances and implementing the static and dynamic binding techniques for a No-Shared model. If CostSDVTDesign(50) is the cost to re-design for static and dynamic binding and InfraDedicatedCost(50) is the dedicated infrastructure cost of supporting 50 tenants, then the cost of o ering an application as a service is: InfraSharedCost(30) + CostDVTDesign(30) + InfraDedicatedCost(50) +
CostSDVTDesign(50) The Service Provider can also chooses to place the 50 tenants on with existing tenants in a Partially-Shared model. In this case, the Service Provider needs to evaluate the impact due to the higher variability of requirements. If CostDVTRedesign(50) is the cost to re-design for dynamic binding, then the cost equation for service variability is:
InfraSharedCost(30) + CostDVTDesign(30) + InfraSharedCost(50) +
CostDVTRedesign(50) To on-board the 50 tenants, the Service Provider can make decisions based on the minimum cost of both choices.
Min (InfraSharedCost(50) + CostDVTRedesign(50) , InfraDedicatedCost(50) + CostSDVTDesign(50) ) If the Service Provider is aware of the need to support up to 80 tenants(30 tenants with low variation of requirements and another 50 tenants having high degree variation of requirements), the service provider can alternatively plan to support the 80 tenants directly with No-Shared for all 80 tenants. If InfraDedicatedCost(80) is the cost for dedicated infrastructure to support 80 tenants and CostSDVTDesign(80) is the cost to implement the static and dynamic binding variability techniques, then the cost equation for service variability is:
5. Service Isolation - To many organizations, security and privacy are still the top issues in adopting SaaS. The No-Shared model would be most suitable with software components and process instance being tenant-speci c. Service Providers might want to propose Partially-Shared model (e.g. only the entity components are tenant-speci c) for the group of tenants who are more pricesensitive.
The pro tability model for SaaS is an area that attracts much interest. The
author of [
We addressed the problem of pro tability of SaaS solutions in view of the revenues from selling the service, and the cost of SaaS computing infrastructure to o er a service to tenants. The rst depends on the number of tenant who pay for the service. The latter is determined by the cost of computer resources utilization, and the cost of service engineering. We identi ed trade o s involved in Service Provider decisions regarding the choice of service variability (i.e., the ability to satisfy the diversity of tenants' requirements) and SaaS architecture for the service. With the growing number of tenants, the likelihood of facing more diverse tenants' requirements increases. We found that high service variability may call for more costly SaaS architectures (e.g., dedicated service instance as opposed to shared instance), and more costly techniques for service variability management (e.g., static binding as opposed to dynamic binding). We summarized the results of our analysis in tables that show in uences among factors that determine pro tability of the SaaS solution. We believe our results can help Service Providers make more informed decisions regarding service o ering. Our current study is qualitative. In future work, we will extend it with quantitative analysis and models that more precisely correlate SaaS costs and bene ts, giving more accurate insights into pro tability of SaaS from service variability perspective. We plan to decompose cost and bene t of SaaS solution into more detailed factors that will include the e ort of migrating an existing application into a service and on-board new tenants.