1. EMEA Jürgen Pfeifer Architect, MCA Microsoft EMEA HQ http://blogs.msdn.com/juergenp Building SaaS Solutions

2. EMEA Consuming SaaS

3. EMEA enterprise Purchase The Enterprise

4. EMEA From Evaluation...

5. EMEA To „Try before you buy“...

6. EMEA enterprise Purchase Deploy long eval process try before you buy The Enterprise

7. EMEA From Customization...

8. EMEA To Configuration...

9. EMEA enterprise Purchase DeployManage long eval process try before you buy customisation configuration The Enterprise

10. EMEA From reliance on internal IT...

11. EMEA Contract To SLAs...

12. EMEA enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs The Enterprise

13. EMEA SaaS ISV considerations

15. EMEA independent software vendors (ISVs) enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs enable try before you buy SaaS Vendors

17. EMEA independent software vendors (ISVs) enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs enable try before you buy enable no-code config SaaS Vendors

19. EMEA independent software vendors (ISVs) enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs enable try before you buy enable no-code config enable SLA infrastructure SaaS Vendors

20. EMEA enable economies of scale independent software vendors (ISVs) enable try before you buy enable no-code config enable SLA infrastructure enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs SaaS Vendors

21. EMEA Monetisation

25. Monetization Scheme matters  For the Enterprise  No upfront perpetual license cost  Finance people like predictable recurring cost  For the ISV  Subscription model provides better predicability of revenue streams

26. EMEA independent software vendors (ISVs) enable economies of scale enable try before you buy enable no-code config enable SLA infrastructure enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs enable monetisation schemes SaaS Vendors

27. EMEA

29. referrals & breadth marketing self provisioning self-customisation delegated administration automatic billing Minimize human intervention

30. EMEA independent software vendors (ISVs) enable economies of scale enable try before you buy enable no-code config enable SLA infrastructure enterprise Purchase DeployManage long eval process try before you buy customisation configuration reliance on internal IT SLAs enable monetisation schemes enable minimal intervention SaaS Vendors

31. EMEA User Experience counts

35. EMEA Architectural Impact Very Visible Business Opportunities Often Overlooked Architectural Challenges Business OpportunitiesArchitectural Challenges Serving the “long tail” “try before you buy” Subscription model Business SLAs Multi-tenancy / Scale Self service / Automatic provisioning Metering / Billing SLA Monitoring/Enforcement (Examples)

36. EMEA shareisolate vs The right balance is determined by: Business model (can I monetise?) Business model (can I monetise?) Architectural model (can I do it?) Architectural model (can I do it?) Operational model (can I guarantee SLAs?) Operational model (can I guarantee SLAs?) Regulatory constraints (can we share data?) Regulatory constraints (can we share data?) SLA per tenant Data Separation Economy of Scale Simpler Management

37. EMEA Browser Smart Client Presentation Process Services Business Services Meta Data Services Security Services Directory Service Databases File System Meta Data High Level Application Architecture

38. EMEA Application Runtime (same code image) Tenant Profile and Configuration Data Meta Data Service Farm of deployed application runtime components Entity Model Workflow and Rules User Interface Application Configuration and Designer Tools Virtual application instance Configurability Scaleability Multi-tenant efficiency Metadata Driven Instances

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

40. EMEA Meta-Data : UI/Branding

41. EMEA Meta-Data: Configure Workflows

42. EMEA 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 Meta Data: Data Model Extension

43. EMEA Meta-Data: Access Control

44. EMEA UI/Branding Workflow and Rules Data model extensions Access Control … other domain specific considerations… Meta-Data Considerations

45. EMEA GUIDANCE

46. Sample Application  Microsoft has developed a sample application („Litware HR“)  Addressing all the major architectural challenges of a SaaS application for the „Long Tail“  Is available for download on MSDN  http://msdn.microsoft.com/architecture/saas/sampleApp http://msdn.microsoft.com/architecture/saas/sampleApp

