News

Build a Multitenant SaaS Application -- the Microsoft Way

• By Lee Thé
• April 23, 2007

"We've heard again from many vendors out there how easy and simple SaaS is," Carraro said. "I partially believe in that, but unfortunately magic doesn't exist."

He went on to say that even with typical software-as-a-service applications in the HR, CRM and ERP areas, "the complexity, the risks don't go away -- they are shifted to the provider of the application architecture and delivery architecture. Tremendous effort is required on the delivery side."

With this sober introduction, Carraro took his SaaScon audience through the inner workings of a SaaS application.

Basic Anatomy
The SaaS ecosystem stacks a consumption architecture on an application architecture on a delivery architecture. The consumption level features SaaS buyers (consumers, enterprises). The application level comprises independent software vendors (ISVs) and aggregators (themselves sometimes atop more ISVs). And the delivery level involves SaaS hosters, with "classic" (i.e., legacy) hosters on the bottom.

Alongside all three levels you find system integrators (SIs) and value-added resellers (VARs), although the roles of SIs and VARs are often transformed, or even nonexistent, in a SaaS ecology.

And the ISV's role morphs too. For example, "you need to understand how your application may be aggregated into other types of offerings that make sense in this ecosystem," Carraro noted.

Human Resources SaaS App
Carraro ran a demo using a sample SaaS application (i.e., not a real product) that Microsoft offers called LitwareHR, which is aimed at supporting recruitment campaigns by human resources departments. (However, Carraro stressed that what the app does is less important than how it does it.) LitwareHR uses the .NET Framework 3.0 and SQL Server 2005 to implement single-instance multitenancy patterns. Carraro asked the audience how many had looked at this. Only a few raised their hands, providing yet another sign of what a new field this is.

In the demo Carraro showed how this application could be used to host recruitment Web sites for a retail shoe chain and a music school, each changing the Litware user interface with their own distinct, long-established "looks," along with different workflows, roles and access procedures, and data (including new data fields). Of course all of this is accomplished without any changes to LitwareHR itself.

LitwareHR supports a delivery platform, which in turn supports a public site for unauthenticated access (for people to search and apply for jobs), as well as a private site (for configuration and posting jobs).

The way you optimize application delivery doesn't matter much to end users, Carraro observed. However, a lower cost of delivery is interesting of course. He added that talking about your delivery methodology is like eating a T-bone steak in a restaurant and the chef comes out and brags about the Ginzu knife he used to cut it.

Next Carraro ran a demo, taking the role of someone adapting LitwareHR to an online shoe retailer, named Contoso. He demonstrated tenant provisioning of forms. The first challenge was to supplant the LitwareHR user interface (UI) with something looking like Contoso. He showed how quickly the Contoso look could be installed with minimal programming, but noted that you have to enter shared and custom schema and any additional steps needed, such as a process for a phone interview. He edited rules set in business processes to install the new workflows.

Metadata-Driven Architecture
In the rule set, you can automatically expose fields that are metadata-driven, retrieved from the context of the tenant. So if the job level equals "10" -- executive recruitment -- you can apply discovery of available workflow and alter that as needed. Carraro said that a full-fledged demo and architectural discussion are available on the LitwareHR Web site.

Next, Carraro showed how the music school Web site could exploit the metadata-driven architecture to incorporate private data associated with each tenant. The shoe store never "sees" the music store or its data. (For further information on this aspect, the LitwareHR site includes a white paper on data management in a multidata environment.) You wind up with separate databases, separate schema, but also shared schema where appropriate.

Then for the UI and workflow configuration, Carraro pointed out that you have to carefully evaluate what is safe to replace, lest something divides something else by zero. So the customization options you provide must incorporate isolation and virtualization to ensure that one tenant doesn't bring down the other tenants, yet provide enough customization to satisfy them. Likewise, workflow configuration requires runtime behavioral checking and model validation. Yet, at the same time, you have to make sure that your workflow isn't too restrictive. Carraro quoted a saying from Argentina: "You should never give a gun to a monkey."

So you need designer and runtime policy enforcement engines, along with security, fairness and halting policies. And you probably need to distinguish between standard customers, premium customers, and trusted partners, each with successively fewer restrictions when using your templatized designers. Each level of customer interacts with your system to produce runtime metadata feeding into application instances, mediated by the runtime policy enforcement engine.

Carraro compared this process to the IRS. You provide an income tax template, but also have an IRS agent check the actual filings. That is, your runtime environment needs to check, meter and control the behavior of every tenant, even if all of the behavior comes from a templatized environment. You also want to give a bigger sandbox to trusted partners, such as service integrators, who actually understand how the application works.

Finally, Carraro dipped into the need for single sign-on (SSO), ranging from individual users to an enterprise consuming multiple services. You never want to force customers to keep logging in and out. So you need multitenant security patterns, with Web sites using cookie authentication for browser clients and security token service for smart clients.

One SaaS product vendor who attended this lecture observed that it made a compelling argument for using SaaS products that can hide a lot of these complexities. But whether an ISV decides to build or buy, it's always a good idea to have some idea what's going on down there.