Experts,
We are currently using Oracle Financial Analyzer (OFA) and are
trying to COMPARE the new tool - Enterprise Planning and Budgeting
(EPB) from Oracle to HYPERION. Can someone help. Some of the criteria
for comparison that we are looking at are

Integration with Oracle Financials
Language Capabilities
Functionality
Ease of migration from current OFA to Hyperion/EPB
Support
Architecture

Also is there any truth that Oracle is planning to buy Hyperion as
stated in this article
http://www.businessweek.com/technolo...6549_tc024.htm.

Early response will be helpful.
Thanks
Sanjay

Sanjay, EPB is version 1, and is quite limited in functionality.
Hyperion Planning has better functionality, but is limited in
flexibility. It also requires Hyperion Reports and/or Hyperion
Analyzer for reporting. Reports is cumbersome, Analyzer is nice.
Architecture of Hyperion is questionable - based on Essbase. I'd
recommend a more open architecture such as MS Analysis Services -
Outlooksoft is a good choice here, and offers tremendous
functionality/flexibility.

None of them offer much in way of integration with Oracle Financials,
although Hyperion and OutlookSoft offer data import tools. From an OFA
migration standpoint, I can't imagine Oracle offering anything, and I
know the others don't. I will say that the flexibility in Outlooksoft
gives you a better opportunity to migrate things like dimensions, since
you simply cut/paste them into Excel.

There have been rumors about a buyout of Hyperion for many many years,
so we'll have to wait and see what Larry has up his sleeve. Maybe if
the stock dips...


sanjay.raj (AT) ge (DOT) com wrote:

Sanjay,
Unfortunately I dont know anything about OFA, but if you are interested
in migrating please contact me and we can talk about options.

Please check out our site for our migration tool
www.exologic.com/products.htm

Thanks
Justin
t a y l o r @ e x o l o g i c . c o m

sanjay.raj (AT) ge (DOT) com wrote:

All,
Thanks all for the input. Appreciate it. However, I would like if
someone could compare EPB and Hyperion.

Thx
Sanjay
justinptaylor (AT) gmail (DOT) com wrote:

Hi

Just thought I should correct a couple of points that you made, for the
benefit of any others confused by your reply to Sanjay:

Firstly, Oracle Enterprise Planning and Budgeting (EPB), of course, does
indeed have a great deal of integration with the Oracle Financials - in
version 1 and in version 2 - though it is not dependent on Oracle
Financials (i.e. EPB can be installed separately from Oracle Financials
and accept feeds from other financial systems.)

Second, Oracle does indeed provide OFA customers with a lot of help when
migrating to EPB. For example: OFA licenses can be traded in for EPB
licenses, and Oracle also offers free migration tools to take the data,
users, and reports and move them to EPB, thus reducing the
implementation costs still further. I can't imagine why you could
imagine that Oracle wouldn't do this ;-)

EPB is built on the Oracle Database and leverages the multidimensional
embedded OLAP Option and related technology, so it inherits the
architectural and security benefits of running entirely on Oracle. We
believe this offers key advantages compared to alternative
architectures, including: less administration, more security, less
latency, less duplication.

Regards, Kevin (@ Oracle)

OLAP Guy wrote:

A couple corrections:

" Like OFA (or EP) Essbase calculates aggregates and therefore isn't as
good
as on-the-fly data bases for flexible ad-hoc-budgeting. If you want to
do
something like this you might be better off looking at other vendor's
applications. "

Essbase calculates aggregates faster than any database, and you have
complete control over how many aggregates are made, whether they are
done beforehand, at query time, in reports, on the client, on the
server or cached in memory. So on the technical side of this you have
complete control and multiple options.

"Hyperion's current reporting solution (Hyp. Reports and
Hyperion Analyzer) provided with HP is in fact not capable of meeting
any
requirement. Hyperion bought ->BRIO and its tools two years ago and
hasn't
integrated them from a functional point of view as well as in the
backend. "

In fact, all of these are fully integrated (see Avalanche) and also the
world-standard Excel Add-In comes free with Planning. As well, Tableau
Software's OEM is part of the package options, AND, the new replacement
for the Excel Add-In called SmartView will give full reporting and
drilldown in not only Excel but all of Microsoft Office. There is no
reporting solution that is more comprehensive and capable.

