What Makes BI SaaS Architecture Multitenant?

I'd like to drill into some more details on my BI SaaS blog from September 2009. A key critical point to "what differentiates one BI SaaS vendor from another" discussion is what really constitutes multitenant architecture. Here are some initial thoughts to stimulate the discussion:

DBMS. There's got to be back end, DBMS architecture that allows for one of the following:

• Automatically generate a separate DBMS instance for each client
• Use same DBMS instance for multiple clients, but automatically generate a set of unique tables for each client
• Use same DBMS instance and tables for multiple clients, but automatically assign unique keys to to each client so that they can only update and retrieve their own rows

Application. Similar functionality has to exist in the application tier:

• Automatically connect to the appropriate, client specific DBMS instance, or
• Automatically use views that only point to client specific tables, or
• Append "where" clause to each SQL statement to only retrieve client specific rows

Provisioning. All of the above functionality has to be automatically executed at a push of a button, a swipe of a credit card, with zero involvement from vendor support staff or internal IT organization.

I believe that these features truly differentiate self service BI SaaS from hosting, virtualization, private clouds, etc, that some vendors are also trying to position as BI SaaS. All these other services and architectures are important, relevant and applicable to multiple situations and requirements, but they are not BI SaaS IMHO. I'd love to hear everyone's thoughts on what else is relevant here.

This blog is syndicated from Forrester’s Blog For Business Process & Applications professionals. For more, visit http://blogs.forrester.com/business_process.