I just got back from a short tour in Northern California meeting with a score of Oracle reps who sell in California. I am on the road to OBIEE and OBIEE+ integration with Essbase and discovering some of the painpoints with regard to understanding this integration and selling the tools into established customers, new customers and customers with competing technologies. It was very enlightening.
One of the specific pain points that I picked up on, is determining when to transition Planning users into full-use Essbase and/or getting OBIEE users to decide to use Essbase at all. I specifically recall the term 'cubing' used. I kind of like it because it sounds like a buzzword with some traction out there. I heard it in the context that major customers who have OBIEE are already 'cubing' with Essbase, meaning making Essbase the data source for their OBIEE reports rather than making OBIEE go directly against relational and other sources.
Today I want to talk about this video which draws attention to three flaws with generic OBIEE implementations.
The salient points are clear.
I can only say that the first one was a surprise, the other two are cascading surprises. If, in order to use OBIEE and get it performing you need to build a DW of any stripe, then hallelujia days for Essbase are not far away, even though Essbase is not as simple as it used to be. Building on Essbase eliminates all of the limitations of watching your queries and building aggregate tables and all that carefulness one needs with stars and snowflakes. Plus using Essbase makes maintenance of those hierarchies very simple and query times consistent, no matter how complex or unbalanced they get. (I have yet to know if OBIEE handles unbalanced parent-child hierarchies well, for example).
I have been assuming, but only loosely, that OBIEE like Discoverer, depends to some extent on materialized views that are known by Oracle Apps specialists and that these are tidy enough to support some realtime querying without the need for exporting to a DW type architecture. If that is the case for turnkey stuff, but not for what demanding customers demand, then the technical case for 'cubing' with Essbase can be quite easily be made.
The clues given by the speaker, that one has to be smart in ETL design suggests to me that the technical case is indeed strong. And from what I've heard from some reps, the economic case with Essbase can be more flexible than it ever was under Arbor or Hyperion.
What is clear to me is that if one desires to enable EPM, then the key differentiator in using Essbase in the Oracle BI stack is its capability to handle write-back and it's capacity for managing very specific security requirements. These are things you cannot do with any ease in under star and snowflake designs. That matters whether or not complex KPIs are in play.
That's what I've got so far.
Comments