Multi-Tenant Data Architecture

June 2006 Frederick Chong, Gianpaolo Carraro, and Roger Wolter Microsoft Corporation Applies to: Application Architecture Software as a Service (SaaS) Summary: The second article in our series about designing multi-tenant applications identifies three distinct approaches for creating data architectures. (25 printed pages) Acknowledgements Many thanks to Paul Henry for his help with technical writing. For further reference, an ARCast is available: ARCast - Software As A Service Contents IntroductionThree Approaches to Managing Multi-Tenant DataChoosing an ApproachRealizing Multi-Tenant Data ArchitectureConclusionRelated GuidanceFeedback Introduction Trust, or the lack thereof, is the number one factor blocking the adoption of software as a service (SaaS). This is the second article in our series about designing multi-tenant applications. Three Approaches to Managing Multi-Tenant Data The distinction between shared data and isolated data isn't binary. Separate Databases Figure 1. Figure 2. Figure 3.

Many degrees of multi-tenancy Software as Services ZDNet.com For SaaS purists, multi-tenancy — the architectural model that allows them to serve multiple customers from a single shared instance of the application — is an article of faith, the one thing that marks them as a tribe apart from traditional software vendors. Suggesting that they're anything other than fully multi-tenant, then, is tantamount to questioning a man's virility or impugning an American's patriotism. It's not the done thing. Perhaps, therefore, Milan Thanawala (pictured), director of platform products at Oracle, might have chosen his words a little more carefully in a panel session last week at the SIIA OnDemand Europe conference in Amsterdam [disclosure: I was a keynote speaker at the conference and participate in agenda planning for the SIIA's SaaS events. I spoke — for a fee — at an Oracle event in January, and Salesforce.com, mentioned below, is also a client]. It was a fateful example to choose. Salesforce.com: First-degree multi-tenancy.

Gianpaolo's blog SaaS Simple Maturity Model A few days ago, Fred and I hosted a BoF at the OpSource Saas Summit. It was a great discussion. Most of the 15 people who came to the BoF were startups exec. the few others were architects / director of dev. at larger companies. The discussion was not whether they should move to SaaS (they were convinced of that already); but very much how to successfully implement SaaS. As you can expect, there is no silver bullet for implementing SaaS and a lot of passionate exchanges of opinion took place. scalability (with SaaS applications can potentially reach Internet scale), multi-tenancy (this is to keep under control the cost structure, one cannot have 1000s of customer, each on a separate instance) and customization through configuration (related to previous point). To facilitate the discussion Fred and I introduced a basic SaaS maturity model. Level 0: (Ad-hoc / Custom) At its level, nothing is done for allowing multiple tenants running on the same instance. Level 1: (Configurable)