Hyperion User Group Conference, Hyperion Essbase, ASO, BSO, and Atmos Energy

Jon Rambeau: Hyperion fumbled this thing when they released the product. They came out with a new technology, we really ought to think of it as a fundamentally different product. It can’t even compare with Hyperion Essbase, it really is a different prod. It has built different, has certain capabilities of BSO, the original Hyperion Essbase version will not do. So you need to expand your mind set that instead of ASO a limited deployment database, it quite frankly should be the majority of your Hyperion Essbase data systems. Then if it can’t handle certain things, because there are certain limitation in the product set you should consider a hybrid solution that includes some DSO and some ASO. The reason you should do these considerations is 1) performance, 2) the maintenance on these will be simplified in many ways and 3) more than anything, your envelope of opportunity to solve problems in your business goes up significantly when you understand the technology.

There’s an opportunity to do more with it. My frame of reference was there’s BSO, it’s a great product, it’s reliable, it’s been around a long time, you use it a lot, maybe you love it and maybe you don’t. It is slow in some cases and sometimes it is perfectly suited to what you need to do. There’s ASO, potentially 10 times, 100 times faster in certain things, it’s not good for everything.

To refresh some of the Atmos story, when we engaged them they were in a situation with low-performing models, the conventional wisdom was a) you can’t do this in ASO as Michael had mentioned, and b) it’s going to fail if you try. If you understand the product at its most thorough level you can do a lot of things with it.

What we had was a summation of these eight models that accumulated over 200 GB of disk space taking approximately 100 hours to process them all. As Michael mentioned, some were much longer than others, but in aggregate in total it was more than 100 hours.

This notion of trying all the Hyperion Essbase textbook things. I'm going to outline borders in a sophisticated way. I'm going to change my cache settings. You've probably heard some of these things before. I'm going to try to partition these models. I'm going to do all these textbook standard things that people have heard to try to solve these problems, optimize calc scripts, whatever it might be. It wasn't going to solve this problem. You were going to just keep beating your head against the wall and the opportunity to involve ASO in a very sophisticated design was sitting there waiting for the organization to have the right partner to come in and do this.

So we did it. The aggregate improvement was 99 percent performance. That did several things for the firm. It not only made the end-user experience significantly better, because if they had to reprocess the data, maybe some of the data feeds from their data warehouse, then have processing time, if they had to update a cube, if they had to modify anything at the last minute. Any of those things were never possible in a 40 hour account window. But when it takes two hours or less to process the entire model, or in some cases seconds or minutes, the opportunity to use that tool in a more sophisticated manner was enabled.

So anyway, the processing time has been dramatically improved but now the amount of data that Michael talked about is not constrained. Now we can double, triple, quadruple a lot of these models and still get acceptable performance.

For more information about Oracle Hyperion Essbase or other products supported by US-Analytics, please visit our website or fill out the form below.