Engineering Multi-Tenant Software-as-a-Service Systems

Engineering Multi-Tenant Software-as-a-Service Systems

E.Geetha Rani# 1, CH.Suguna Latha*2, D.Anusha# 3, M.Satya Sukumar*4 T.Swathi#5

#1Infornation Technology, Gudlavalleru Engineering College, Gudlavalleru, jntuk, A.P, INDIA

#3Information Technology.PVPSIT,Vijayawada, jntuk, A.P, INDIA

#5Information Technology.Gudlavalleru Engineering College, Gudlavalleru, jntuk, A.P, INDIA

*2Infornation Technology, Gudlavalleru Engineering College, Gudlavalleru, jntuk, A.P, INDIA

*4Infornation Technology,PPDCET,Surampalli(V),jntuk,A.P,INDIA

ABSTRACT

Increasingly, Software-as-a-Serv ice (SaaS) is becoming a do minant mechanis m fo r the consumption of software by end users. From a vendors perspective, the benefits of SaaS arise fro m leveraging economies of scale, by serving a large number of customers (tenants) through a shared instance of a centrally hosted software service. Consequently, a SaaS provider would, in general, try to drive commona lity a mongst the requirements of diffe rent tenants, and at best, offer a fixed set of customization options. However, many tenants would also come with custom require ments, which may be a pre-requisite for them to adopt the SaaS system. These requirements should then be addressed by evolving the SaaS system in a controlled manner, while still supporting the needs of existing tenants. This need to balance tenant variability and commonality, and to optimize on development and testing effort, can ma ke the evolution of mu lti-tenant SaaS systems an interesting engineering challenge; this has strong economic undertones as well, given the pay-per-use subscription model of SaaS, and the cost of incre mental development and ma intenance to cater to new tenant needs. In this paper, we outline a set of research issues in the design, testing and ma intenance of multi-tenant SaaS s ystems, and highlight some of the interesting optimizat ion questions that arise in the process. Presenting specific technical solutions is beyond the scope of this paper instead, our goal is to help shape a research agenda for mult i-tenant SaaS that can provide stimulus for

further investigation into this area by the software and service engineering research community, and can help advance methodological guidance and tool support for SaaS vendors.

Keywords :

Software -as-a-Serv ice, cloud computing, mult i- tenancy, testing, semantics, refine ment