If Outlooksoft is a serious competitor to Hyperion, it's only on price,
not on features. It simply doesn't scale like the Hyperion solution,
which is understandable because it's a downmarket product, whereas
Hyperion owns the F100 in Budgeting, Consolidations and Financial DW.

--
As to whether Oracle would buy Hyperion.. that's a perennial rumor that
refuses to die precisely because Hyperion has, over the years,
continued to beat Oracle at the OLAP game. The only reason Oracle would
buy Hyperion is because Hyperion has superior technology and a very
comprehensive understanding of the market. Everybody keeps waiting for
Hyperion stock to fall...

mb (AT) cubegeek (DOT) com

Applix has never submitted to the APB-1 Benchmark as far as I know. So
while I know that there are plenty who swear by it (and why wouldn't a
memory resident database be the fastest?) they just didn't want to play
in the same space as the big boys. You can most accurately say that
Essbase is the fastest out there only because everyone else tired of
the benchmark game - saying that other things than raw performance were
more important. You can also say that when it comes to the difference
between a .001 sec query response and .01 is not important, but you
can't say that one isn't faster. In the end, I think it's clear that
given the amount functions (and java extensions) deployed with the
Essbase calculation engine, it's because the core tech is super fast.
They wouldn't burden it if they didn't have something at bottom that
was that fast. Yeah I know, nobody really cares about being the
fastest...

---

I can't tell you how to build both. Hyperion would shoot me. Just wait
60 days and wait for the hype.

I've actually seen SmartView and I can say publicly that it's really,
honestly an order of magnitude smoother. I've seen it put OLAP data
into Microsoft Word through whatever Office 2003 now calls what used to
be called 'OLE Automation'. So basically, riding on top of whatever the
common data interface is for Office 2003, you can talk directly to
Essbase. That includes Powerpoint.

I've never bothered with SQR. I've never gotten bogged down into the
review meetings over fonts, column widths, row heights and colors so
deeply that I'd need to code 4GL. I tend towards the Analytical rather
than production reporting. I believe that SQR is overkill and the
visual programming provided by tools like Analyzer and Powerplay is
basically the way to go. However I know there are guys who crank out
reports and can sit through those requirements meetings. That's how BO
makes money. My bias is that customers who need all that tend to like
tools like Crystal and that's exactly why Crystal doesn't scale. On the
other hand, I wouldn't consider a vender world class who didn't have
that kind of tool somewhere in the package. All I can say is that
(Avalanche) is the response to the ultimate all things to all people
front-end. The industry ended up here because nobody by Microsoft and
Hyperion would publish open APIs and promote open OLAP in the first
place.

---

I understand that it's difficult to say what's best because customers
often don't know what to ask. My experience tells me this: Every
company eventually will want the stuff that the current state of the
art vendors are working on. That's basically Microsoft and Hyperion.
I'll give Cognos some props because they do relational front-ends as
good as anyone, but they really aren't a platform vendor. As customers
evolve, they'll get to the point where they want the platform. It costs
a bit to get started, but in the end they always want the whole thing.

Young smart companies get it. You basically have to have the right kind
of person with enough juice. Anybody with an MBA who isn't afraid to
program VB or SQL I'd say. Somebody who gets paid close to six figures.
If you don't have that kind of person looking closely at the systems
from end to end, you're not going to pull out the kind of requirements
that demand what the top tier vendors are selling. You'll spend a
little license money, a lot of development money, you'll get a system
that's good enough. Three years later...

Hi Michael.

You made some statements in your interesting post which deserve not to
go unchallenged, and suprisingly chose to exclude Oracle in your
comparisons. I think if you do, things may not seem quite so rosy for
Essbase... So, for anyone watching who is interested in this 'mine is
faster than yours' discussion :

- Actually Applix did once submit APB-1 numbers - a long time ago,
on APB-1 v1. At that time they beat Essbase's numbers but not Oracle's
(due to Oracles superior query phase numbers). Because of its memory
based architecture TM1 beat both Oracle OLAP (Express) and Essbase in
the build phase of the benchmark metric, but only Oracle was fast enough
and scalable enough at the query phase to keep the overall APB-1 record
at that time. But this is ancient history now, not frankly very
interesting as all 3 products have been improved alot since then.