47. Contoso Customizations: UI: “Contoso Orange” L&F Data: New “Job Level” Field Workflow: Recruitement based on Job Level Roles and Access: HR Manager, CEO Litware HR: A Sample SaaS App HR App (Recruitment) Single Instance Multi Tenant Authenticated access Configuration & Post jobs Private site Web Interface Fabrikam Customizations: UI: Fabrikam L&F Data: New “Audition Required” Field Workflow: based on “audition required” Roles and Access: Audition Judge, Owner Unauthenticated access Search & Apply for jobs Web APIs Public site Web Interface Internet Music SchoolRetail Shoe Chain Operational Platform “Internal” SaaS Hosting Platform Provisioning (try before buy) Billing (not implemented)

48. EMEA Configurable UI  Well understood topic on Microsoft Platform  For Web Apps:  ASP.NET 2.0, AJAX: CSS, Masterpages, Themes etc.  For Windows Apps:  Use „Windows Presentation Foundation“ (WPF)

49. EMEA Configurable Workflow  Workflow Foundation  Uses Markup  Can be stored, manipulated, executed on a per tenant basis

50. EMEA Workflow Customization: Design Time Hosted Designer Loads “current” workflow definition (from.xoml file) Manipulates workflow object model Serialize modified object model Calls Web Service to update.xoml Customization type Behavioral (decisions/rules) Structural (activities)

51. EMEA public WorkflowInstance CreateWorkflow (XmlReader workflowDefinitionReader); Workflow Customization: Runtime XAML Activation

52. EMEA Configurable Data  Challenges:  Defining custom fields and storing custom data for each tenant.  Business logic that can handle custom fields  Presentation logic that can handle custom fields Tenant A Product ID Description Category ID Catalog Item Tenant B Product ID Description Classification Code Catalog Item

53. EMEA ApproachSecurity PatternsExtensibility PatternsScalability Patterns Separate DatabasesTrusted Database Connections Custom ColumnsSingle Tenant Scaleout Secure Database Tables Tenant Data Encryption Shared Database, Separate Schemas Trusted Database Connections Custom ColumnsTenant-Based Horizontal Partitioning Secure Database Tables Tenant Data Encryption Shared Database, Shared Schema Trusted Database Connections Preallocated FieldsTenant-Based Horizontal Partitioning Tenant View FilterName-Value Pairs Tenant Data Encryption Database Patterns

54. EMEA Custom Fields Data and Definition  Meta-data/data dictionary required  3 general approaches:  Separate database for each tenant  Shared database, a canned set of extended fields  Shared database, any number of extended fields  Tradeoff between each approach

55. EMEA Dedicated Tenant Database  Approach:  Separate database for each tenant  Database maintains data dictionary  Advantages:  Easy to implement  Meta data identifies database instance for each tenant  Tradeoff:  Number of tenants per database server is low  Infrastructure cost of providing service rise quickly  When to use:  When tenant has data isolation requirements  Able to monetize the data extension/isolation feature Tenant 1 Tenant 3 Tenant 2

56. EMEA Shared Database, fixed set of extensions  Approach:  All tenants data in one database.  Pre-defined set of custom fields  Advantages:  Easy to implement  Maximize number of tenants per database server  Tradeoff:  Tendency to results in sparse table  When to use:  When data co-mingling is OK  Easy to anticipate pre-defined custom fields Tenant ID F1F2C1C2C3 345Ted53NullpaidNull 777Kay3423NullNull 784Mary45NullNullNull 345Ned21NulloweNull 438Pat26NullNullyes

57. EMEA Same database, variable custom extensions  Approach  All tenants in one database  Variable number of custom fields  Name-value pair in separate tables  Advantage  “Unlimited” number/option for custom fields  Tradeoff  Increase index/search/query/update complexity  When to use  OK to co-mingle tenant data  Custom fields are high value features  Difficult to predict custom fields Tenant ID F1F2 Record ID 764Ted$56893 673John$32Null 783Sal$99564 NameValue893StatusGold 893Expire7-29-2008 564AffiliationAcme

