What Makes BI SaaS Architecture Multitenant?

[Latest News Headlines]

By Boris Evelson

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 multi-tenant architecture. Here are some initiall 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.



More from the Forrester Business Process & Applications Blog...