The truth about Vanilla

When I started out with OBI in it's old incarnation a.k.a Siebel Analytics I had this depressing thought that I am headed no where.After all it's a tool.I was still in thrall of C and Oracle.That's the way real men code in exalted ambience of black surly console of Unix .Oracle with all it's powerful analytic functions and later with it's extensions of model clause in 10g made all Analytic tasks a cake walk.Then why do I need a dumb Siebel Analytics.It was with these not so comforting thoughts I started my journey.Later , on maturer reflections it occured to me more than raw computing power and elegance of Analytic functions what really mattered was the hard day to day realities of Business.Siebel being astute had everything wrapped up in it's nice vanilla.If I needed to build an application for a Pharma company I needn't start from scratch.Everything was already there all I needed to do was to make appropriate modifications.Also if the source OLTP happened to be a Siebel database then it was even more easy.All ETL routines were pre defined and we were able to cut development time by huge amount.Very few people appreciate this but one of the best stuff you get packaged with OBI is it's Vanilla rpd.
So next time do take a peek at the Vanilla.
I promise you'll come up with something worth a Butter Scotch even if it's a plain Vanilla.

OBI Performance

I have invited some of our resident gurus to help me with this topic ... lets hope they can post something really nice enough.

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.