Multi-tenancy Research Day


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Multi-tenancy Research Day

  1. 1. Multi-Tenancy Research Meeting: Using Design Patterns to Implement Multi-Tenancy Jaap Kabbedijk, MSc. Utrecht University1
  2. 2. Jaap Kabbedijk  PhD. Candidate @ Utrecht University  Interests: Requirements Engineering, Software Variability, SaaS, Open Source Software, Software Architecture  Graduated on the topic of “Decision making in Requirements Engineering”  First publication in the PaaS project  J. Kabbedijk & S. Jansen, Variability in Multi-tenant Environments: Architectural Design Patterns from Industry, Proceedings of the International Variability Workshop@ER, 20112
  3. 3. Outline  Motivation and goal  Case Companies  Concepts  Pattern Evaluation Method  Conclusion  Discussion3
  4. 4. Research Motivation  Customers have specific requirements for the software they use  Offering specific on-premises variants can be hard to:  Manage  Update  Maintain  Complying to customer specific requirements in a SaaS environment has drawbacks:  Difficulty with scalability  Difficulty with maintainability  Architectural erosion4
  5. 5. Main Project Goal Minimizing the total cost of ownership (TCO), by profiting of the economy of scale of the SaaS deployment model, while keeping flexibility in offering functionality to customers5
  6. 6. What will we do? What will we do in order to answer the question: ‘How to facilitate variability in Multi-tenant Software as a Service deployments?’6
  7. 7. What will we do? What will we do in order to answer the question: ‘How to facilitate variability in Multi-tenant Software as a Service deployments?’ Come up with Runtime Variability Patterns (RVP)7
  8. 8. Case Companies  AFAS  Exact  MP-Objects  Possibly Unit4 and Mamut  Most in Truffle 100 (
  9. 9. What is Multi-Tenancy? Bron: Microsoft Research, 20069
  10. 10. When do you need Multi-tenancy?10
  11. 11. What is Variability?11
  12. 12. How to get the Patterns? Develop Patterns Publish Evaluate & Test Patterns Patterns12
  13. 13. Pattern Development  Identify Run-time Variability Patterns currently used  Case study at AFAS  Case study at Exact  Case study at MP-Objects  Identify RVPs in literature (literature study)  Come up with new RVPs (design science)13
  14. 14. Test and Evaluation  Identify RVP evaluation criteria  Evaluate RVPs by expert reviews  Test RVPs on small scale and large scale (testbed)14
  15. 15. Expert Review Session  20 experts  Twice a year  Direct feedback from industry  Interactive voting  Direct discussion15
  16. 16. Evaluation Criteria (1/2) (based on expert review session)  Scalability – How does the pattern behave if the customer base grows?  Maintainability – How easy can the software be maintained when this pattern is applied?  Reusability – How easy can this pattern be reused in other parts of the software without code duplication?  Risk – What is the risk in terms of security of implementing this pattern? What are other typical risks and possible countermeasures?16
  17. 17. Evaluation Criteria (2/2) (based on expert review session)  Complexity – How complex is it to implement the pattern in a software product?  Flexibility – How well can the pattern cope with different system environments?  Required Changes – How much should be changed to a solution that does not yet implement the pattern?  Cost of Implementation – How much does the implementation of the pattern cost in total?17
  18. 18. Test Tooling  Selenium  SauceLabs  Tellurium  JUnit  TestComplete  TestArchitect18
  19. 19. Reporting (based on expert review session)19
  20. 20. Testbed • Patterns • Comments Tools Patterns Industry • Evaluations Testbed • Patterns Academia • Comments • Evaluations Test Data Testing Logic Pattern Database20
  21. 21. Publish  Summarize all RVPs and test results in the RVP database (continuous)  Publish catalogue (in the end)21
  22. 22. Pre/Post Update Hooks (1/3)22
  23. 23. Pre/Post Update Hooks (2/3)  Intent - To provide the possibility for tenants to have custom functionality just before or after an event  Motivation - To let the software product fit the tenants business processes best, extra actions could be made available to tenants before or after an event is called  Solution – The use of a component able of calling other components before and after the update of data. The tenant-specic modules are listed in a separate table23
  24. 24. Pre/Post Update Hooks (3/3)  Explanation – See image  Consequences - Extra optional components have to be available in the software system in order to be able to implement this pattern  Example - In a bookkeeping program, tenants can choose, whether they want to update a third party service as well by using a component that uses the API of a third party service to make changes there. If so, the FunctionalComponent can call the third party communicator after an internal update is requested24
  25. 25. Module Dependent Menu (1/3)25
  26. 26. Module Dependent Menu (2/3)  Intent - To provide a custom menu to all tenants, only containing links to the functionality relevant to the tenant  Motivation - Displaying all possible functionality in the menu would decrease the user experience of tenants, so menus have to display only the functionality that is relevant to the tenant  Solution – Every time a tenant displays the menu, the menu is built dynamically based on the modules he has selected or bought26
  27. 27. Module Dependent Menu (3/3)  Explanation – See image  Consequences - To be able to use this pattern, an extra table containing user-IDs and the modules available to this user has to be implemented. Also, the extra class ModuleChecker has to be implemented  Example - In a large bookkeeping product, containing several modules that can be bought by a tenant, the menus presented to the tenant can be dynamically composed based on the tenants license27
  28. 28. Discussion28
  29. 29. Multi-tenancy levels  Data Model Multi-tenancy  All tenant share the same database and data model  Application Multi-tenancy  All tenant share the same software instance  Configurable Multi-tenancy  All tenants share both database and software instance, while being able to configure the product the way they want it29
  30. 30. Variability levels  Look-and-Feel Variability  Possible different variants only enable changes in the look and feel  Data Model Variability  Different variants allow for changes in the data model  Application Variability  Different variants allow for changes in the product functionality30
  31. 31. Thanks!    www.slingerjansen.nl31