Landelijke Architectuur Congres 2011


Published on

Slides and research by J. Kabbedijk, Msc.
Presentation by prof.dr. S. Brinkkemper

Published in: Technology, Business
1 Like
  • Be the first to comment

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

No notes for slide

Landelijke Architectuur Congres 2011

  1. 1. Product as a Service: One Size doesn’t fit All prof.dr. Sjaak Brinkkemper dr. Slinger Jansen Jaap Kabbedijk, MSc. Utrecht University, the Netherlands
  2. 2. Outline <ul><li>Introduction </li></ul><ul><li>Deployment Models </li></ul><ul><ul><li>Traditional </li></ul></ul><ul><ul><li>Online </li></ul></ul><ul><li>Concepts </li></ul><ul><ul><li>Variability </li></ul></ul><ul><ul><li>Multi-tenancy </li></ul></ul><ul><li>Case Example </li></ul><ul><li>Example Pattern </li></ul><ul><li>Conclusion and Future Research </li></ul>LAC2011
  3. 3. Research Project <ul><li>Utrecht University </li></ul><ul><li>University of Groningen </li></ul><ul><li>Two large ERP product software vendors from the Netherlands </li></ul><ul><ul><li>Exact </li></ul></ul><ul><ul><li>AFAS </li></ul></ul><ul><li> </li></ul>LAC2011
  4. 4. First something completely different! Based on work of dr. Andy Zaidman (TUDelft) LAC2011
  5. 5. Pros and Cons House : Privacy en freedom Apartment : Cost efficiency LAC2011 House Apartment Effective use of land - + Privacy + - Infrastructure sharing - + Maintenance cost sharing - + Freedom + -
  6. 6. Traditional Deployment Model <ul><li>Think about the ‘House’ example </li></ul><ul><li>Customers have to install and update their own software </li></ul><ul><li>Customers manage their own data </li></ul><ul><li>Every customers needs his own server to deploy the product </li></ul><ul><li>Customizations can easily </li></ul><ul><li>be done per customer </li></ul>LAC2011
  7. 7. Traditional – Disadvantages <ul><li>High initial costs for customers </li></ul><ul><li>Hard to keep up with updates </li></ul><ul><li>Lack of expert knowledge </li></ul><ul><li>High change of data loss </li></ul>LAC2011
  8. 8. Overview Online Deployment Models (Kwok et al., 2008) LAC2011 Application Server Provider Multi-user Solution Different Environments Multi-tenancy
  9. 9. Application Server Provider <ul><li>Data not responsibility customer </li></ul><ul><li>Application is hosted at a third party </li></ul><ul><li>Multiple products are hosted on the same machine </li></ul><ul><li>More efficient use of server compared to the traditional way </li></ul><ul><li>Every customer has his own product on the server </li></ul>LAC2011
  10. 10. Different Environments <ul><li>Data not responsibility customer </li></ul><ul><li>Everyone uses the same product, but gets his own environment and database </li></ul><ul><li>Only one codebase </li></ul><ul><li>Reasonably scalable </li></ul>LAC2011
  11. 11. Multi-user Solution <ul><li>Software as a Service (think about the ‘apartment ‘ example) </li></ul><ul><li>Data not responsibility customer </li></ul><ul><li>A product is offered completely as a ‘service’ </li></ul><ul><ul><li>Comparable to water or energy </li></ul></ul><ul><li>Possibility to serve large number of customers with a limited amount of servers </li></ul><ul><li>Facebook, Grooveshark, etc. </li></ul>LAC2011
  12. 12. Multi-tenancy <ul><li>Data not responsibility customer </li></ul><ul><li>A product is offered completely ‘as a service’ </li></ul><ul><li>Possibility to serve large number of customers with a limited amount of servers </li></ul><ul><li>Tenants (customers) can have specific functionality </li></ul><ul><li>Combination between the ‘house’ and ‘apartment’ example </li></ul>LAC2011
  13. 13. Multi-tenancy: Holy grail? <ul><li>A hosted solution </li></ul><ul><li>Sharing of Hardware, Software, Development cost, Deployment cost, Maintenance cost </li></ul><ul><li>Possibility for variability in the product </li></ul><ul><li>Great flexibility in a product can make it difficult to maintain </li></ul><ul><li>Single point of failure </li></ul><ul><li>But most of all…most companies don’t know HOW to implement variability! </li></ul>LAC2011
  14. 14. What is variability? <ul><li>Possibility to adapt a software product to a specific situation </li></ul><ul><li>During design </li></ul><ul><ul><li>Different product for Linux than for Windows </li></ul></ul><ul><li>During compilation </li></ul><ul><ul><li>Point to different sections of code while compiling software for a specific phone </li></ul></ul><ul><li>Linking at installation </li></ul><ul><ul><li>Linking a product to several additional modules </li></ul></ul><ul><li>Run-time </li></ul><ul><ul><li>When a user of an on-line system wants to change something </li></ul></ul>LAC2011
  15. 15. Runtime variability LAC2011
  16. 16. Case 1 - Exact LAC2011
  17. 17. Case 1 – Exact <ul><li>Had (and have) an on-premises solution </li></ul><ul><li>Started Exact Online a few years ago </li></ul><ul><li>15.000 customers </li></ul><ul><li>Database change </li></ul><ul><li>All customers (in principle) use the same database and software instance. </li></ul><ul><li>Customizations per customer are difficult </li></ul>LAC2011
  18. 18. Architecture Exact Online LAC2011
  19. 19. Overview ASP to Multi-tenancy (Kwok et al., 2008) LAC2011
  20. 20. So, where are we now? <ul><li>Software is increasingly offered ‘ as a Service ’ (Ma, 2007) </li></ul><ul><li>Customers want a product to do ‘what they want’ </li></ul><ul><li>Complying to customer specific requirements in a SaaS environment has drawbacks: </li></ul><ul><ul><li>Difficulty with scalability </li></ul></ul><ul><ul><li>Difficulty with maintainability </li></ul></ul><ul><ul><li>Architectural erosion </li></ul></ul><ul><li>Multi-tenancy enables software vendors to offer a SaaS product in a cost efficient way (Guo et al., 2007) </li></ul>LAC2011
  21. 21. What are Design Patterns? <ul><li>A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components , their responsibilities and relationships , and the ways in which they collaborate (Buschmann et al., 1996) </li></ul>LAC2011
  22. 22. When do you need Multi-tenancy? LAC2011
  23. 23. Pattern Catalogue <ul><li>Identify Run-time Variability Patterns currently used </li></ul><ul><ul><li>Case study at AFAS </li></ul></ul><ul><ul><li>Case study at Exact </li></ul></ul><ul><li>Identify RVPs in literature (literature study) </li></ul><ul><li>Come up with new RVPs (design science) </li></ul>LAC2011
  24. 24. <ul><li>Example Patterns </li></ul>LAC2011
  25. 25. Pattern Example <ul><li>In a warehousing system, customer A wants an SMS to be send to the truck driver when an order is picked, after which the order is removed from the system . Customer B however does not want any SMS to be send, but does want an approval by a manager before a picked order is removed from the system. </li></ul><ul><li>How can we solve this workflow related problem? </li></ul>LAC2011
  26. 26. Pre/Post Update Hooks (1/3) LAC2011
  27. 27. Pre/Post Update Hooks (2/3) <ul><li>Intent - To provide the possibility for tenants to have custom functionality just before or after an event </li></ul><ul><li>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 </li></ul><ul><li>Solution – The use of a component able of calling other components before and after the update of data. The tenant-specific modules are listed in a separate table </li></ul>LAC2011
  28. 28. Pre/Post Update Hooks (3/3) <ul><li>Explanation – See image </li></ul><ul><li>Consequences - Extra optional components have to be available in the software system in order to be able to implement this pattern </li></ul><ul><li>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 requested </li></ul>LAC2011
  29. 29. Conclusion and Further Research <ul><li>Design patterns are an appropriate way to document and communicate solutions to the variability problem </li></ul><ul><li>The proposed patterns should be evaluated </li></ul><ul><li>How are patterns really used ? </li></ul><ul><li>We need mor e patterns and feedback on existing patterns </li></ul><ul><li>We are looking for research partners </li></ul><ul><ul><li>Mail: [email_address] </li></ul></ul>LAC2011