1. INTRODUCTION

   In recent years, the trend towards Everything -as-a- Service (Xaa S) as envisioned in Utility Co mputings pay-per-use model, has been rapidly gaining ground in the Informat ion and Communication Technolog y (ICT) world. Co mpanies are increasingly adopting this new paradigm where they do not wish to commit resources for engineering computing infra-structure. Instead, they acquire these resources as and when they need them as services. Cloud co mputing, wh ich has emerged as the run-time platform for realizing this vision, may be visualized as a stack of possible service types, ranging fro m infrastructure-as-a- service (IaaS) at the very base, to platform-as-a- service (PaaS)S, to finally, Softwa re-as-a-Se rvice or SaaS the main focus of this paper. Informally, SaaS may be described as software deployed as a hosted service and accessed over the internet without the need for users to deploy and maintain additional on – premise IT infrastructure. Fro m a SaaS vendors perspective, the benefits of SaaS arise from leveraging economies of scale, by serving a large number of customers ( mu ltip le tenants) through a shared, centrally-hosted software service. This

   translates to lower subscription fees for individual tenants, thereby encouraging entirely new ma rket segments to utilize the benefits of software services for e xa mple , Small and Mediu m Enterprises (SM Es) who have traditionally been unable to afford steep software license costs, are able to factor in SaaS subscriptions as part of their operational e xpenses, and thereby give their business the benefit of IT services. For these reasons, SaaS has seen very significant growth over the last few years, and the ma rket outlook for the future continues to be bright. According to a recent IDC report [23], the SaaS ma rket reached $13.1B in revenue in 2009, while the on-premise market shrunk by $7B. The Saa S ma rket is forecasted to reach $40.5B by 2014, representing a compound annual growth rate (CA GR) of 25.3% . By 2014, about 34% o f a ll new business software purchases will be consumed via SaaS [23]. Other industry analysts also share this optimis m around Cloud Co mputing/SaaS e.g. Ga rtner estimates that over the course of the next 5 years, enterprises will cumulat ively spend $112B on SaaS, Paas and IaaS [24]. The business benefits of SaaS notwithstanding, supporting true mult i-tenancy in a SaaS system can be very challenging. By true multi-tenancy, we mean a SaaS instance that not only supports the common needs of several tenants, but also the custom require ments of indiv idual tenants to the extent possible. In the traditional mode of on -premise software delivery, or even in the Application Service Provider (ASP) model, each tenant would have a dedicated instance of the base application customized to its needs. However, when several tenants have to share the same application instance in a multi-tenant SaaS, how to handle variat ions in tenant require ments becomes an interesting question. Clearly, supporting such variations increases the overhead on the SaaS vendor. Also, allowing too much variability can defeat the very purpose of sharing, and ma ke system ma intenance very expensive. On the other hand, allo wing too little va riab ility may d iscourage tenants fro m subscribing to a SaaS in the first place – tenants would be unwilling to compro mise too much in terms of changing their business processes to adapt to what the SaaS vendor has to offer. This will be particularly true for many sma ll and mediu m-sized vendors, who would be less capable to dictate the terms of business engagement with their customers. In fact, industry surveys [25] ind icate that the inability to customize SaaS applications to suit their needs is the most significant challenge that customers face with the SaaS offerings they use. In the coming years, this has the danger of slowing down the growth of SaaS beyond those domains where there is little or no need for tenant-specific variations. Such domains may be few in spite of the general move towards industry

   standards.We believe that for the Saa S paradig m to truly meet its potential, vendors will need to move away fro m build ing rigid one-size-fits-all systems, or those that offer a fixed set of available customization options fro m which tenants must select. Instead, vendors will have to design SaaS systems in a way that allows the applications to evolve with time to cater to the custom requirements of newer tenants look ing to onboard the system. While doing so, vendors should not, of course, lose sight of the end-goal of a shared SaaS that the commonality a mongst tenants remain sufficiently high for a single application instance to be justifiable and viable. Thus multi-tenant SaaS development must involve maintaining this balance between tenant commonality and variability on an ongoing basis, leveraging the benefits of co mmonality wherever possible, and suitably adapting the design/development/testing/on-boarding process to address the require ments of variability. At its very core, SaaS is a economic model for software consumption, hence much of these activities would have to be grounded on the basis of financial reasoning that can bnefit the vendor as well as the tenants. In this paper, we seek to outline a mult i- tenant SaaS engineering approach that is motivated by this line of thinking. In particular, we consider the topics of: designing mult i-tenant SaaS systems in a way that facilitates reasoning about tenant commonality and variability (Section 4); testing such systems efficiently to avoid redundancies due to shared behaviour while still e xe rcising a ll points of diffe rence (Section 5); and re-factoring SaaS systems to ease maintenance (Section 6). Elaborating on these issues, we naturally find a set of optimizat ion questions rooted in the SaaS economic model, wh ich can guide decision-making for exa mp le, which set of tenants to onboard, or wh ich subset of services to retire, so that the vendor profitability is ma ximized, or impact on tenants is minimized. The overall SaaS engineering approach that we outline may be realized through design and analysis toolkits that vendors may use to methodically design, validate, refine and evolve multi-tenant SaaS systems. However, going into specific rea lizat ion aspects is beyond the scope of this paper we focus, instead, on the research issues involved and outline possible solution approaches with the hope that this will provide an agenda for further investigation.

2. Relate d Work

   While there is a lot of interest in SaaS in general, we believe that the challenges that arise due to mult i- tenancy have not been adequately explored fro m a software engineering perspective. Much of the e xisting research on multi-tenant SaaS have focused

   on shared data architecture and security manage ment [5, 7, 1, 15], and middle ware e xtensions to address the well-founded concerns due to data/security/isolation. The wo rk of [8] develops a mu lti-tenant placement model wh ich decides the best server where a new tenant should be accommodated. The placement main ly considers the hardware resources including CPU and storage usage. In principle , a new tenant will be placed on the server with min imu m re ma ining residual resource left that meets the resource requirement of the new tenant. There have also been studies on service performance issues in mu lti-tenant SaaS [9].

   In contrast, there has been relatively little research so far on the impact tenant variability may have on the functionality and evolution of a SaaS system over its lifecycle. Th is is not surprising given that SaaS is a relative ly recent phenomenon, and hence the initial focus is bound to be on issues that are related directly to its feasibility (such as security or performance). However, the fact that a SaaS system needs to functionally cater to mult iple tenants is now increasingly understood, leading to research on how to model variability in a SaaS, and how to make a SaaS system more customizable. Models and techniques successfully e mployed in software product line engineering [14] have been applied in mu lti-tenant systems to manage configuration and customization of service variants. In particular, [11] e xtends variability modeling [2], wh ich provides informat ion for a tenant to customize the SaaS application and guides the SaaS provider for service deployment. The work of [3] discusses some potential challenges in imp le mentation and ma intenance of multi-tenant systems. It presents an architectural approach which tries to separate the mu lti-tenant configuration and underlying imple mentation as much as possible, by adopting the 3-t ier architecture (authentication, configuration, and database) in the traditional single-tenant web application. Along the same lines, e xperiences in modifying industrial-scale single -tenant software systems to mult i-tenant software have been reported in [4]. Th is involves extending user-authentication mechanis ms, introducing tenant-specific software configuration and adding an application layer to e xtract tenant-specific vie ws fro m the shared database. A recent paper [13] also studies tenant specific customizations in a single software instance, mu ltip le tenant setup.In the software product lines community, feature diagra ms have been used to capture the simila rit ies and differences between products in a software product family (e .g. see [33] and the references therein). Testing of s oftware product lines described as feature diagra ms has been studied in [34], where the goal of test generation is

   given as the presence/absence of selected features. In comparison, for mult i-tenant SaaS systems, we feel it is important to have a holistic view of the commonality/diffe rences across tenants so that it be e xploited to sharing of parts of the test suite across tenants.