- Your claim of 'Essbase is fastest' appears now to be based on
claimed APB-1 numbers. This subtle shift in your position is interesting
since the AQM metric is heavily influenced by query performance, not
about aggregation time as per your original reply to Joerg when you
claimed "Essbase calculates aggregates faster than any database" (tho I
ofcourse do know that like Oracle, Essbase can now do aggregations on
the fly at query time if you set it up that way).

- APB-1 has indeed fallen in to disrepute - NOT because any of the
other vendors are tired of benchmarks per se (Oracle Database for
example continues to regularly deliver world records in TPC-H - a
respected data warehousing / decision support benchmark), or that
(before you claim it) they believe that Essbase is the fastest and can't
be beaten. In my view, it is because firstly APB-1 is no longer a
challenge to any of the vendors (its data volumes are tiny and the data
set not particularly realistic) and secondly, because Hyperion hired the
only previously independent auditors of APB-1 submissions.

Therefore no vendor (Hyperion included) can any longer credibly
claim new APB benchmark records as there is no way for anyone to verify
that the rules were adhered to. For this reason the marketing claims
by Hyperion of superior APB-1 runs with their latest versions are just
that - marketing claims. They have not been independently verified.
Hyperion perhaps more than any other organisation knows the APB-1 rules
(it helped write them, and hired the auditors after all) and previously
attacked vendors like Applix for apparently violating some small print.
It is therefore especially suprising (revealing?) that as far as I can
tell the recent APB-1 claims have not even been supported by the
mandatory published disclosures. Perhaps there is no longer any point
since they also cannot be independently audited as APB-1 required.

- So, 'officially', if you want to quote APB-1 at people, the now
prehistoric Oracle9i OLAP run from way back in early 2003 holds the
world record for the APB-1 release 2 benchmark. Ofcourse, Oracle, like
other vendors have released new versions since 2003, so any comparison
with that is also now of only passing interest in any case.

For Oracle's part, for example, new internationally patented
multidimensional technology (not subject to any legal claims etc) built
into Oracle Database 10g is typically providing our customers with
aggregation performance (important in build/refresh processing, as you
know) of between and 4 and 40 times faster than before (I know of cases
that are far better than that even) and also drammatically reducing the
size of the resulting multidimensional cubes - again, typically by a
factor of 3 to 30 times - sometimes much better than that, depending on
the sparsity patterns in the data. All the time preserving and in most
cases also improving Oracle OLAPs already excellent query performance
and scalability. I think people who look carefully at this area may
well find that the much hyped Aggregate Storage Option to Essbase is not
so innovative and remarkable as claimed by the Marketing folks in
Sunnyvale...

Query performance ofcourse is a key strength of Oracle OLAP as well
as Essbase. Other vendors continue to trail these two for this
particular performance measure in my experience, and apparently that of
others.

In Nigels OLAP Survey 4 (The OLAP Survey 4 Summary of Results White
Paper) for example, some interesting findings confirmed that despite the
demise of APB-1 as a useful measure, Oracle's real-world leadership in
query performance and the processing of large multidimensional datasets
remains. Note that OLAP Survey 4 was carried out before the
availability of Oracle10g OLAP and the required administrative tools, so
included no customers using the new features:

Ofcourse, Query performance, load and calc times and data volumes
are all closely interrelated. The 'best' products scale in terms of
load/calc & query as data sizes increase, and concurrent user load (not
measured in the OLAP Survey) increase. So, what did OLAP Survey 4 find
in these areas ? :

Median Data Volumes.
-----------------------------------
In the survey, Microstrategy (ROLAP), Oracle Discoverer
(Relational(only) Query tool at that time - latest version ofcourse
includes native support for multidimensional data too), SAP BW and
Oracle OLAP Option were the top 4 for the largest data volumes.

