ARC219 

Software As a Service (SaaS):

The Good, the Bad and the Ugly

Gianpaolo Carraro
Architecture Strategy Team
gianpc@microsoft.com
http://blogs.msdn.com/gianpaolo
DC-13 Developers Strongly Cautioned
Strong Architectural Language
Limited Visual Studio Wizardry
What is SaaS?

Software deployed as a hosted service and

accessed over the network (Internet).

as opposed to: “on premise”

“SaaS Stack”
 SaaS Impacts the Entire Consumption Cycle :
In particular in the L.O.B. application space

Purchase Deployment Management

From:
From: Customizatio From:
Long Eval Process n Reliance on
internal IT
Enterprise
To: To: To:
Try before you buy Configuratio SLAs
n
Enable: Enable:
Enable:
Try before you Configuratio
SLA monitoring /
ISVs buy n (no custom
enforcement
code)
 Importance of Economy of Scale

Economy
of scale

Hardware Cost People Cost

at Provider at Provider

Enable:
ISVs Economy of Scale
The Long Tail
Dozens of markets of millions or
millions of markets of dozens?
$ / Customer

Your Large Customers

What if you lower your cost of sale (i.e.

lower barrier to entry) and you also lower
cost of operations

Your Typical Customers

New addressable market >> current market

(Currently) “non addressable” Customers

# of Customers
Monetization Options

Subscription (monthly fee per seat)

Transaction based pricing (profit sharing)
Ad-based revenue (e.g. pay per click)

Enable:
Multiple Monetization
ISVs Schemes
Humans are costly

Reduce human intervention

No Direct Sales (but referrals and breadth
marketing)
Self Provisioning
Self Customization
Delegate Administration
Automatic billing

Enable:
ISVs
Impact on YOUR architecture
Requires Architectural Shift:
Single instance – multi tenancy

Multi-tenant efficient
Sharing resources (One instance to run them
all)
Customizable
Customization through configuration
Scaleable
Many applications will require Internet scale
“Basic” SaaS Maturity Model
 Share vs. Isolate

SLA per tenant Share Economy of Scale

Data Separation Isolate Simpler Management

The right balance is determined by:

Business model (“can I monetize isolation?”)
Architectural model (“can I run on a single logical instance?”)
Operation model (“can I guarantee my SLA without isolating?”)
Regulatory constrains “data must be physically separate”)
High Level Application Architecture

Browser
Smart
Client
Presentation

Security
Services Directory
Meta Data
Process Services Service
Services

Business Services

Meta Databases
File
Data
System
Meta Data Service

Customizable:
UI/Branding
UI/Branding Workflow
Scope Data Model
Workflow/Business Rules Business rules
Domain-specific
Data Model Extensions Scope:
Nested hierarchy of
customization
Access Control
Inheritable
E.g. Enterprise,
department, user
Domain-specific ext. levels

0 or more
scopes
 “Peopleware”:
a multitenant HR
application

Powered by
SuzSoft www.suzsoft.com and
Matias Woloski http://staff.southworks.net/blogs/matiaswoloski
High Level Scenario
Contoso: Uses PeoplewareHR Fabrikam: Uses PeoplewareHR

Needs to customize: Needs to customize:

Data Model Data Model
Business Process Business Process

PeoplewareHR: Software to manage training programs

Maximize economy of scale:

Single Web Server, Single Workflow Engine, Single Database
Multi-tenant architecture
Act 1: Multi Tenant Data
Model
Extension Value Pairs
Approach
Offers “Unlimited” Data Tables
number/option for custom
fields Tenant Name Score Record
Extension-value pairs in ID ID
separate tables 764 Ted 56 893
Metadata table keeps track of
data labels and data types for 673 John 32 Null
extensions
783 Sally 99 564
Metadata
Table
Tena Extensi Extensi Dataty
nt ID on ID on pe Record ID Extension Value
Label ID
764 6729 Status ntext 893 6729 Trainee

764 7634 StartD dateti 893 7634 5-29-2006

ate me
564 8903 UCLA
783 8903 Univer ntext
sity
Extension Value Pairs

Advantage
“Unlimited” number/option for custom
fields
Tradeoff
Increase index/query/update complexity
and delay
When to use
OK to co-mingle tenant data
Custom fields are high value features
Difficult to predict custom fields
Shared Database
Fixed Set of Extensions

Approach: Tenant F1 F2 C1 C2 C3
ID
All tenants data in one
345 Ted 53 Null p Null
database. aid
Pre-defined set of custom
fields
777 Kay 34 23 Null Null
Advantages:
Easy to implement
Maximize number of 784 M 45 Null Null Null
tenants per database ary
server
Tradeoff: 345 Ned 21 Null owe Null
Tendency to results in
sparse table
When to use: 438 Pat 26 Null Null yes
When data co-mingling is
OK
Easy to anticipate pre-
defined custom fields
Dedicated Tenant Database
Approach:
Separate database for each
tenant
Database maintains data
dictionary
Advantages:
Tenan t Ten ant Ten ant
Easy to implement 1 2 3
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
Scaling Data

Data Partition
Divide subscriber data into smaller partitions to
meet performance goals
Schemes: hashing, temporal, etc.
Dynamic Repartitioning
Automatically repartition when database size
reaches maximum size

http://msdn.microsoft.com/architecture/learnmore/default.aspx?p
http://msdn.microsoft.com/architecture/learnmore/default.aspx?
=/library/en-us/dnbda/html/ScalOutSQL.asp
Act 2: Multi Tenant Workflow
Workflow Customization: Design
Time
Hosted Designer
Loads “current” workflow definition (from .xoml
file)
Manipulates workflow object model
Seriliaze modified object model
Calls Web Service to update .xoml

Customization type
Behavioral (decisions/rules)
Structural (activities)
 Workflow Customization: Runtime

XAML Activation

public WorkflowInstance CreateWorkflow

(XmlReader workflowDefinitionReader);
Act 3: Running The
Application
Demo: Next Steps

Make it a publicly available “sample

application”
Probable additions
AJAX UI (Atlas) / Office integration
Single sign on
Integration with “on premise” L.O.B. (legacy)
applications
Scale out
More sophisticated cross tenant data access
control
Hooks in “shared services” (billing, monitoring)
<insert yours>
Shared Services

SaaS
Provider

SaaS
Hoster
Shared Services: e.g. Billing, Metering, SLA Monitoring…
a.k.a. SO Infra, Service Delivery Platform, OSS/BSS

“ Cl ass ic” Ho sting “Classic”

CPU -Sto rag e-Ba nd wid th Hoster

As provider: do you build or buy the hosting?

Ask the Zen Master: SOA vs.
SaaS
Resources

Blogs
http://blogs.msdn.com/gianpaolo
http://blogs.msdn.com/fred_chong

Web Sites
http://msdn.microsoft.com/architecture
http://msdn.microsoft.com/isv
http://www.skyscrapr.net
 © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other
countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing
market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this
presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.