3. Motivation for this Paper

   By and large, the emphasis of the above cited work has been on how SaaS architects may model customization/configuration options through variation points, and make them available to tenants who wish to on-board the SaaS system, so that each tenant may indiv idually dec ide wh ich set of customization options offered by the vendor to select. However, while a vendor may offer a fixed set of customization options based on its understanding of the domain, we e xpect that a SaaS like all other software in the past will need to evolve based on newer/differentiated capabilities demanded by the users specially since the user base, spanning across mu ltip le tenants, will be large and diverse. Business imperatives will de mand this evolution. One may argue that tenant-specific changes (beyond vendor- offered customizations) go against the very objective of sharing, and that such demands, when they have to be met, should be handled through separate customized instances for individual tenants. However, there is an entire spectrum to be traversed between fully common, shared behavior, to complete ly diffe rent, customized behavior, and we strongly feel that the moot question is not whether tenant-specific changes should be considered, but to what e xtent they may be accommodated within a single instance, while still reta ining the benefits of sharing. From the vendors perspective, the evolution of a SaaS system due to functional variability amongst tenants raises many interesting questions: how diffe rent is a new service variant being requested from the ones that we currently offer? Is it a refine ment, or an elaboration of what we have, or will it require significant new development? What impact will it have on the homogeneity of the overall system if we accommodate it? Is the return-on- investment justified? How qu ickly can we test the changes? At what point does the maintenance overhead of tenant-specific changes start outweighing the benefits due to shared behavior? A service variant we were supporting seems to be having diminishing utility how do we min imize the impact of retiring it?….and many more. The goal of this paper is to help chart an agenda from the e xisting work on vendor-driven customizab ility via variability modeling, to a mo re tenant-driven evolution of a SaaS system, and the engineering challenges (e xe mp lified by the questions above) that the vendor

   has to address to accommodate this evolution. In the rest of the paper, we attempt to elaborate on this agenda.

