There's at least one observer -- I'm enjoying the deja vu.

This takes me back to the good old days of around eight years ago when
Dan Druker (Michael's former boss, then still with Arberion) and Kevin
(then on his Rockport sabbatical from Oracle) jousted regularly. Now, of
course, Michael is (temporarily?) away from Hyperion while Kevin is
back in Oracle. I guess it's no longer possible for employees of
corporations to duel in public, so at least one of the parties needs to
be a loyal consultant still working with the his former employer's
product, rather than a current employee.
(For an example, see
http://groups.google.com/group/comp....c2a8b2fbb4869a,
which shows that Michael used to know that Applix had submitted TM1 to
the APB-1)

What, of course, would be great is if customers of these vendors joined
in to disclose the reality rather than these sanitised marketing
versions of the truth...

"Kevin Lancaster" <kevindotlancaster (AT) oracle (DOT) com> wrote

<snip>

versions of the truth...

You can say that again. Dan used to whack me for speaking plainly here
and over at the Yahoo board for HYSL because I could always get out
marketed. I just build the damnable things. I've been trying to juice
up public discussion over at Cubegeek but the first format didn't
really take off. I do get a lot of job offers though, and that's always
nice to know that folks can get work at that board, but I'm more
interested in hearing some more from developers and customers.. So I'll
be facilitating a wiki and a blog. That should help.

--
Back to some points in the fray.

I don't believe that extensions to SQL are the way to go. Wasn't the
entire point of coming up with an XMLA standard? As an Essbase guy, I
don't like MDX, principly, but I also got certified in ProClarity and I
like the idea that MDX driven front-ends should be able to be vendor
independent. Of course I like the idea that with Essbase you have a
choice between programming in MDX and the same old calculator language.
Either way I wouldn't go around saying that MDX is a proprietary
extension.

I find it difficult to believe that the DBAs who might be building
Teradata class warehouses even condescend to speak to end users who use
Oracle Discoverer or what's the name of that report writer out of
Oracle Financials. Again, I'm focused on the value add of the
Analytical Applications that are built, and it's not clear to me that
that has ever been a priority in Oracle's businesses. You certainly may
have the toolkit, but it's about retaining practitioners too.

The larger analytical applications are always a system sale - a
platform sale so exactly where you draw the line between Oracle OLAP
and the RDBMS isn't so important is it? So long as the integration is
smooth. Likewise where Essbase links into DB2 or Teradata in the
context of big apps isn't so critical.

The usefulness of ASO to current Essbase customers is pretty
substantial due to the nature of a sizeable percentage of Essbase
models. If (swag) 25% of the BI market is ROLAPable, meaning what we
call 'rack & stack', then that's a 25% that could benefit straight off
by converting. I'd be a bit more aggressive and suggest that anything
you can ROLAP you can ASO. That basically means that the Essbase
platform is swallowing up more of the applications it didn't address
before. That's very useful of for current Essbase customers. My
prediction is that customers who have Essbase and MSTR toss out MSTR as
they learn ASO, rather than the other way around.

What I'm seeing is what I've called 'Multipath' applications, where
previously unsupportable retail or sales actuals get pumped into an ASO
partition and allows reporting from the same front-ends as with
Hyperion Planning. It's a beautifule thing.

BTW we got Data Mining and Statistics in the Hyperion platform, but
really, most of the Fortune 500 are about as up on that as Able Danger.


So now that Oracle is planning to swallow Siebel, I hope the marketing
budget for OracleOLAP doesn't suffer. This banter is great fun.