Disconnected Thoughts

I always had that deep seated suspicion for all things disconnected and as it is I am in throes of a particularly complicated disconnected implementation.There are few things that immediately came to my notice.OBI somehow misses that punch here.Well it's true that you don't get everything from the online application in the disconnected mode.I still find that sync process is particularly difficult to debug.Lot of things are completely opaque to the developer.One would had expected a better sync log and all the internal flags that OBI checks before loading the webcat all over again.I find it completely arbitray at times and I have had harrowing time in figiuring out the exact behaviour.Again what is it that OBI does when it merges the webcat?Sad part is that I find documenation on these techincal aspects no better than sphynx of forgotten lands.
However most difficult problem has been in deciding indexes for the SqlAnywhere tables.I wonder why is it that Oracle still persists with SqlAnywhere for disconnected application when it could go for Oracle express edition.Even the most basic rules for selectivity of indexes don't work here and I am really at my wit's end in deciding what set of indexes should go in for a query.I pinned my hopes on clustered indexes here which arrange rows based on sorting of columns specified.That way your chances of fetching different page for adjacent column values decrease.However to my dismay even that is no guarantee for good perfromance.
Well OBI please pull your socks.
Your disconnected offerings needs lot of improvement.

Give me more ....!!

Today's age is that of greed exceeding need ... a recurrent ethos that gets so dramatically reflected in todays vast growing repository of packaged software and why should BI Tools be any exception .. given that Oracle has gobbled up some of the biggest names in BI and since one of them happen to be our dear ol' Siebel Analytics, I thought we can have a look at this trend and debate upon whether the consolidation is good, bad or ugly ...

Last heard SAP BW will get a big boost with acquiring of Business Objects though it remains to be seen how BO which read Hyperion Cubes in Essbase (acquired by Oracle) through 'Voyager' will fuse ... that brings us to the much hyped Oracle Fusion which never got out of the starting block ... Now isn't that getting complex ??

Gurus, what say ? What do you think will be the trend in coming years? And, if consolidation is the way to go, is it justified ...?

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.