4. Overview

   To motivate the mu lti-tenant SaaS engineering approach that we outline in subsequent sections, let us consider the following scenario two ma jor stock e xchanges make an agree ment to offer joint online trading services for a range of stock transactions (th is is a realistic scenario as we have seen from recent news on the Singapore and Australian Stock Exchange [30]). Let us suppose, this has to be made operational very soon to exp loit a favorable econo mic climate.

   Several e xisting services offered by both the stock e xchanges have functional similarities, a long with some variat ions. These services need to be identified and grouped together/merged in the joint trading system to be developed.

   Require ments for several new business services have been elicited with a h igh numberof variants to meet the needs of different financial

   institutions and grades of investors. There is a need to judiciously invest in new develop ment, so that it generates most value for the ecosystem (stock

   e xchange, customers), while g iving prio rity to the services in most common need.

   As development commences, testing

   scenarios seem to escalate when considering how each possible tenant is like ly to e xerc ise the system. Given the short development cycle, it is critica l to reduce testing overhead whenever possible, wh ile

   still retaining a degree of confidence about the coverage of tenant behavior.

   Post development and testing, the joint trading services are offered and they become very successful. New tenants continue to come on-board and the service and variant portfolio is opportunistically e xpanded to cater to their needs. At one point, ma intenance overhead becomes a bottleneck somehow the system needs to be re- factored to reduce tenant variability and keep things tractable. These are all rea listic scenarios that are like ly to occur when a multi-tenant SaaS system one that tries to ma ximize tenant commonality wh ile accepting some of their variabilit ies – is developed and deployed. These scenarios suggest the following topics would be relevant for engineering mu lti-tenant SaaS:

   A (Semantic) Model for SaaS Systems: Th is will involve modeling the SaaS services and variations, and representing tenant requirements so that they may be mapped to the SaaS system. The

   model should support semantic reasoning, so that similarities and diffe rences between services and

   tenant requirements may be analy zed to fine-tune the service model, estimate develop ment costs for tenant require ments and guide tenant on-boarding.

   SaaS Testing: Tenants will share many common features, but may also need capabilit ies that apply only to a subset of other tenants. There is a need to devise effic ient test representation and test case generation techniques, so that the testing activity can focus on exe rcising variations in tenant behavior, and avoid redundancies in testing the common behavior shared across a set of tenants.

   Re-Factoring SaaS Systems: A mu lti-tenant SaaS system may be initiated fro m customized single tenant instances, whose commonalit ies need to be me rged and variation points accounted for. It will continue to evolve as it accommodates the require ments of new tenants on-boarding the s ystem. Eventually, it may again need to be re-factored certain service variants may not have a high utility and the vendor may want to retire those while minimally impacting subscribing tenants, while the variability a mongst certain sets of tenants may justify separate SaaS instances for them. While the focus of the above discussions has been on functional similarities (or variabilities) between tenants and its implications on the SaaS develop ment cycle, there may also be differences between non-functional require ments (NFRs) of tenants. NFRs may be captured in the Service Leve l Agreements (SLAs) between the tenants and the SaaS provider, and they will constitute an important element of a mu lti-tenant SaaS analysis and engineering fra mework. However, given the orthogonal nature of functional and non – functional require ments and how they may be realized, we restrict ourselves to the functional space in this paper.

5. A Model for Multi-Tenant SaaS

   A mult i-tenant SaaS system has to be carefully designed to handle the variability that can arise due to the differing needs of tenants. At an abstract level, a SaaS system may be considered as a collection of services, where each service in turn, consists of a collection of operations that can be invoked by clients. The functionality desired by diffe rent tenants out of a service or operation may differ, thereby necessitating support for variants of these entities. As the existing literature shows [11], concepts from product-line engineering may be adopted to define variation points to which different variants may be lin ked, and the variability model may also be used to guide SaaS customization. Moreover, the packaging and deployment of the SaaS may be guided through a set of mult i-tenancy patterns that help distinguish

   between components that are shared between all tenants or are specific to some tenants [12]. Technically, these constructs provide the basic foundation for supporting variability within a mult i- tenant SaaS application architecture. However, to help mult i-tenant SaaS systems evolve in a controlled manner, what is needed is not only a way to record diffe rent variants, but also to be able to analyze their degree of variab ility (or conversely, similarity). For e xa mple , to onboard a new tenant, its require ments fro m the SaaS system needs to be mapped onto the set of available services and operations, so that the vendor can determine the gaps that need to be filled through new variants. If a new variant is very similar to an existing service or operation, then th e development effort will be re latively s ma ll, and the homogeneity of the system will not be impacted too much. On the other hand, if the tenant requires a very diffe rent/new type of service or operation, then it may imply significant development overhead, which has to be reviewed not only in light of the potential financia l benefits, but also the heterogeneity it introduces and its long-term ma intenance implications. In addit ion to updating a SaaS system to onboard a new tenant, the vendor may also wish to re-factor the system periodically to improve its ma intainability (we d iscuss this in Section 6) this would also need an analysis of similarities between diffe rent services/variants, so that the right decisions may be taken with respect to changes that have to be made to the underlying design.

   For these reasons, it would be helpful to enrich the e xisting variation-oriented modeling of mu lti-tenant SaaS systems with constructs that enable representation of service semantics. This may be done, for exa mp le, using a Design by Contract approach [31], where the semantics of a design entity like a service or operation is captured through the use of pre-conditions, effects/post-conditions, invariants etc. In the SOA world, such a representation has already been explored by the semantic web community to facilitate service discovery, matching or composition, leading to formalis ms like OWL-S [32]. We believe that a similar approach can also be taken to establish the semantic underpinnings of a mu lti-tenant SaaS solution. On top of this, one may define different notions of refine ment to understand relationships between services/variants and the ease with which a new variant may be created fro m e xisting ones. For e xa mp le, a variant that only needs weakening of an existing pre-condition may be easier to incorporate than one that introduces a significant new post-condition. Similarly, the addition of a variant of an e xisting service operation may cause less impact than the definition of a new operation, which is turn, may be dee med to have less overhead

   than having to define an entirely new service for a tenant. Such an approach would help the vendor estimate the cost of onboarding a new tenant, both in terms of the associated development effort, as well as the degree of heterogeneity that is introduces into the model. The vendor may fu rther define thresholds for this heterogeneity (or conversely, homogeneity or commonality) at d ifferent design levels to control and scope the evolution of a multi-tenant SaaS system. Given such a semantic model for Saa S, the onboarding of tenants poses interesting optimizat ion problems. The require ments of a tenant may be represented in terms of services and operations, and we may e xpect these require ments to be a mix of mandatory (must-have) and optional (good-to-have), which provides a basis for negotiation with the SaaS vendor. Given a tenants requirements profile, the vendor would like to identify the optima l ubset of require ments it should support, so that its net profit is ma ximized wh ile lead ing to the best commonality in the resultant system. The vendors profit would be the difference between the expected revenue from the services/operations based on the tenants anticipated usage profile, and the cost of additional development, which in turn will depend on the degree to which e xisting services/operations may be re-used e.g. through refinement. The resultant commonality of the system would reflect the e xtent to which the services/operations of the updated system are shared between tenants, and the degree of similarity between the variants of a service/operation. Given a set of such tenants to be considered for the next cycle of evolution of the SaaS system, the vendor would be interested to identify the subset of tenants and require ments to support, so that the above profit/commona lity criteria a re optimized.A variation-oriented semantic model for mu lti-tenant SaaS can thus provide a sound basis for a controlled evolution of the system.

