Successful SaaS - what will it take?

1. Successful SaaS - what will it take? Eric Nelson Application Architect Microsoft Ltd http://blogs.msdn.com/ericnel

2. Why should an ISV care? RECAP...

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

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

5. 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 Before SAAS After SAAS

6. 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)

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

8. 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”

9. I suppose there are a few  Technical Challenges

10. Basic SaaS Maturity Model 1. ad-hoc /custom 2. configurable single tenant 4. configurable multi tenant (scalable) 3. configurable multi tenant

11. Three Headed Monster Scaleable Configurable Multi-Tenant Efficient

12. multi-tenant data architectures

13. vs share isolate business model (can I monetise?) architectural model (can I do it?) operational model (can I guarantee SLAs?) regulatory constraints (can we share data?)

14. 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 separate database per tenant Tenant A Tenant B Tenant C

15. same database, separate schema • 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 Tenant A Tenant B Tenant C

16. same database, same schema • 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 Tenant B Tenant A Tenant C

17. single instance, mult-tenant

18. Configurable

19. meta-data considerations UI/branding workflow and rules data model extensions access control … other domain specific considerations…

20. meta-data UI/branding

21. meta-data workflow/rules

22. we want to track customer colour preferences we want to keep track of customer visits online our customers have peculiar address formats we need to track customer history by product meta-data data model extensions

23. 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 • http://www.codeplex.com/litwarehr

24. Litware HR: A Sample SaaS App Retail Shoe Chain Music School Contoso Customizations: UI: “Contoso Orange” L&F Data: New “Job Level” Field Workflow: Recruitement based on Job Level Internet Web Interface Web APIs Web Interface Public site Private site Unauthenticated access Search & Apply for jobs Authenticated access Configuration & Post jobs Operational Platform “Internal” SaaS Hosting Platform Provisioning (try before buy) Billing (not implemented) HR App (Recruitment) Single Instance Multi Tenant

25. LitwareHR demo • Act 1: Tenant Sign Up and Provisioning

26. Tenant Provisioning Behind the Scene Tenant Provisioning Service ProvisioningProcessWorkflow SQL Database IIS ADAM

27. LitwareHR demo • Act 2: Configuring Application

28. Meta Data Driven Architecture Application Configuration and Designer Tools User Interface Workflow and Rules Entity Model Runtime Meta Data Service Tenant Profile and Configuration Data

29. 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”

30. Appendix

31. Templatized Configuration Design Time Runtime Policies Designer Policy Enforcement Engine Runtime Policy Enforcement Engine Security, Fairness and Halting Policies Metadata Standard Customers Runtime Metadata Runtime Metadata Premium Customers Runtime Metadata Application Instance Trusted Partners Templatized Designers

32. Data Model Configuration 2. Extensible Data Model 3. Multi-tenant Data Store Entity 1 1. Tenant Configurable Data View View Extension Extension name-value pair Entity 2 Extension meta data Extension