Successful SaaS - what will it take? Eric Nelson Application Architect Microsoft Ltd

RECAP... Why should an ISV care?

Achieve enormous wealth Achieve enormous wealth Money Predictable revenue New revenue Shorter sales cycles Lower cost of sales Reduced support and maintenance costs

I want your cool SaaS App! Gain millions of new customers Gain millions of new customers I want your cool SaaS App! Opportunities “The Long Tail” New geographies

Become more desirable Become more desirable Agility Quick to enter new markets Quick to respond to competitors Quick to respond to customers Loyalty Try before you buy Tighter Relationship Responsive After SAAS Before SAAS

Yet don’t work very hard Yet don’t work very hard Simplicity One version of the application deployed Core vs Custom headaches vanish No more onsite visits No more customers tinkering with your code No more competitors spying on your code Less sales people (selling something you haven’t built)

Ah... but... There is a Huge Impact on... Business Model Sales and Marketing Technical Model Need to execute well in all 3 areas

Sidebar: SaaS-less SaaS? SaaS benefits on-premise? Benefits: Rapid provisioning Reduced initial costs Immediate Value High degree of configuration vs customisation Seamless deployment Seamless upgrades Address the “long tail”

TECHNICAL CHALLENGES I suppose there are a few I 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

shareisolate 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 extension Easy to restore tenant data More security isolation Tradeoff: Number of tenants per database server is low Higher 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 extension Moderate security isolation Better 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 important OK 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 data Harder to implement data model extension When to use: Scale per server is important OK to co-mingle tenant data in same database same database, same schema

single instance, mult-tenant

Configurable

considerations meta-data UI/branding workflow and rules data model extensions access 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 - LitwareHR Addressing the major architectural challenges of a SaaS application for the “Long Tail“ Available for download

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 access Configuration & Post jobs Private site Web Interface Unauthenticated access Search & Apply for jobs Web APIs Public site Web Interface InternetInternet Music School Retail Shoe Chain Operational Platform “Internal” SaaS Hosting Platform Provisioning (try before buy) Billing (not implemented)

LitwareHR Act 1: Tenant Sign Up and Provisioning

TenantProvisioningServiceTenantProvisioningService ADAMADAM SQL Database IISIIS Provisioning Process Workflow

LitwareHR Act 2: Configuring Application

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 right Plenty of stuff to get wrong 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 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 NameData Type 999LocationShort Text 888JobLevelNumber 3. Multi-tenant Data Store Extension name-value pair Extension Row IDValueExtension ID ABC…999 DEF… Extensible Data Model 1. Tenant Configurable Data View Extension meta data