6. Testing Multi-Tenant SaaS systems

   There are (at least) two interesting questions to consider in the area of testing multi-tenant SaaS systems that evolve to accommodate tenant variability : First, when a new tenant is onboarded, how do we test that existing tenants are not impacted by the changes introduced? Second, how do we efficiently test that the SaaS system meets the needs of the different tenants that have been onboarded? In the approach outlined in the preceding section, any new functional capability required by a tenant that is being onboarded, is handled cleanly by defining a new service/operation or its variant. We do not update any existing operation used by current tenants. This ensures that the changes made for the new tenant are isolated, and do not impact the functioning

   of the existing tenants. The first question is thus not relevant to our approach, although it will be a core concern for methods that try to overload existing operations to behave differently fo r different tenants. We do not recommend this since it is like ly to result in code that is very difficult to ma intain. The second question, however, is very relevant. Given the large degree of commonality that is like ly to exist amongst tenants, significant testing resources may be consumed if every tenant has to be fully tested across all applicab le scenarios. Rather, we may wish to test only the changes introduced by a tenant. One may argue, of course, that each tenant is different in that it would have its own data set. However, even if tenants are to be comprehensively tested individually, a testing strategy should be devised that exploits similarities amongst tenants to let testers step through the scenarios in a systematic manner. Belo w, we elaborate on the issues related to multi-tenant SaaS testing, based on the semantic model suggested in the preceding section. We assume a test case to be represented as a sequence of service operation invocations (or it may be rela xed into a partial order). The first issue we consider is test case generation, particularly test cases which do not exist in the current test-suite, but which should be tested once the new tenant(s) are on-boarded. This problem is similar in flavor to the test-suite augmentation problem where tests are generated to stress program changes, name ly e xecuting the changes and propagating the effect of the changes to the program output. The general proble m of test-suite augmentation may be addressed via two steps (for exa mp le, see [16]). In the first step, a control dependency analysis is done to find a test input to reach/execute the change. Then, in the second step, we modify the path of the change reaching test input to ensure that the program outputs are different with or without the change. One key issue here is to avoid infeasible paths, and for this reason symbolic e xecution (and path condition calculation) is essential. For mu lti-tenant SaaS systems, the test-suite augmentation problem will be visualized at a higher level, with the changes defined at operation level. Consequently the individual steps of the analysis (for finding the new tests) will also need to be changed. For reaching the change, we may want to explo it pre-conditions of the operations, instead of performing a fine-gra ined control dependency analysis. Finally, fo r propagating the effect of the executed changes, we can analyze the operation post-conditions (along with suitable control flow restrict ions) to find a suitable test (in the form of a partial order o f operation invocations). Since pre- and post-condition analysis will be central to this method, we envision that symbolic e xecution will play an important role in the proposed methods. The

   approach will e xtend contract-based testing of web services [26, 27]. The second issue relevant to testing mu lti-tenant SaaS systems is devising a testing strategy that explo its the similarity amongst tenants and structures the test suite accordingly. For this purpose we propose the notion of a Test-tree. The root node of a test-tree captures the set of test cases which need to be tested for all the tenants. Each intermediate node of the tree will capture a set of test cases which need to be tested for a subset of tenants. Thus, a partitioning of the tenant set is given by the root-to-leaf paths in the test-tree. To further illustrate the notion of test-tree, we may consider a schematic e xa mple .

   Fig. 1: A Test Tree for Multi-Te nant SaaS

   In this exa mple , we have five tenants {t1, t2, t3, t4, t5}. For co mprehensive testing, tenant t1s behavior needs to be tested against (200 +100 +10) = 310 test cases. Of these, 10 test cases are unique to t1, hence the SaaS system must be tested on these prior to onboarding of t1. Out of the re ma ining, 100 test cases are shared with t 2 and t3, and 200 test case are shared with a ll other tenants, so depending on the degree to which these test cases have already been exerc ised on e xisting tenants, testers may decide whether to test for a specific case or not. Furthermore, the root-to- leaf paths in the test-tree induce a partitioning of the tenant set namely {{t1}, {t2, t3}, {t 4, t5}}. We feel that the notion of a test-tree is a powerful one, for efficient and systematic testing of multi-tenant SaaS systems. In a broad sense, constructing the test-tree also amounts to a specification of the behavior of tenants in a mu lti-tenant SaaS system outlining the similarities and differences across the tenants usage of the SaaS system. Given such a notion of a test-tree for a mu lt i-tenant SaaS system, we need to study how the tree is modified as new tenants are on-boarded. In this respect, we can be guided by some of the works on software change-impact analysis. Mature tools like Ch ianti [17] e xist for change impact analysis.

   Given two progra m versions, these tools identify the atomic changes (across the two versions) and then find out the tests whose execution is affected by the changes. Such tools are very useful fo r program understanding, debugging and testing but from a general software engineering context. For mult i- tenant SaaS systems, the atomic changes can be defined more coarsely, possibly in terms of new operations or variants thereof. We can then adapt the works on change impact analysis to find which tests fro m the e xisting test suite may be affected, and test – tree transformat ions have to be defined accordingly.

