Lately, my colleague Gianpaolo and I have been talking to many SaaS startups and SaaS company wannabes. Our current verdict: single instance, multi-tenancy is still a black art that only selected few have been able to master.

 

Looking through the lens of an architect, architecting software as a service is an area sorely in need of better guidance. Of the companies I have spoken to, some have redelivered classic client-server applications using technology similar to terminal server so that they can expedite the time-to-market, only to run into scalability issues when the market demand for their software service takes off; some have chosen to put all their customers’ data in one database, with no upfront consideration for data performance and regulatory compliance issues; a few have attempted to solve per tenant data model extensions issues with many battle scars to prove apparent intractability of the perfect solution…

 

This is great. The above are all reasons why I have a day job…

 

I’ve been spending a lot of time looking into how my team can help lower the bar for software vendors to deliver software as a service. I’m a fan of SaaS, because I believe this software delivery mechanism changes the economics of the software industry in a way that allows online information and computing to be accessible to many more people in emerging markets such as India and China. This is a topic that warrants a separate posting a different time. For now, I want to highlight what Microsoft is bringing to the table in terms of SaaS architecture guidance.

 

If I can try to summarize the key areas where architects should spend their time, it would be the following:

 

  • Scale the application
  • Enable multi-tenant data
  • Facilitate customization

 

Scaling the application means maximizing concurrency and using application resources more efficiently – optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data and partitioning large databases are examples of best practices for scaling applications to a large number of users.

 

The single-tenant data models of many existing on-premise applications constrain running application instance to only use operation and business data owned by a single organization. In a multi-tenant SaaS environment, this application instance and data ownership binding must be relaxed. For example, when a user from Acme is accessing customer information using a CRM application service, the application must be able to retrieve the customer data for Acme and not for any other companies. In order to enable multi-tenancy, the underlying application data model must be designed to accommodate flexibility for manipulating tenant specific data.

 

Many SaaS customers will want to customize the application services they subscribe to. Altering workflows, extending business documents, modifying business rules and customizing brands, logos and user interfaces are all within the plausible realms of application customizations. The challenge for the SaaS architect is to ensure that the task of customizing applications is simple and easy for the customers, yet at the same time, not incur extra manual development or operation costs for each customization. Expect meta-data to play a big part in SaaS solutions.

 

Of course, accomplishing these feats is no child’s (or the average architect (this may be an oxy-moron)) play – especially for existing applications that are client-server based and those that are miles away from being scalable, multi-tenant ready and customizable.

 

I don’t know about you, for me, all these thinking really beg the question - what would a book on SaaS architecture guidance look like? After an evening of cranking and a few iterations with fellow architects, I have scoped out the table of content of a potential bestseller:

 


 

1. Introduction

  • Definitions
  • Differences from traditional ASP model
  • SaaS value proposition
  • Realizing SaaS = business model + application architecture + operation structure

 

2. Business Model

  • Revenue and licensing model
    • Additional services revenue: configuration and customization
  • Sales compensation model
  • Types of software services
  • Designing SaaS SLA and contracts

 

3. Application Architecture Overview

  • Instancing and multi-tenancy
  • Comparisons of application architecture: on-premise, ASP, SaaS
  • SaaS maturity model
  • SaaS application architecture issues: identity, data, workflow, messaging, design for manageability, service-orientation, scaling, tenancy, meta-data, service consumption etc.
  • Overview of SaaS capabilities and enablement architecture

 

4. Scaling 101

  • Pools: thread, connections etc.
  • Async
  • Locks
  • States
  • UI/Presentation

 

5. Data Management

  • Partitioning for scaling and performance
    • Data partitioning schemes: Spatial, temporal, hashing etc., SQL Server 2005 support for data partitioning
    • Data distribution patterns and functions
    • Dynamic partitioning: re-partitioning growing database
  • Data availability
    • Replication strategy

 

6. Tenant Management

  • Data model for tenant management
  • Subscription Management
  • Identity management
    • Models
  • Delegated administration

  • Identity federation

  • Hybrid: e.g. federation for tenants and delegated admin for tenants' customers.

 

7. Tenant Customization

  • Meta data service for customization
  • Approaches for extending application data model
  • Approaches for UI customization
  • Approaches for business process customization
  • SaaS and system integrations modes:
    • In house systems to SaaS integration (main app is in house)
    • SaaS to in house systems integration (SaaS is the main app)
    • SaaS with partial SaaS solution hosted on premise
    • SaaS to SaaS integration
      • Direct
      • Hub-and-spoke through SaaS integration platform (like Salesforce’s AppForce)

 

 

8. Application and Data Security

  • Common authentication schemes: username/pwd, certificates
  • Application single sign-on
  • Securing data transfer
    • Application security session
    • Session data integrity and privacy
    • Transport vs. application level security
  • Authorization
    • Schemes: ACL, RBAC, business rules
    • Policy management: distributed/resource, centralized
  • Application security abstractions:
    • Tokens, claims, security token services, security policies
  • Trusted sub-system model for securing application tiers
  • Identity context propagation
  • Secret/key management: for application and tenants
  • Data isolation schemes
    • Database access control: RBAC, views etc.
    • Partitioning:
      • Logical: tables, databases
      • Physical: disks
    • Database encryption

 

 

9. Programmable Software Services

  • Software service lifecycle
  • Service versioning
  • Service certification, registration and publication
  • Software service registry
    • Requirements
    • Architecture

 

10. Programmable Software Service Consumption

  • Function vs. data oriented services (web service vs. RSS vs. REST etc)
  • Composite applications
  • Tools and community framework

 

11. Instrumentation and Monitoring

  • Types, goals and audience of instrumentation: infrastructure, application stack, business logic
  • Instrumentation constructs: counters, events, rules, threshold, alerts
  • Health monitoring
  • Availability monitoring
  • Business performance monitoring

 

12. Configuration Management

  • Change management requirements
  • Configuration management architecture

 

13. Metering

  • Usage models
  • Data model for each metering
  • Usage tracking architecture

 

14. Infrastructure Security

  • Network and firewall design
  • Intrusion detection
  • Protecting against viruses and worms
  • Protecting against denial of service attacks

 

15. Operation Structure

  • Provisioning
    • Infrastructure
    • Application
    • Tenants
  • Disaster recovery
  • Billing
  • Network operation center
  • Call center

 

Appendix

  • SaaS enablement roadmap: from on-premise and ASP to SaaS
    • Scenarios and SaaS enablement strategy
  • Enabling SaaS to on-premise solution migration
    • Deploy existing SaaS solution and subscription to on-premise
    • Need to de-mingle data to be hosted on-premise

 


 

 

This book will not appear in a big bang. Instead, following the tradition of Microsoft CTP practice, you can expect to see partial but frequent releases of guidance papers from us. Also be prepared to see the chapters being revealed out of sequence.

 

I expect my future contributions to the guidance to be an exciting journey, with perhaps a happy destination to look forward to when the final chapter is pen. But for our SaaS ISVs, SaaS is truly a journey, with new challenges and solutions to deal with as they mature in each stage of their SaaS business model, application architecture and operational excellence.

 

Your SaaS journey can be exciting too – we invite you to walk with us when we open the chapter into this new era of software delivery.