Just Enough Essbase To Be Dangerous

Essbase is a rare and beautiful thing. It doesn’t take much to get it, as most financial oriented managers have learned. Anybody who loves Excel, and there are millions of us, love Essbase for what it does. Nobody should ever forget that the ESS in Essbase stands for Extended Spread Sheet. It was designed to be the multidimensional database that organizes all of your spreadsheets, and it is still brilliant at that.

But Essbase is also a fully mature multidimensional database system. Not just a spreadsheet backend, but an enterprise class backend to every numerical report any company can think of, and a whole lot more that most never think of. The problem is that few people have just the simple Essbase, they have System 9 Essbase and soon will be dealing with Oracle’s Essbase 11. I must say that I do love the sound of that, ‘Oracle Essbase 11’. It is the fulfillment of many dreams. But it’s also damned complex.

Among the biggest mistakes made by newbs in the Essbase world are:

1. Sitting Essbase under the CFO’s desk and out of the sight of IT.
2. “Boiling the ocean” and putting everything in one cube.
3. Not hiring an Essbase programmer.
4. Building with Essbase with a DW methodology.
5. Building Essbase without a methodology.

Let’s talk about mistake number one, which is almost always associated with numbers three and five. This is the ‘just enough to be dangerous’ scenario. It marks the limited utility of Essbase, by cementing in place those practices that make it almost impossible to expand the scope of Essbase applications.

Essbase is the most scalable multidimensional database system ever. It has been for seven years, ever since parallel calcs and multi-server partitioning were enabled in version 6. But the combination of newbie mistakes 1,3 and 5 conspire against its scalability. But because Essbase is a rare and beautiful thing, and always an order of magnitude more usable than the systems it replaces, scalability is not what’s on functional user’s minds. It’s all about linking up those spreadsheets. Lock and Send. Drill down, pivot. These are the verbs of interest, not ‘automate’, ‘partition’ or ‘architect’.

It was the culture of Hyperion that sold the ease of use of Essbase. Unfortunately, the ubiquity of finance people who desired ease of use was no match for the ubiquity of SQL programmers who defied ease of use. So in walked the legions of Business Objects folks who have dominated most of the front-ending of data streams issuing from relational database systems, as well as a skewing of what BI has become. Or rather, what OLAP has become. People forget that OLAP was all about working with data, not just presenting it. And because of the shortcomings of 4GLs like SQL, working with data has happened mostly in BI at a slow, semantic level. And we have drowned in a sea of semantics which has now grown up into its own beast, codenamed ‘business rules’. Here’s a rule, if no more than five people can describe them in plain English, something is likely to be overcomplex.

Try this one on for size. If a company wants weekly data because cashflow is an issue, ask whether or not they are working on a 4-4-5 calendar. This has been the best practice way to deal with fiscal data on a weekly basis since the MBA was invented, and probably before. If they are not, the reason why is very likely because they would have to reprogram a mountain of business rules across a bunch of database and reporting systems. Nightmare right? Not with Essbase. I could convert it all in a day – end to end. That’s what working with data means. 4-4-5 was not invented yesterday. There’s no good reason why dealing with it should be difficult, but it is, because SQL is a general purpose language whose generalities constrain the way business managers look at their own data. This is a sad thing. Your systems should not limit your imagination or constrain your vision, they should enable it. Unfortunately, too many of us are all too happy just to see some numbers in a familiar format. Lucky for BI, stultifying for OLAP.

But let’s get back to the newbie problem, which is not ramping up on the IT side and knowing just enough about the technology to be dangerous. There are several expensive consequences of underinvestment in your Essbase tech.

1. Over reliance on external support.
2. Under development of the language of BPM.
3. Failure to understand product capabilities.

The obvious results of consequence 1, is that you pay for expensive consultants to develop your applications. The temptation is always to skimp. Either buy a ‘wholesale’ consultant or skimp on the project plan with national consultants. There are innumerable ways for companies to short-change themselves by managing project to the penny rather than to the objective. I won't get into that exhuastive list. But the bottom line is there aren't many ways to avoid the pain of reforming your business practices, and if that's not the aim of your installation of BI and OLAP, then you're just buying software for the pretty charts.

The more insidious difficulty is with consequence number 2. Like everything else in this industry, technology is moving forward quickly. And because all of the big companies are driving product requirements from the now-consolidated product vendors, product offerings get more complex. That means understanding of what features are built into the products follows. In other words, this is not like buying cars where the more expensive car is just more of the same. It's more like buying a seven course meal in a French restaurant - you can't just eat it the same way you chow down a Big Mac.

EPM is the rallying point for all of the marketing associated with what was once merely BI, and people have little choice but to have their favorite products and technologies merged into stacks that make sense from an EPM perspective at the enterprise scale. The era of small perfections is over, now is the era of interoperability of OLAP in industry specific verticals and enterprise class systems, meaning enterprise class politics and governance. Meaning opportunities for gobbledygook to confuse and clutter all talk about your systems. If you don't understand where the industry is going, where EPM is going, you're going to have a hard time getting the attention of the best and brightest consultants.

Consequence three of underinvestment is a failure to keep up. I think we're all guilty of that to a certain extent. I don't know enough MDX to save my soul and Aggregate Storage? Heh. I know about 10% more than your Oracle salesguy knows. That's not a problem for me, because I get it quick and I have at least 5 new projects every year. But at your company, technology gets stale and you get behind. How many of you are on Essbase 6, raise your hands. That's 7 years old people. You have two conversions to go and one of them is painful.

I hope this is an incentive for you to get a bit closer to your Essbase technology. It is the king and world-beater and it is, as it always has been, a very satisfying product to know as well as use. Don't hedge your bets. It's Oracle now.

Comments

[Paul Weston]

Great thought process! It made so much sense to me that I have forwarded the URL to a few good consultants. Essbase is great and has been since the Arbor days but we need to get into the Oracle mindset of a complete approach to EPM. A little knowledge in EPM is as dangerous as a little boat in an Atlantic storm - just not good enough. As the article says governance and the big picture will be key to success. I'm loving v11