7. Re -Factoring Multi-Tenant SaaS Syste ms There are situations where a vendor may wish to refine a SaaS design, either to improve its ma intainability, o r to provide better support for mu lti-tenancy. In particular, we envision the need for three re-factoring techniques that we term merging, splitting and pruning. The goal of me rging is to help bootstrap a multi-tenant SaaS design fro m e xisting single-tenant ones. Splitting may be used to generate smaller SaaS systems to reduce variability and improve ma intenance. Pruning may be used to reire service entities that are of low utility, in a controlled manner to manage impact. We introduce them in the following.

   Merging: The me rging technique will be useful in moving legacy service systems to the cloud. Imag ine a vendor of a SaaS system or an on-premise software product with many instances that have been individually customized and deployed for different customers. The vendor may now want to offer this software on the cloud, and have a single instance shared across the customers, to leverage the benefits of mu lti-tenancy. Fro m a design perspective, this means that the commonalities and differences across the various customized instances need to be identified and accounted for within a common design this is where merging co mes in. The technique assumes that the individual instances have a SOA -based design in terms of services and operations, and that the semantics of these entities (pre-conditions/effects) is known, or may be discovered by mining the legacy code. Given this, merging will analyze the specification of the different instances to detect similarities in services/operations. Diffe rent grades of similarity (fro m strict to lenient notions) may be used to come up with a merged design that meaningfully groups together similar entities under v ariation points. The literature on model differenc ing/merg ing [17, 18, 19] and semantic web matching [20, 21] will be relevant here.

   Splitting: Th is is the dual of the merging operation. There may be a number reasons why a service provider may want to split a large mult i-tenant SaaS

   system into smaller mu lti-tenant systems (each system consisting of a subset of services and operation variants present in the original system). For e xa mple , it may be due to ease of maintenance. As more and more tenants onboard a SaaS, the service/operation/variant set may keep on increasing. As a result, the software may get bloated, and a direct business consequence of this for the provider would be higher ma intenance costs . Secondly, a group of tenants may e xh ibit similar us age require ments. In such cases, it may ma ke sense to support them out of a separate (smalle r) Saa S instance, and maybe charge a higher price for those combinations of services and operations. However, splitting a large mu lti-tenant SaaS system into mult iple sma lle r ones supporting subsets of tenants, may also lead to some features being replicated across the different instances, and this may lead to new running costs. There is thus a trade-off to be considered. A relevant optimizat ion problem is, given a mult i-tenant SaaS system S, divide its tenant set T into K (>=2) non-overlapping sub-sets generating K mult i-tenant systems (each system containing all the services/operations/variants needed by its tenants), in a way that leads to ma ximization of the profit for the SaaS vendor and also leads to the best commonality in the resulting systems.

   Pruning: Pruning refers to changes made to a SaaS design by retiring entities (services, operations) that the vendor perceives to be of low utility. This may be based on financial mot ives. For e xa mp le, the utility value for a service operation (or a specific variant) may be co mputed as the ratio of revenue generated fro m this operation and its running costs where the revenue is computed over all tenants who have subscribed to the operation, while running costs refer to the cost the provider has to bear to ma intain the operation in question (such as cost of associated infra -structure, third party services and so on). We can simila rly lift the notion of utility to the lev el of a service by averaging over all the service operations. When the utility of a service, operation or variant falls below a threshold, the SaaS vendor may dec ide to retire i.e. withdraw those entities, and thereby save on the running costs. We term this as pruning the SaaS design.

   However, retiring a service or operation will impact those tenants who have subscribed to it. If an entire service is retired, the subscribing tenants will lose the associated functionality, and if this represents one of their mandatory require ments, they are like ly to leave the vendor, causing revenue loss to the latter. A more controlled way of pruning the SaaS system may be by retiring selected operation variants of low utility, with the plan of offering other variants of these

   operations (as substitutes) to the subscribing tenants. Our assumption here is that as long as the vendor is able to preserve a tenants control flo w through the SaaS at the level of the operations invoked, it may still be acceptable to the tenant if certain operation variants are replaced by other suitable variants. Of course, tenants will also need to know the cost implications of this transfer for exa mp le, if the new variants are much more e xpensive than existing ones

   – hence the vendors goal would be to offer those

   alternative to a tenant that do not result in excessive additional cost. On the other hand, if the provider cannot preserve a tenants control flow in terms of the operations it needs to invoke, then the tenant may leave the provider. Given this context, the pruning problem may be formulated in terms of determin ing the subset Sk of low-utility operation variants that may be re moved fro m the SaaS system, such that the number of tenants who may leave is <L, the average transfer costs of rema ining tenants is <Q, and the providers profit is >P, where L, Q and P are suitable thresholds for the respective measures that may be defined by the user/vendor.

