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.

It is pretty difficult to locate Comcast channels after they switched over to digital format. So I went through one by one with the TV to try and document them all. These are for San Francisco, California. They may not be the same for other counties like San Mateo, Contra Costa, or others.

If you have any recent model LCD/Plasma TV (at least within the last 3-4 years) with digital tuner, you should be able to tune into the QAM channels. Some of the USB and PC peripheral tuners will also be able to tune into the QAM channels.

I'll update the listing if things change over time but hope this helps. It's a shame Comcast doesn't publish these channels to service listings that allow companies/devices like Tivo take advantage of. They are literally shooting themselves in the foot with these kinds of tactics.

Channel Station
81.11 Nickelodeon
81.2 Oxygen
81.3 Discovery
81.4 TLC
81.5 Comedy Central
81.6 VH1
81.7 Cartoon Network
81.8 Spike
81.9 E!
83.1 Vs
83.12
83.2 Bio
83.3 History International
83.4 Lifetime Movie Network
83.9 Style
86.4 Food Network
86.5 MSNBC
86.6 Disney Channel
86.7 USA
86.9 A&E
94.11 HGTV
100.1 C-SPAN
100.10 QVC
100.12 Headline News
100.2 C-SPAN2
100.3 Animal Planet
100.4 Travel Channel
100.7 CNN
100.8 Golf Channel
100.9 HSN
121.1 Latination
121.10 News Radio
121.11 Classical Radio
121.12 Latin Jazz (KCSM)
121.13 Radio
121.14 Pop Radio
121.15 Spanish Radio
121.16 Contemporary Radio
121.17 Radio
121.18 Pop Radio
121.19 Radio
121.20 Country Radio
121.21 Country Radio
121.22 RnB Radio
121.23 Radio
121.24 Radio
121.25 Classic Rock (KFOX)
121.26 Spanish Radio
121.6 Hispanic (Telemundo?)
81.10 TV Land
86.10 FX
86.11 Lifetime
86.12 AMC
87.13 SyFy
87.14
87.3 Hallmark
87.4 Tru TV
89.1 TV Guide
89.10 SFGTV2
89.11 GOD
89.12 ARTS
89.3 Weather Channel
89.4 Link TV
89.5 Comcast Home
89.6 SFGTV
89.7 ShopNBC
89.8
91.311 MTV
94.10 Bravo
94.14 TV Land Prime
94.9 History
98.11 VH1
98.13 GEMSTV
98.5 FCS
99.13 G4
99.5 Bloomberg
99.8

Link: http://www.gooddata.com

A new startup funded in part by Marc Andreeson (formely of Netscape & Mosaic fame) called Good Data extolls the virtues of collaborative Business Intelligence and placing the platform on cloud computing environment for scaleability as usage grows. It leverages SOA and Web 2.0 technology to deliver a hosted solution that is as functional, if not more so, than pre-existing BI platforms like OBIEE, Business Objects, Cognos, etc. And best of all, it's free to try!

I have yet to play around with this but I'll be taking a CSV file of raw data and trying to build reports on top of it, including the testing of Ad Hoc analytics on it. With Good Data, you can source multiple data sets, including Amazon S3 buckets. It's claim to access different data sets via their API needs to be tested out but the limitations are obvious if a database was the source of data that needs to be transferred over the Internet (securely of course) into Good Data's distributed system. I'm guessing Hadoop is their storage and processing model for distributing the share of workload for storage, retrieval and light processing of the data.

It will be interesting to see how this new upstart plans to break a market that has been previously dominated by a handful of BI players. And given the hosted model here, how long will we see this being produced as a standalone enterprise application that can be purchased by customers looking to manage their BI internally? Financial institutions would NOT want a hosted solution for this and they are a market that would be good to monetize on. What plans Good Data has is not clear but hopefully they sort this out and pick their target markets wisely.

Having had a little more exposure to the Microstrategy application stack, specifically Version 8, I find they are fairly similar platforms. The differences end up being how to create Microstrategy (MSTR) Projects, which are essentially Logical Models within the Business layer in OBIEE. Metrics & Facts take on slightly different meanings within the MSTR world as they are fairly flexible in nature. The organization of things in multiple folders within an MSTR Project is a little daunting and confusing at first but makes some sense if you just focus on everything relative to the Project itself. If you extend the concept of MSTR Projects to a single OBIEE Subject Area, then you can make the association.

The MSTR analytical engine is fairly similar in that it will try to determine the most optimal query to construct based on the definition of the MSTR Project objects. The architecture of the physical data model requires a little bit of a different approach.

One thing I started to investigate was the fact that Microstrategy likes to snowflake tables off dimensions. This is a little different than the nearly complete normalization of dimension tables within the Oracle Business Analytics Warehouse data model. I'm going under limited exposure on the reasons behind this but I believe there are cases where snowflaking, let's say, a type table off a dimension may lead to some design approaches to the fact that that make it easier later on to create aggregates that join to the snowflake table at a higher level of granularity than referencing the dimension table. The MSTR analytical engine chooses the approach table to join to the proper granular fact table through its own implementation of aggregate awareness.

OBIEE has had aggregate awareness for quite some time now (at least 5 years) within its main server engine. It also was a little more intuitive to define at which level of granularity the Logical Table Sources were defined for and referencing the appropriate hierarchy column within a dimension to determine which LTS to query against. If an appropriate column within the normalized dimension table exists to join to the aggregated fact table, this design decision allows OBIEE to implement aggregate awareness in a much more efficient manner.

I'll dig more into how the Microstrategy analytical engine handles this with the configuration in the Project.

Another difference is that the metadata resides within its own schema whereas the OBIEE metadata resides in a single file. There are pros and cons in both methods. With an older BI platform product I worked on over 10 years ago called Information Advantage DecisionSuite (RIP IA!), it was very similar to what Microstrategy's approach is in terms of centralizing the metadata storage in a database schema. Migrations with metadata stored in a file vs a database means that it is a little more cumbersome to conduct within Microstrategy. In OBIEE, it requires copying a single file into the target server. Within Microstrategy, the Object Manager needs to push the changes from one environment to another, meaning that it needs to do database reads and writes from one metadata schema to another, in another database as well (if you architect it according to best practices and separate the target server metadata in another schema or database instance altogether). This, however, ensures that proper measures and checks & balances are done via the platform to preserve the integrity of the metadata components.

I'll post some more thoughts as I come across them. Feel free to poke holes in my observations though and comment on the comparisons. More to come!

I recently took a new position at a company as a Full Time Employee (FTE as we're called now ), ditching the consultant life of going from one client to another, and trying to take what I've learned and experienced over the years with Business Intelligence and OBIEE and applying them to this company.

The platform they are using is Microstrategy, which as some of you (or most of you astute readers) will know to be one of the oldest ROLAP Business Intelligence tools in the market. It's on version 9 now so I'll have quite a bit of exposure to the Intelligence Server architecture, the platform itself, the Reporting engine and the Administration portion of it to compare with OBIEE's similar parallel offerings.

I've already noticed a few differences between the 2 platforms but am surprised at the amount of similarites. In the next several posts, I'll probably do some comparisons of the 2 platforms and invite comments about the pros and cons of each one of these comparisons.

All things being equal, OBIEE and Microstrategy aren't that far apart in terms of what they actually offer and provide businesses: the ability to visualize their data and gain value and insight into their organization in order to manage their business more effectively and efficiently. It's just in HOW they go about taking care of business that will be interesting to compare with.

Oh, and BTW, why aren't there more resources on Microstrategy (such as blogs and forums) than there are available for OBIEE?