58. EMEA Data: a practical advice  Consider design for the most general case, the single shared database  If a customer wants isolation, just deploy him on a single instance  Pro: This approach gives you the greatest flexibility.  Con: More complex queries, may affect performance

59. EMEA Scaling Application  Stateless  Improve service memory footprint  Improve ability to load balance  Asynchronous I/O  Do useful work while waiting for I/O to complete  Resource Pooling  Threads, network and database connections  Maximize concurrency  Minimize exclusive locking

60. EMEA Scaling Data  Data Partition (horizontal)  Divide subscriber data into smaller partitions to meet performance goals  Schemes: hashing, temporal, etc.  Dynamic Repartitioning  Automatically repartition when database size reaches maximum size

61. EMEA Implication on Identity Architecture  Use identity federation to achieve SSO  How to manage trust – PKI  Standard-based products (WS-Federation, SAML etc)  Use claims-centric architecture to communicate access policies  Signed attributes and assertions to rely on roles and access rules information:  E.g. authorized to purchase if amount < 50

62. EMEA Access Control  Some Platform Technologies to consider  ADFS  Windows Role Based Access Control (RBAC)  Authorization Manager (AzMan)

63. EMEA Access Control Role Users Groups Permission … Business Rules  Authorization policies can be defined at different scopes (enterprise, dept etc.)  Permissions, roles, groups and business rules can be customizable per tenant SCOPE

64. EMEA SLAs  SLA Monitoring  Availability  Performance  SLA Enforcing  Rules, notification and alerts  Automated Resource Allocation  Automated provisioning  Early evidence shows SaaS customer are expecting more when hosted than in-house

65. EMEA Composition & Integration  Provide clean and well defined Service Interfaces  Follow SOA best practices  For Enterprise: support SOAP style and WS-* if necessary. Windows Communication Foundation (WCF) is your friend  For Consumer SaaS: support REST style (again, WCF is your friend)  Be OBA friendly (Office Business Applications)  Emerging Office based Composite App Framework

66. EMEA “Classic” Hosting CPU-Storage-Bandwidth Shared Services: e.g. Billing, Metering, SLA Monitoring… a.k.a. SO Infra, Service Delivery Platform, OSS/BSS As provider: do you build or buy the hosting? “Classic” Hoster SaaS Hoster SaaS Provider Shared Services

67. EMEA SaaS Hosting Platform: Operational Security Log SaaS Application Identity Management Usage Tracking CRM Call Center Support System Management Log SaaS Application Performance Availability Security SLA Monitoring Provisioning Management Agent Access Control Metering Order Management SaaS Hosting Platform Runtime Billing Management Alerts

68. EMEA Business Implications  Perpetual licenses to Subscription model  Ad based revenue  Critical mass on new business  ‘Long-tail’, low-margin customers  Customer acquisition and retention MS Service Provider License Agreement (SPLA) No Up-Front Cost No Minimum Commitment Success-based, Pay What You Use Two Models: Per User or Per CPU Right to Upgrade Evaluation Period Extended No cost for Disaster Recovery Licenses SPLA Feedback Project

69. EMEA Call to Action  ISV “council” for “collaborative” efforts  isvsaas@microsoft.com isvsaas@microsoft.com  Additional Information  Software as Services Architectural Guidance  http://msdn.microsoft.com/architecture/saas http://msdn.microsoft.com/architecture/saas  Blogs about Architecture :  http://blogs.msdn.com/fred_chong http://blogs.msdn.com/fred_chong  http://blogs.msdn.com/gianpaolo http://blogs.msdn.com/gianpaolo  SaaS sample application (for the long tail)  http://msdn.microsoft.com/architecture/saas/sampleApp http://msdn.microsoft.com/architecture/saas/sampleApp  Service Provider License Agreement  http://www.microsoft.com/serviceproviders/licensing http://www.microsoft.com/serviceproviders/licensing

70. © 2006,2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.