Oracle OLAP is the top MOLAP product. 4 times more data than the
next MOLAP product. More than 10 times more than Microsoft AS, and 9
times more than Essbase, on average. All the other MOLAP vendors deal
with tiny data volumes on average, in practice, according to this survey
Even with the Oracle OLAP numbers increasing the average, the
Average MOLAP data size in the survey is only 2.3 Gb. The Median for
Applix TM1 for example was just 238Mb.

The scalability improvements now available in 10g OLAP are in line
with our objective of supporting even larger scale OLAP systems than
ever before. (Perhaps Hyperion have similar objectives). We believe
that, as a result, single Oracle databases will be used to consolidate
previously multiple seperate multidimensional databases by customers
wanting to improve the quality of their analysis and reduce the cost of
ownership of multiple seperate standalone multidimensional data marts..
And smaller systems will be moved to 10g OLAP for even faster build
times and reduction in latency of the information they provide.

Query Performance (Mean, by data size)
-----------------------------------------------------------------
According to OLAP Survey 4, the 2 fastest products were Essbase (at
the low end) and Oracle OLAP (at the high end).

Microsoft was reported to be good at low end, but it is very clear
that query performance reduces significantly with larger volumes of data.
In contrast, there is some evidence in the findings to suggest that
while at the low end (<1 to 10Gb) Oracle OLAP performance is a little
slower than the better low end products for this measure, as the data
volumes rise Oracle quickly moves into the lead, while all the other
products slow down, indicating superior scalability/architecture for
enterprise scale systems, even before version 10g.

Oracle OLAP users were apparently the 2nd least like to complain of
poor query performance. Kudos and hats off to Applix TM1 here by the
way, who topped this measure - tho, ofcourse, on much smaller data
volumes good query performance is easier to achieve : 238Mb was the
median size for TM1, compared to 38Gb for Oracle OLAP.

Load and Calc Times (median load and calc times)
-----------------------------------------------------------------
Oracle OLAP was ranked #4 in this measure, just behind Microsoft AS
at #3, despite 10 times the data volumes... (#1 and #2 ranked products
are are TM1 and Alea - two memory based desktop OLAP products that do no
little or no pre-aggregation, of much smaller data volumes).
Essbase and Microstrategy were the bottom 2. Ironic huh that
products from opposite ends of the OLAP 'ROLAP/MOLAP/SchmOLAP scale'
could both perform badly in this...
MicroStrategy has a good excuse (big data volumes), but Essbase ?
4 times slower to load and calc 9 times less data than Oracle OLAP ?
(on average)

Ofcourse, the much hyped 'Aggregate Storage Option' was not around
then, which, as Nigel pointed out might have improved things a bit for
Essbase, but neither was Oracle 10g. Hyperion claim big improvements as
a result of ASO, and we have plenty of evidence that Oracle10g is at
least as much faster than Oracle9i OLAP as Hyperion Marketing claim ASO
is compared to older versions of Essbase. So, if Old Oracle is faster
than Old Essbase, it seems likely that New Oracle is faster than New
Essbase too. Certainly enough of a probability to cast some more doubt
on your earlier claims of total superiority over 'any database' for
calculating aggregates.

As an aside, OLAP Survey 4 also reported that Oracle OLAP Option had
the fastest growing sales in the survey, with Microstrategy, Essbase and
Applix TM1 in "sharp decline".

So - perhaps the market is not as clear cut as you make out. I
don't dispute that Essbase is an important product in the OLAP market.
So is Microsoft Analysis Services. My purpose in this post is simply to
remind you and anyone else still reading this that Oracle Database 10g
OLAP Option is also an important product.

By combining 'best of breed' levels of performance, scalability and
multidimensional calculation capability etc with all the benefits of
being embedded inside the Oracle Database kernal, Oracle has a very
compelling OLAP product range too. But it is for customers to compare
and choose based on their business and technical requirements, not
biased people like us ;-)

Two final thoughts :

- Perhaps even IBM will make a play in the market now they have decided
to drop the 'DB2 OLAP' re-badging of Essbase. It seems unlikely that
of the 'big 3' database vendors they are the only ones not investing
heavily in OLAP.