8. Summary

   Multi-tenancy offers a very attractive proposition to vendors and customers alike , to leverage the economies of scale by sharing a common application instance across many tenants. There is a growing need however, to make mult i-tenant SaaS more fle xib le so that some of the custom require ments of individual tenants can be met even within the shared application instance. Existing approaches try to address this by considering how a vendor may offer a (fixed) set of customizat ion options to tenants, which they can choose from wh ile onboarding. In this paper, we have argued for a mo re tenant-driven evolution of a SaaS, where a vendor can accommodate changes to a SaaS to meet tenant needs, within reasonable limits. We have then discussed a number of software engineering issues that are relevant to such an evolution, and some of the optimization proble ms that arise. Specifica lly, we have considered semantic modeling of mu lti-tenant SaaS systems, onboarding of tenants with custom needs, effic ient testing for multip le tenants with a mix of co mmon/custom behavior, and re-factoring techniques to increase the maintainability and economic va lue of mu lti-tenant SaaS systems. We are currently working on forma lizing many of the concepts introduced in this paper. This will lay the foundation for a mult i-tenant SaaS toolkit with capability patterns for semantic modeling, tenant onboarding, testing and re-factoring, that vendor teams may use to develop, evolve and maintain mu lti-tenant systems.

9. REFERENCES:

• S. Aulbach, T. Grust, D. Jacobs, A. Ke mper and J. Rittinger. Multi-tenant Databases for Software as a Service:Sche ma- Mapping Techniques. In SIGM OD, pp 1195-1206, 2008.

• J. Bayer, S. Gera rd, O. Haugen et al. Consolidated Product Line Variability Modeling. Software Product Lines.

