29
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

Landelijke Architectuur Congres 2011

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Landelijke Architectuur Congres 2011

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

Page 2: Landelijke Architectuur Congres 2011

2

Outline

Introduction

Deployment Models Traditional Online

Concepts Variability Multi-tenancy

Case Example

Example Pattern

Conclusion and Future Research

LAC2011

Page 3: Landelijke Architectuur Congres 2011

3

Research Project

Utrecht University

University of Groningen

Two large ERP product software vendors from the Netherlands

Exact AFAS

www.productasaservice.org

LAC2011

Page 4: Landelijke Architectuur Congres 2011

4

First something completely different!

Based on work of dr. Andy Zaidman (TUDelft)

LAC2011

Page 5: Landelijke Architectuur Congres 2011

5

Pros and Cons

House Apartment

Effective use of land - +

Privacy + -

Infrastructure sharing - +

Maintenance cost sharing - +

Freedom + -

House: Privacy en freedomApartment: Cost efficiency

LAC2011

Page 6: Landelijke Architectuur Congres 2011

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

Page 7: Landelijke Architectuur Congres 2011

7

Traditional – Disadvantages

High initial costs for customers

Hard to keep up with updates

Lack of expert knowledge

High change of data loss

LAC2011

Page 8: Landelijke Architectuur Congres 2011

8

Overview Online Deployment Models

(Kwok et al., 2008)

LAC2011

Application Server Provider

Multi-user Solution

Different Environments

Multi-tenancy

Page 9: Landelijke Architectuur Congres 2011

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

Page 10: Landelijke Architectuur Congres 2011

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

Page 11: Landelijke Architectuur Congres 2011

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

Page 12: Landelijke Architectuur Congres 2011

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

Page 13: Landelijke Architectuur Congres 2011

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

Page 14: Landelijke Architectuur Congres 2011

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

Page 15: Landelijke Architectuur Congres 2011

15

Runtime variability

LAC2011

Page 16: Landelijke Architectuur Congres 2011

16

Case 1 - Exact

LAC2011

Page 17: Landelijke Architectuur Congres 2011

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

Page 18: Landelijke Architectuur Congres 2011

18

Architecture Exact Online

LAC2011

Page 19: Landelijke Architectuur Congres 2011

19

Overview ASP to Multi-tenancy

(Kwok et al., 2008)

LAC2011

Page 20: Landelijke Architectuur Congres 2011

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

Page 21: Landelijke Architectuur Congres 2011

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

Page 22: Landelijke Architectuur Congres 2011

22

When do you need Multi-tenancy?

LAC2011

Page 23: Landelijke Architectuur Congres 2011

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

Page 24: Landelijke Architectuur Congres 2011

24

Example Patterns

LAC2011

Page 25: Landelijke Architectuur Congres 2011

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

Page 26: Landelijke Architectuur Congres 2011

26

Pre/Post Update Hooks (1/3)

LAC2011

Page 27: Landelijke Architectuur Congres 2011

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

Page 28: Landelijke Architectuur Congres 2011

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

Page 29: Landelijke Architectuur Congres 2011

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