- You mentioned that only Hyperion and Microsoft seem interested in
promoting Open OLAP? You forgot Oracle. Oracle has provided a simple
regular ANSI standard SQL access to not only relational data but also
multidimensional data and calculations in the Oracle database for
several years, and in 10g has further enhanced it. As an open standard,
most people would agree that SQL qualifies.

Kevin (@ Oracle).

mbowen (AT) gmail (DOT) com wrote:

God it's good to know that there are still some Oracle people out there
who can cite chapter and verse. I was beginning to think you guys had
dropped off the face of the planet.

Your explanation for the death of the APB-1 is perfectly acceptable to
me, and that was the source of my information, plus one other
non-disclosed perf comparison between Essbase and MSAS dated last
summer.

So apparently Oracle is facing the same difficulty as Hyperion, which
is a broad installation base of their applications with only a few
people calling for raw scratch built analytical applications. I
basically hear nothing of Oracle OLAP. While there was never much
doubt of its scalability and power, there were always questions of
whether it integrated well. I've been to admittedly few presentations
since 10i rolled out but the entire migration path for Express seemed
very confused.

If Oracle OLAP is indeed back in the saddle and well integrated with
other vendor front-ends (supporting MDX for example), then that's
competition that is welcome. It would consolidate the basic
understanding in the industry that OLAP is a platform solution - a
comprehensive tier that should interoperate in all environments. MSAS'
Windows only implementations muddy the platform message, and the huge
ugliness of BO Universes, which are neither totally front-end, nor
really ETL, nor as integrated as MSTR further confuse. By accomplishing
some clarity in this regard, it pays off to everyone in the industry
such that best of breed selections can take place.

So if a new benchmark can arise and a standard way of describing
systems that is not so dependent on Nigel and us biased old heads,
that's all good. As an architect with over 17 years in the business, I
would have loved to learn as many products as possible, but it hasn't
been possible in OLAP because of this lack of interoperations.

I am hopeful that era is coming to a close as premier vendors such as
Hyperion, and hopefully Oracle can implement things like external
authentication to LDAP etc and deeper integration to UML driven design
tools that make enitre infrastructures more clear. Again, nobody should
be stuck on an entirely proprietary platform.

As for Hyperion and performance, what I expect to see is that their
partnership with Teradata will bear fruit. That may mean, as a
standalone OLAP engine, Oracle OLAP may handle the higher volume apps a
bit earlier withing MOLAP storage. But since Hyperion already has
Hybrid (which is pure relational storage mapped under the OLAP access
methods and calculations) large cardinality dimensions are handled
nicely. At a certain point, with Hybrid, Essbase could leverage Oracle
RDBMS as well as OracleOLAP. I think of it as a slider. Where do you
want to store what part of the big model?

It's true that Essbase Aggregate Storage is lacking in the full set of
Essbase calculation functions but it is demonstrably very well capable
of those applications which were fairly well understood at the time to
be pure ROLAP apps, like retail. By implementing this multi-kernel
strategy under the same API, Hyperion has a done a very good job of
expanding the application envelope for the Essbase platform. ASO is a
killer on performance and 50 times performance over Essbase 6.5 is
probably typical and 400x is not uncommon. I still don't understand the
underlying technology. To me it still seems like magic. Obviously I'm
looking forward to some bake-offs.

As I implied earlier. The scalability issue is almost nullified. From a
Hyperion perspective, it's a short matter of time before they integrate
ASO with the fuller set of Essbase calculations (and user defined java
extensible custom algorithms) plus add support for slowly changing
dims. 18-24 months at the outside is my guess. So we will have a two
order of magnitude jump in performance. Add to that 64bit, which is
already available which bumps everything about 1.4 with no tuning, and
you're talking about imagination as the limit for apps. People are
going to have to start thinking of new classes of analytical
applications before the engines are strained. By that I mean 17
dimensional financial apps - pushing the limits of ERP systems to
maintain their codeblocks... I've signed up to the Teradata vision of
the Active DW, still on the basic hub and spoke model, but with
provisions for realtime and the whole 5 level model.

So from my perspective, it's a race to get to EAI and MQ kind of
datafeeds into source agnostic, platform-independent, interoperable
OLAP tiers. That's something I am happy to see Oracle get into if they
can sustain interest in the market. MS will be spending the next two
years getting 2000 users to ramp up to .NET and MSSQL2k5, so I don't
think there's much hope there. There is a big question as to what
improvements are rolled into MSAS2k5.