• C. Be ze mer and A. Za id man. Mu lti-Tenant SaaS Applicat ions: Maintenance Drea m or

  Night mare? In Proceedings of the 4th Internaitonal Joint ERCIM/IWPSE Sy mposium on Softwa re Evolution (IWPSE-EVOL), 2010

• C. Be ze mer, A. Za id man, B. Platzbeecke r et al. Enabling Multi-tenancy: An Industrial Experience Report. In ICSM.

• F. Chong, G. Carra ro, and R. Wolter. Mult i- Tenant Data Architecture. MSDN Library, Mic rosoft Corporation, 2006.

• K. Czarnec ki, M. Antkie wic z and C. Kim. Multi-level Customizat ion in Application Egineering. Co mmunications of the ACM, 49(12): 65, 2006.

• C. Guo et al. A Fra me work for Nat ive Multi-Tenancy Application Deve lopment and Management. 9th IEEE Intl. Conf. on E-Co mmerce Technology and 4th IEEE Intl. Conference on Enterprise Co mputing, E-Co mmerce and E-Serv ices (CEC-EEE), 2007.

• T. Kwok and A. Mohindra. Resource Ca lculations with Constraints and Place ment of Tenants and Instances for Multi-Tenant SaaS

  Applications. In International Conference on Service Oriented Co mputing (ICSOC), 2008.

• X. Li, T. Liu, Y. Li and Y. Chen. SPIN: Service Performance Isolation Infrastructure in Multi-Tenancy Env iron ment. In Internatonal Conference on Serv ice-Oriented Co mputing (ICSOC), pp 649-663, 2008.

• R. Miet zner and F. Ley mann. Generat ion of BPEL Customization Processes for SaaS applications fro m Variability Descriptors. In IEEE International Conference on Serv ices Co mputing, volu me 2, pp 359-366, IEEE Co mputer Soc iety, 2008.

• R. Miet zner, A. Metzger, F. Ley mann and

  K. Pohl. Variability Modeling to Support

  Customization and Dep loyment on Multi-Tenant- Aware Soft ware as a Se rvice Applications. In ICSE Workshop on Princip les of Engineering Service Oriented Systems (PESOS), 2009.

• R. Miet zner, F. Ley mann and M. P. Papazoglou. Defining Co mposite Configurable SaaS Application Packages Using SCA, Variability

  Descriptors and Multi-Tenancy Patterns. 3rd Intl. Conference on Internet and Web Applications and Services, pp 156-161, 2008.

• Nitu. Configurability in SaaS (software as a service) Applications. In Proceedings of the 2nd India Soft ware Engineering Conference (ISEC), pp 19-26, 2009.

• K. Pohl, G. Bockle and F. Van Der Linden. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Ve rlag Ne w Yo rk Inc, 2005.

• C. Weissman and S. Bobrowski. The Design of the Force.co m Mult i-Tenant Internet Application Develop ment Platfo rm. In SIGM OD, pp 889-896, 2009.

• D. Qi, A. Roychoudhury and Z. Liang. Test Generation to Expose Changes in Evolving

  Progra ms. In ASE, 2010.

• X. Ren, F. Shah, F. Tip, B. Ryder O.

  Chesley. Chianti: A Tool for Change Impact Analysis of Java Progra ms. In OOPSLA 2004, pp 432-448

• C. Treude, S. Berlik, S. Wenze l and U.

  Kelter. Diffe rence Co mputation of Large Models. In ESEC/FSE 2007.

• T. Mens. A State-of-the-Art Survey on

  Software Me rging. IEEE Transactions on Software Engineering, 28(5), 2002

• G. Brunet, M. Chechik, S. Esterbrook et al.

  A Manifesto for Model Merging. In Proceedings of GAMMA, May 2006

• M. Pa loucci, T. Kawa mu ra, T.R.Payne and

  K. Sycara. Se mantic Matching of Web Serv ice Capabilit ies. In Proceedings of IWSC, June 2002

• E. Stroulia and Y. Wang. Structural and

  Se mantic Matching for Assessing Web Service Similarity. Intl Journal of Cooperative Info rmation Systems, 14(4), pp 407-438, 2005.

• Worldwide Softwa re as a Serv ice 2010-2014 Forecast: Software Will Never Be The Sa me. IDC Report Doc#223628, June 2010.

• Forecast: Public Cloud Serv ices, Worldwide and Regions, Industry Sectors, 2009-2014. Gartner, June 2010.

• J.M.Kap lan. How SaaS is Overco ming

Co mmon Customer Objections. Cutter Consortium: Sourcing and Vendor Re lationships, Advisory Service, Executive Update 8(9), 2008.