More on the Merger

I've had a chance to ponder as well as listen to other folks talk. Here are some of the best ideas of mine and theirs.

1. In the short term, nothing will happen.
We always forget this, and then reality sinks in. Nothing significant is going to happen in the next 4 to 6 months in the product lines. People will be getting over the shock in the marketplace and in the organizations. Associated companies will be getting their bearings and the very few people who knew about this blockbuster of a deal will surprise us again. From what I hear, this secret was kept very well. Although it has been rumored for years (and I wish I could find some of my old comments and speculations on those rumors) it blew everybody away.

2. Current Hyperion customers might upgrade, just to be on the safe side.
If you're sitting on an older version of Hyperion software, chances are you'll upgrade just to buy yourself time. This means busy work for the consulting sector. It's easy if you're already in System 9 of Hyperion, and easy if you're pure Essbase. But if you have a mix of Hyperion products moving all of them up will take a little doing. Still this is the only downside hedging I would expect current Hyperion customers to do.

3. Brio guys aren't breathing hard.
Somebody needs to really sit me down and explain what it is that Business Objects has that Brio doesn't. Whatever BO might have, or Oracle Discoverer might have the Brio folks aren't sweating it. The Brio customers were loyal in their transition to Hyperion and they weren't disappointed. Oracle rebranding doesn't seem to concern them much at all. That's interesting.

4. Product Integration takes time.
Peoplesoft people are still calling Peoplesoft Peoplesoft. So for the time being, it's entirely reasonable to expect that Hyperion will be a 'wholly owned subsidiary' as far as customers are concerned. It's going to take a while for Oracle to learn what Hyperion customers like about Hyperion and what they don't like. So in order to do product integration smartly, they'll most likely run out the current planned release schedule on the Hyperion suite and then start looking to merge. Again, I'm thinking Data Integration Manager (Informatica OEM) and Analytic Integration Server will be the first likely casualties to all of Oracle's data pump tech. Then again, current customers must be served. Perhaps by Solutions 2007 in Orlando in a couple months, we'll hear a few more specifics.

5. IT objections mitigated.
Already, dithering customers have committed to Hyperion based on the fact of the merger. Oracle shops are now open to Hyperion BI. This is bad news for Business Objects seeds in particular. This is one issue that has been the bane of my existence, being one of those rare individuals who thinks both relationally and multidimensionally I have suffered endless tirades about what MOLAP can't do, by people who have no hands-on. When I explain to people that Essbase is a modular database technology that has Hybrid, MOLAP and Aggregate Storage, that it is partitionable both logically and physically, they still find it hard to believe because nobody thinks of Hyperion as a database company. Now instead of showing them case studies with 500 concurrent databases or 50,000 concurrent queries I can just say two words to cease all hostilities. "It's Oracle".

People forget that Hyperion Essbase was Teradata's choice for marting in their Active Data Warehouse strategy. So I will reiterate my trash talk against MSTR. You guys are in for a surprise. The database guy in me is just giggling silly, and I haven't been so pleased since IBM OEM'd Essbase for DB2OLAP.

6. Verticals
Back when I was talking with people who oughta know, the idea for the killer Essbase apps was a certification program. That is to say Essbase had (and still has) the capability of being a brandable kind of analytic engine, as in Analytics powered by Essbase. I was personally involved with the deal that almost got Essbase embedded into Siebel, and I've since heard where the strengths and weaknesses of the chosen technology are. In any case, Hyperion has dreamed of moving towards verticals and now with Oracle's coverage of vertical markets, there are opportunities galore for Essbase to be exactly that. Of course it will require some thoughtful people to make it happen, but the Oracle introduction can be there. The technology is ready. Today.

Comments

[John Smith]

So what advice to do you have for a veteran Oracle Express Architect, now that it appears that Oracle will probably abandon their futile efforts to make Oracle OLAP a success...Should I transition in Essbase Or Microsoft Anlaytic Server...Would like to hear your views

[Cobb]

I'd learn MDX, then you can pick between MSAS and Essbase. I prefer Essbase because administratively you can program it like Express and integrate it into various processes. The new Yukon interface (although I haven't seen it) will equally load Essbase and MSAS. Essbase will run on Linux, Unix and in 64 bit.

On the other hand, chances are that if you have MSAS, the customer will appreciate any analytic apps you build more because they don't often staff up when they get MSSQL. So as an individual developer you'll get more credit. Obviously it's less expensive to deploy.

The Essbase learning curve is going to be greater but I don't think that would be daunting for an Express programmer. Learning Essbase is going to get you into more different kinds of places than with MSAS. Also remember that Essbase talks to Microsoft Reporting Services too.

Performance wise the databases themselves perform about equally in quite a few areas, which was really a shock to me. But the difference that gave Essbase a definite edge is its granularity of control. Also, the APIs to Essbase perform a lot faster that the interfaces between MSAS and .NET applications.

Essbase has a programmable calculation engine which means you can create new functions in Java and embed them, not just 'stored procedures' in MDX.

On the whole, I have a healthy amount of respect for MSAS. I did some work with it via ProClarity a few years back. It's a good feature set that lends itself well to rapid development of standard BI implementations. It's perfect for the mid-market. But as a developer, I want to know that I can do anything it is possible to do in the largest and most complex environments. Essbase gives me that.

[Cobb]

When I talk about granularity of control, I mean stuff that makes a difference during the production cycle.

For example, if you have a change to a dimension definition, you can apply that change to Essbase without it necessarily updating indices before the next dimension definition change. So if my dimension definition change requires three passes (from three different files, for example) I won't necessarily rebuild my index three times.

I can load data independent of its calculation and aggregation. I can determine the order of calculation. I can do partial and multi-pass calculation. I can goal-seek (but not quite as well as Express). I have really, complete control of what calculates and when at all times.

This is the kind of discrete control that makes all of the difference when applications become complex. For people who want to squeeze performance out of their databases, people with years of experience, this is what you want.

[John Smith]

Thank you for your advice....To learn Essbase would you suggest attending an instructer led class or purchasing a book...What do you believe he best way for doing this would be...Do you have any recommendations for white technical guides or books....There is plenty out there for SSAS, but virtually nothing for Essbase.

[Cobb]

Essbase bootcamp is worth it. You'll be astounded at how much hands on for a week will give you. Beg borrow or steal what you need to get into a course. If you're in the NYC area go for MTG. Tell 'em Michael Bowen sent ya.

http://www.mtgny.com/traincourses.html