Upload
jaap-kabbedijk
View
384
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Slides and research by J. Kabbedijk, Msc.Presentation by prof.dr. S. Brinkkemper
Citation preview
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
Outline
Introduction
Deployment Models Traditional Online
Concepts Variability Multi-tenancy
Case Example
Example Pattern
Conclusion and Future Research
LAC2011
3
Research Project
Utrecht University
University of Groningen
Two large ERP product software vendors from the Netherlands
Exact AFAS
www.productasaservice.org
LAC2011
4
First something completely different!
Based on work of dr. Andy Zaidman (TUDelft)
LAC2011
5
Pros and Cons
House Apartment
Effective use of land - +
Privacy + -
Infrastructure sharing - +
Maintenance cost sharing - +
Freedom + -
House: Privacy en freedomApartment: Cost efficiency
LAC2011
6
Traditional Deployment Model
Think about the ‘House’ example
Customers have to install and update their own software
Customers manage their own data
Every customers needs his own server to deploy the product
Customizations can easily be done per customer
LAC2011
7
Traditional – Disadvantages
High initial costs for customers
Hard to keep up with updates
Lack of expert knowledge
High change of data loss
LAC2011
8
Overview Online Deployment Models
(Kwok et al., 2008)
LAC2011
Application Server Provider
Multi-user Solution
Different Environments
Multi-tenancy
9
Application Server Provider
Data not responsibility customer
Application is hosted at a third party
Multiple products are hosted on the same machine
More efficient use of server compared to the traditional way
Every customer has his own product on the server
LAC2011
10
Different Environments
Data not responsibility customer
Everyone uses the same product, but gets his own environment and database
Only one codebase
Reasonably scalable
LAC2011
11
Multi-user Solution
Software as a Service (think about the ‘apartment ‘ example)
Data not responsibility customer
A product is offered completely as a ‘service’
Comparable to water or energy
Possibility to serve large number of customers with a limited amount of servers
Facebook, Grooveshark, etc.
LAC2011
12
Multi-tenancy
Data not responsibility customer
A product is offered completely ‘as a service’
Possibility to serve large number of customers with a limited amount of servers
Tenants (customers) can have specific functionality
Combination between the ‘house’ and ‘apartment’ example
LAC2011
13
Multi-tenancy: Holy grail?
A hosted solution
Sharing of Hardware, Software, Development cost, Deployment cost, Maintenance cost
Possibility for variability in the product
Great flexibility in a product can make it difficult to maintain
Single point of failure
But most of all…most companies don’t know HOW to implement variability!
LAC2011
14
What is variability?
Possibility to adapt a software product to a specific situation
During design Different product for Linux than for Windows
During compilation Point to different sections of code while compiling software for a
specific phone
Linking at installation Linking a product to several additional modules
Run-time When a user of an on-line system wants to change something
LAC2011
15
Runtime variability
LAC2011
16
Case 1 - Exact
LAC2011
17
Case 1 – Exact
Had (and have) an on-premises solution
Started Exact Online a few years ago
15.000 customers
Database change
All customers (in principle) use the same database and software instance.
Customizations per customer are difficult
LAC2011
18
Architecture Exact Online
LAC2011
19
Overview ASP to Multi-tenancy
(Kwok et al., 2008)
LAC2011
20
So, where are we now?
Software is increasingly offered ‘as a Service’ (Ma, 2007)
Customers want a product to do ‘what they want’
Complying to customer specific requirements in a SaaS environment has drawbacks:
Difficulty with scalability Difficulty with maintainability Architectural erosion
Multi-tenancy enables software vendors to offer a SaaS product in a cost efficient way (Guo et al., 2007)
LAC2011
21
What are Design Patterns?
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)
LAC2011
22
When do you need Multi-tenancy?
LAC2011
23
Pattern Catalogue
Identify Run-time Variability Patterns currently used Case study at AFAS Case study at Exact
Identify RVPs in literature (literature study)
Come up with new RVPs (design science)
LAC2011
24
Example Patterns
LAC2011
25
Pattern Example
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.
How can we solve this workflow related problem?
LAC2011
26
Pre/Post Update Hooks (1/3)
LAC2011
27
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-specific modules are listed in a separate table
LAC2011
28
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 requested
LAC2011
29
Conclusion and Further Research
Design patterns are an appropriate way to document and communicate solutions to the variability problem
The proposed patterns should be evaluated
How are patterns really used?
We need more patterns and feedback on existing patterns
We are looking for research partners Mail: [email protected]
LAC2011