Single instance, multi-tenancy is still a black art

Looks like Microsoft might be serious about SaaS. From Fred Chong's blog: "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 ..."