It's been a while since I last posted about anything remotely related to OBIEE or Microstrategy. I've had almost a year of picking up the Microstrategy side of the technology and gone through some headaches to get more accustomed to its quirks, strengths, weaknesses and workarounds.

Most of this post will deal with the Microstrategy 8 platform, not the 9 release that has been out about a year now. There are some features of 9 that will apparently level the playing field but I'll go through the obvious things (to those who know one or the other or both platforms) first.

1) Multi-source: Apparently Microstrategy 8 only is able to leverage one database source to run OLAP queries from. In OBIEE (even before the Oracle acquisition when it was still Siebel Analytics), one of the main benefits it incorporated way back in 2003 was the ability to derive analytics through multi-sourcing. This meant that if you had a Data Warehouse built and you wanted to join some tables to a second (or third) source (such as an Excel spreadsheet with corresponding correct key joins), OBIEE would easily do this for you. All the work, however, occurs at the server level and this spells bottleneck if it needs to go against 2 sources of very large datasets. After all, OBIEE design necessitated the fact that you need to push as much of the analytics processing down to the database level. With Microstrategy 8, you would essentially need to go through the data migration process of getting everything into a consolidated Data Warehouse for this to happen. Microstrategy 9, introduced in 2009, has finally rectified the issue of multi-source and allows you to do this.

2) Temp Table shenanigans: Microstrategy 8 LOVES to create temporary database tables to distribute some of the processing of the data into smaller query chunks. The thought process is that if a bunch of smaller queries were pushed to the database level, they would be processed faster and datasets would be returned back to the iServer analytical engine to render the results back to the user. The problem is that the final query (or queries) is dependent on the temp tables being created in the first place. There is a sequential process that seems less effective in terms of processing fairly large queries. Of course, if you design your Data Warehouses with too many records in your fact table, you deserve to suffer long query times! (Remember to design for efficiency also!) OBIEE is a little more straightforward in terms of generating the appropriate queries (it will split up into multiple parallel queries for returning different levels of aggregated metrics if your report is displaying granular, sub-totals and grand totals). And you don't have to follow the temp table madness that can occur with Microstrategy queries, where I've seen up to 8 temp tables built to serve the purpose of a single report. Clean up of these temp tables can get ugly if there aren't taken care of. (I don't believe Microstrategy actually drops them once they have served a dashboard/report purpose.)

3) Visualizations: Since one of the strengths of Microstrategy is in the visualization of dashboards/reports, this means that depending on the deployment type of dashboard (you can have interactive dynamic HTML or Flash versions as well), the rendering of all permutations of data (meaning for all the prompted values on a dashboard, it renders all of the combinations and sends the XML data to the web client) can lead to some heavy wait times on the iServer engine side to complete before the results are displayed to the end-user. This is part of the pixel-perfect features that Microstrategy touts as a prime selling point. With this, however, I believe the flexibility adds much to the complexity of some dashboard/report designs that users and developers can go absolutely nuts developing complex dashboards with a huge amount of permutations of data that can be shown on the it. Since OBIEE is a lot more rigid in the way it renders the dashboards/reports (you only have the standard UI that OBIEE provides or you can hit the highway), and by using dashboard prompts, you are actually requerying the Data Warehouse to generate another visualization of the data that has been selected, it's actually more efficient in "breaking things up" from a rendering perspective.

I've got a few more points to make but I think I'll save that for another time before boring you folks with the details. Again, please post your comments and criticisms of my observations. I welcome them all.