Meanwhile Hyperion still has the upper hand with integration. The
question is whether they can convince 3rd party application vendors to
jump on board.

In summary, if Oracle is alive and well and ready to compete platform
to platform with Hyperion and Microsoft that's all good, because who
knows what IBM is going to do next? Plus it gives me some assurances
that Oracle doesn't destroy any more of customer confidence by
threatening to swallow Hyperion. Don't bite with your mouth full,
Oracle.

mb (AT) cubegeek (DOT) com

Hi

Some interesting comments, as always.
To quickly respond to some of them :

MB : "I was beginning to think you guys had dropped off the face of the
planet"

Sorry to disappoint you - there are plenty of us about, and Oracle is
very much back on the OLAP Block, especially with the 10g release.

MB : "While there was never much doubt of its [Oracle OLAP's]
scalability and power,..."

Glad you agree.

MB : "...there were always questions of whether it integrated well...."

With Express you have a point - Express Server is a separate standalone
proprietary OLAP Server, just like Essbase and Microsoft AS, so is no
better integrated than them. There were ofcourse some technology
integration points with the Oracle database, but the real integration
has happened since.

Oracle OLAP - the multidimensional data types, multidimensional
calculation capabilities and OLAP APIs (including the open SQL
interface) - is embedded into the kernel of Oracle Database, and
requires no external storage or data movement from one database to
another. Not only that, but as well as integration benefits, the
multidimensional power and scalability has been significantly improved
too. As you commented earlier, already an Oracle OLAP strong point.

You can question whether Oracle can do an even better job of this in the
future (the answer, I am sure, is 'Yes there is more to come'), but you
cannot deny that integration is also an area of strength for Oracle.

Hyperion ofcourse cannot integrate Essbase with a RDBMS because it
doesn't have one, and Microsoft's approach appears to be to persist with
separate engines and separate processes for SQL Server and Analysis
Services under the covers of the UI.

MB : "...I've been to admittedly few presentations since 10i rolled out
but the entire migration path for Express seemed very confused."

No, it really isn't confusing at all. If you have clients that are
confused please direct them to their Oracle BI&W contact who can explain
it very clearly. Express customers have little to fear from a move to
10g OLAP, and alot to gain.

MB : "If Oracle OLAP is indeed back in the saddle and well integrated
with other vendor front-ends (supporting MDX for example), then that's
competition that is welcome."

Oracle is 'in the saddle' yes, and thru its OLAP API, and the SQL
interface to Oracle data (multidimensional OLAP as well as all the other
data in the database), is indeed supported by other vendors front-ends,
as well as its own tools and applications.

Curious that you, as an Essbase man, regards MDX as the answer btw.

I don't think many folks outside the Microsoft world believe that. Many
instead argue that a truly open API - SQL - is more in tune with the
interests of customers and ISVs since there are many more SQL skilled
people out there than MDX programmers, and a lot more of the worlds data
is in SQL based databases than is in Microsoft AS MOLAP cubes on Windows
machines. Would you not subscribe to the view that bringing OLAP to the
data is a more sensible strategy than continuing to take the data to the
OLAP : fragmenting the data into multitudes of separate standalone
datamarts with proprietary APIs?


MB : "Again, nobody should be stuck on an entirely proprietary platform."

I totally agree, but confess to having chuckled at the lack of irony
evident in the very next sentence in your post :

MB : "As for Hyperion and performance, what I expect to see is that
their partnership with Teradata will bear fruit"

If Hyperion's aim is to become less proprietary, Teradata is an
interesting choice of partner ;-)

If the aim is to gain performance and data warehousing credentials by
association, I can see a certain logic. However, NCR Teradata has now
lost its image as a performance and scalability leader in Data
Warehousing. Based on things like the TPC-H and Winter Corp Top 10
Surveys and Garner Group magic quadrants for Data Warehousing, it is
clear Oracle has the lead here too. The high end TPC-H competition is
now seemingly between Oracle and IBM - NCR haven't submitted any numbers
for a long time and Oracle and IBM have both since bettered their best
efforts. Gartner rates Oracle Database as the outright leader for DWs
in its Magic Quadrant for DW/RDBMS's and the last Winter Survey found
that the largest data warehouse in the world was an Oracle Database.

