Business Intelligence in SaaS offerings

In this post I will try to explore the challenges that one will face when they try to mix or attach Business intelligence (BI) tools in their SaaS offering. In the traditional software delivery method, you had your database installed on an owned server. You just had to give access to users and designers (through their BI desktops) to access these data. They could query and download data (given certain permissions, of course, but this is another story).

In a SaaS application, the database no longer resides in your premises. If we are talking about a private cloud, then, yes, between your desktop and the database there is the internet (“wild” internet or VPN). Your BI application should be able to access a remote database server through TCPIP (which is obviously not a problem for modern applications).

But, what if you are a user of public cloud – multi-tenant system? Let’s see some points of consideration:

True multitenant systems comprise of one database instance and one application instance. The “Chinese walls” that the SaaS vendor (must) has built, are engineered on the application layer and/or on the database layer. Typically, on the application level, one must take care that user A can search entries performed for “company A1” and user B can do the same for “company B1”. Probably, a system administrator would have access to all “companies”. On the database level, one option is the row-level security that some databases offer: A user may do a query like this: “SELECT * FROM MyTable” but the system will not reply with ALL rows of this table; just the ones that belong to the particular user.

It is possible that your BI application (or your users) may require large volumes of data in an ad-hoc basis. They probably need complex calculations, summarizing values, digging into history data etc. These processes can be quite heavy for your system. It is very common (and actually a best practice) to have your BI tools accessing a database other than the “production” database. You may call it a “reporting-dedicated environment”, a “data warehouse”, a “data mart” or whatever. But surely, you don’t have your end-of-month statistics reports running on the same database in which sales orders are processed! Typically, you achieve this by internal development: you form a project through which data structures or sets are designed, then your programmers take care that these data sets are populated and then BI reports are built on these data structures. And this is usually a custom-made environment/database schema. What do you do when you switch to a new SaaS application? How can you run complex reports and calculations in the middle of the day, while a thousand other people are doing their every-day tasks? One solution to this problem is that your vendor is also providing you with a duplicate environment (not customized, though), where you (and others) can run your BI stuff. This will surely take the load off the “production” database, but it does not solve the problem of the customizing of the data sets. Are we looking at a project-based custom development that you will ask from your SaaS vendor? Or maybe a function that will export your SaaS-based data to a local database? Take your pick!

On a more practical issue, let’s suppose that all these technicalities have been solved. You have selected your BI vendor and your SaaS-business-application vendor. There is the possibility that after having selected your SaaS vendor (because their application has all the features and functionality that you require), you find out that their database structure does not cater for all your “personalized” reporting needs. For example, you would like to categorize your SKU’s in the Items Master File in a three-level categorization tree, for statistics purposes. What do you do when you find out that the application does not have this kind of categorization? Or you would like to apply special discounts on the lowest level, but the application supports special discounts on the higher level, only… I’m trying to make this point: when you are in the software selection process, you not only need to see if the software provides all the “transactions” that you want but also design your reporting needs and have them “tested” against the out-of-the-box offering.