Successful SaaS- what will it take?

Eric NelsonApplication Architect

Microsoft Ltdhttp://blogs.msdn.com/ericnel

RECAP...Why should an ISV care?

Achieve enormous wealth

MoneyPredictable revenueNew revenueShorter sales cyclesLower cost of salesReduced support and maintenance costs

I want your cool SaaS

App!

Gain millions of new customers

I want your cool SaaS

App!

I want your cool

SaaS App!

I want your cool SaaS

App!

Opportunities“The Long Tail”New geographies

Become more desirable

AgilityQuick to enter new marketsQuick to respond to competitorsQuick to respond to customers

LoyaltyTry before you buyTighter RelationshipResponsive

After SAAS

Before SAAS

Yet don’t work very hard

SimplicityOne version of the application deployedCore vs Custom headaches vanishNo more onsite visitsNo more customers tinkering with your codeNo more competitors spying on your codeLess sales people (selling something you haven’t built)

Ah... but... There is a Huge Impact on...

Business ModelSales and MarketingTechnical ModelNeed to execute well in all 3 areas

Sidebar: SaaS-less SaaS?

SaaS benefits on-premise?Benefits:

Rapid provisioningReduced initial costsImmediate ValueHigh degree of configuration vs customisationSeamless deploymentSeamless upgradesAddress the “long tail”

TECHNICAL CHALLENGESI suppose there are a few

1. ad-hoc

/custom

2. configurable single tenant

3. configurable multi tenant

4. configurable multi tenant (scalable)

Basic SaaS Maturity Model

Three Headed Monster

Configurable

Scaleable

Multi-Tenant Efficient

multi-tenant data architectures

share isolate

vs

business model (can I monetise?)architectural model (can I do it?)operational model (can I guarantee

SLAs?)regulatory constraints (can we share

data?)

Approach:Meta data identifies database instance for each tenant

Advantages:Easy to implement data model extensionEasy to restore tenant dataMore security isolation

Tradeoff:Number of tenants per database server is lowHigher management, backup cost and database server infrastructure costs

When to use:When tenant has specific database isolation requirements

Tenant A

Tenant C

Tenant B

separate database per tenant

Tenant A

Tenant B

Tenant C

Approach:Each tenant gets their own group of tables in the same database.

Advantages:Easy to implement data model extensionModerate security isolationBetter tenant scale per server

Tradeoff:More difficult to restore tenant data

When to use:Number of tables for the app is small (100s)Scale per server is importantOK to co-locate tenant data in same database

same database, separate schema

Tenant A

Tenant B

Tenant C

Approach:All tenants use the same set of tables in the same database.

Advantages:Better tenant scale per server Cost of management and backup is lower

Tradeoff:Difficult to restore tenant dataHarder to implement data model extension

When to use:Scale per server is importantOK to co-mingle tenant data in same database

same database, same schema

single instance, mult-tenant

Configurable

considerations

meta-data

UI/brandingworkflow and rules

data model extensionsaccess control

… other domain specific considerations…

UI/branding

meta-data

workflow/rules

meta-data

data model extensions

meta-data we want to track customer

colour preferences

our customers have peculiar

address formats

we need to track customer

history by product

we want to keep track of

customer visits online

Sample Application

Microsoft has developed a sample application - LitwareHRAddressing the major architectural challenges of a SaaS application for the “Long Tail“Available for download

http://www.codeplex.com/litwarehr

Contoso Customizations:UI: “Contoso Orange” L&F Data: New “Job Level” Field

Workflow: Recruitement based on Job Level

Litware HR: A Sample SaaS App

HR App (Recruitment)Single Instance Multi Tenant

Authenticated accessConfiguration & Post jobs

Private site

Web Interface

Unauthenticated accessSearch & Apply for jobs

Web APIs

Public site

Web Interface

Internet

Internet

Music SchoolRetail Shoe Chain

Operational Platform

“Internal” SaaS Hosting PlatformProvisioning (try before buy)

Billing (not implemented)

LitwareHR

Act 1: Tenant Sign Up and Provisioning

demo

TenantProvisioning

Service

TenantProvisioning

Service

ADAMADAM

SQL Database

SQL Database

IISIIS

Tenant Provisioning Behind the Scene

Provisioning Process Workflow

LitwareHR

Act 2: Configuring Application

demo

Meta Data Driven Architecture

Tenant Profile and

Configuration Data

Meta Data Service

Entity Model

Workflow and Rules

User Interface

Application Configuration and Designer Tools

Runtime

Summary

Plenty of stuff to get right Plenty of stuff to get wrong LitwareHR is a good starting point

But... plenty “left to the reader”

Appendix

Templatized Configuration

Templatized Designers

Trusted Partners

Premium Customers

Standard Customers Runtime

Metadata

Runtime Metadata

Runtime Metadata

Policies

Security, Fairness

and Halting Policies

Runtime Policy Enforcement

Engine

Design Time Runtime

Application Instance

Metadata

Designer Policy

Enforcement Engine

View

Entity 1

Entity 2

Extension

Tenant ID … Row ID

123 … …

456 … …

Extension ID

Name Data Type

999 Location Short Text

888 JobLevel Number

3. Multi-tenant Data Store

Extension name-value pair

Extension

Row ID Value Extension ID

ABC … 999

DEF … 888

2. Extensible Data Model

1. Tenant Configurable

Data View

Data Model Configuration

Extension meta data