In the context of our 'OLAP oriented' discussion this is important as
Oracle Database now includes not only all the relational capabilities
that have propelled it to data warehousing leadership, but also world
class multidimensional capabilities.

This is key (along with the advanced Data Mining, Statistics and ETL
capabilities also embedded into Oracle Database) to why I believe Oracle
is very well placed to remain the platform of choice for Data
Warehousing and Business Intelligence.

MB: "That may mean, as a standalone OLAP engine, Oracle OLAP may handle
the higher volume apps a bit earlier withing MOLAP storage."

If I understand you correctly, we are agreeing that Oracle OLAP, today,
continues to have advantages over Essbase for larger multidimensional
OLAP systems - this is one of the points I wanted to surface right at
the start of this thread. Thanks.

However, please remember that Oracle OLAP, unlike Essbase, and Microsoft
Analysis Services etc, is NOT a standalone MOLAP Server - it is embedded
inside Oracle. There are many huge reasons why this is advantageous
for our customers - over and above the scalability and performance side
of things.

MB : "But since Hyperion already has Hybrid (which is pure relational
storage mapped under the OLAP access methods and calculations)..."

Like Oracle has had for many years ?

MB : "At a certain point, with Hybrid, Essbase could leverage Oracle
RDBMS as well as OracleOLAP."

Exactly. Essbase could, in its 'Hybrid' mode, indeed access
multidimensional data and calculations in Oracle, and even benefit from
the performance, scalability and functionality features of Oracle OLAP -
one result of a truly open SQL interface to the data! This would not be
so easy if the Oracle OLAP data was hidden behind MDX or ABAP or any of
the other proprietary APIs used by other vendors...

I am aware of Microstrategy customers and Business Objects sites that
have done this - I imagine Essbase could too - it can generate simple
SQL at an Oracle database, right ?. The ex-Brio products ofcourse can
talk SQL, so they'd also be candidates for leveraging Oracle OLAP, not
just regular relational data.

MB : "It's true that Essbase Aggregate Storage is lacking in the full
set of Essbase calculation functions..."

Which presumably limits it usefulness to existing Essbase customers,
until a future release ?

MB : "...but it is demonstrably very well capable of those applications
which were fairly well understood at the time to be pure ROLAP apps,
like retail."

Unless those retailers have interesting calculation requirements,
aggregation rules or have slowly changing dimensions, again until a
future release ?

Oracle's OLAP technology has a long history in Retail already ofcourse,
and 10g's advances provide our customers with even more performance,
scalability and functionality than before.

"From a Hyperion perspective, it's a short matter of time before they
integrate ASO with the fuller set of Essbase calculations (and user
defined java extensible custom algorithms) plus add support for slowly
changing dims. 18-24 months at the outside is my guess."

So, in 18-24 months Essbase will be on paper where Oracle 10g OLAP is
today, atleast in this regard ? I wonder what additional stuff
Oracle's development team will have completed in that kind of time frame...

MB : "Add to that 64bit, which is already available which bumps
everything about 1.4 with no tuning, and you're talking about
imagination as the limit for apps"

I find this recent splurge of marketing and press releases from BI
vendors like Hyperion lately, announcing 64-bit support, curious. It is
a big performance helper and a sensible thing to support ofcourse - but
hardly revolutionary: Oracle Database (and therefore OLAP) runs on
numerous 64-bit platforms and has done for a long time.

MB : "Meanwhile Hyperion still has the upper hand with integration. "

Compared to who ?

And last but not least, in the context of IBM's dropping of Hyperion :

MB : "...who knows what IBM is going to do next?"

This interesting recent article is worth a read when considering the
OLAP and wider database market it seems to me :
http://www.windowsitpro.com/SQLServe...470/47470.html

Thanks for the interesting discussion. Anyone else interested, or it
just us two talking to ourselves ?

Kevin (@ Oracle)


mbowen (AT) gmail (DOT) com wrote: