Welcome aboard, a first topic - Complicated RPD

Last project, the biggest failure that I saw was on controlling the complexity of RPD. Siebel Analytics is definitely a good tool but if you start messing it up the results are not going to amuse you anyway. ETL definitely is the rescue path, and this was thought through, by our designers. Typically in a Siebel Analytics project here, you will see an amalgamation of skills, reporting and ETL, with a common thread of good Siebel knowledge. Too often though, the RPD designer gets carried away, and the bulk results in slow performance.

The basic tenet of performance in any reporting solution lies in preventing run-time joins, the kind that hogs your cache, and increases the retrieve time. So, firstly look to denormalizing the dimensions as much as you can and with a near star schema design the performance should be neat. Secondly, look at restricting joins to the ETL jobs alone and build redundancy in the schema which may increase your ETL time but will save a lot of hue and cry when the user logs in.

In the coming posts I will invite our in-house BI gurus to contribute.. Let's see where this goes.