Cubegeek

Google BI Becoming Real

As you can see in the above video, the Gapminder visualization tool is now available to run off Google Spreadsheets. I've commented here as my first gut reaction to the news that Google is pursuing SaaS BI. Awesome. Just Awesome.

Essbase Production Cycle - Part One: Build

Firefox Three: Blazing

Is it faster? Yes.
Is it better looking? Yes.

Is it a memory leaking hog? Dunno.
Does it have cool new features? Dunno.
Does it have new bugs? Dunno.

Is it worth it? For now.

It's so much faster that it makes webapps look to be performing faster. That's strange. I've been waiting for my browser all this time and not servers? The AJAX is definitely moving faster, I think.

OBIEE: I Get It

Having reviewed a bit of the Oracle Open World presentations and videos, I now understand and get two things which have advanced my understanding of what may be going on here. The odd edge of the sword of  being an autodidact is that you only get it when you can see the logic which parallels your own.

1. OBIEE is prepackaged analytics. This is an idea I had a long time ago and it has haunted me for years. I don't know how many times I said that we should be doing this over at HYSL and elsewhere. But basically come up with 500 schemas in every nook and cranny of every industry and sell the bundle. That's what they do. Essentially, this can, and probably will be the BI equivalent of what began two decades ago.

I can recall when SAP first hit the states and the Germans said, you will put your business into these buckets as we have defined them. And much to my surprise businesses acquiesced rather than building their own specifications. So it may very well be with OBIEE+.  Oracle will say you will manage your business performance via these KPIs as we have defined them, and companies will, rather than go through the pain of coming up with their own definitions and building them with OLAP tools.

If you can count on companies being lazy and IT as having no internal development staff, rather a cadre of application configurators, then OBIEE has every possibility of dominating the scene for the next generation. It looks brain-dead simple to implement, given that Oracle already knows the schemas for their own transaction systems ahead of time. Why not sell pre-packaged analytics?

2. The good news is that OBIEE takes Essbase as a source. This means that integration was already strategically considered. The thing to sell is ubiquity, not so much technology. So the OBIEE vs Essbase is rather I think a moot point. Rather the point is that OBIEE Plus, should integrate System 9 front-ends as well as the (rather primitive looking) current front-ends. Selling the package can remain a priority and Oracle gets to keep up sales momentum and customer acceptance.

The question is how much diversity of front-ends is and will be necessary in the next generation. Me? I'm rather sick to death of n-tier and web services. Did it really ever give IT the upper hand for systems integration? Now that any and everybody can afford dual core 2MHz clients with 2GB of addressable RAM why the hell we are piling on the web tier? All I can say is this - look how fabulously iTunes works. Think about it for a while. iTunes is really a middle tier right on your desktop. Look how much data it manages, securely. Look how little IT it needs. (none).

Essbase Configuration Guide - 10 Years Ago

I found one of the first capacity planning guides ever made for Essbase. How do I know? I made it. I did this way back in the day when one of the first internal websites at Hyperion had the name 'eProphet'. Wow. Those were the days.

Download essHW.pdf

The following system configurations are appropriate for small, medium and large Essbase installations.

The Junior System / Developer’s Workbench
This system is appropriate for working on small cubes which you don’t expect to share with more than one or two users. When production issues are not a concern and performance is not important, such as in development this configuration is appropriate.

The Bronze System
This is the system I think of as a departmental solution. It is the minimum configuration for a production roll-out in today’s corporation. It is the typical system most companies will use when they are just starting out with OLAP and only have one or two applications in mind.

The Silver System
Experienced OLAP users, most of those who have a D/W project in place or in process, and those who intend on ERP integration will be the most comfortable with a Silver configuration. Capital budget requirements are not too significant, and rapid deployment can be accomplished on such a system, with room for growth.

The Gold System
The penultimate enterprise-wide delivery platform, the Gold standard is for implementers with top quality and 24/7 high performance in mind. More complex applications, worldwide rollouts, and large multi-cube single platform applications are appropriate for the Gold.

The Platinum System
For multiple and special purpose very large single platform multicube databases in the 50GB+ range requiring maximum performance Essbase just screams on these platforms.

There's more in the download. It helped me make a lot of sales back in the day. Things sure have changed.

On the Necessity of Doing Too Much

I have determined that I am not doing enough, and so therefore have to do too much. The lightbulb went off in my head. I have to go through a million things and disappoint excitable people. This is superior to trying to get an extraordinary commitment from a few. As Ralph Malph said in his moment of epiphany this is 'volume babysitting'.

So I'm doing a whole bunch of things and not really worrying until I can't take it. I am inspired by John McCain, of all people. This man who cannot raise his hands above his head, is as old as my father and has said that he can work 18 hours a day 7 days a week for four years. I have no excuses.

So I'm going to work on The Raven Group. I'm going to work with Citibank. I'm going to work with Applied OLAP. I'm going to study DISC. I'm going to work with Mr. Reed. I'm going to work with Mr. Gillespie. I'm going to get The Brother's Cup rolling. I'm going to write Managing Essbase Projects. I'm going to keep playing the bass guitar. I'm going to keep designing the Tabletop metaphor. I'm going to keep blogging at Cobb and more at Cubegeek. I'm going to learn OBIEE and Dodeca. I'm going to learn how to raise venture capital. I'm going to continue to speak at NPR and I'm going to keep correcting my kids' homework. I'm basically going to break my neck. And if I spread myself too thin, then I'll let them tell me. But the fact of the matter is that I don't think any of them have any idea of what I'm capable of which is why I'm still not running half as much of the planet as I should be.

I'm energized about what's possible and I have too many BBs to be plinking. Shotgun time.

Cranky Geeks

Once a week, and sometimes twice depending upon how sleepy I am, I take my iPod touch to bed and watch the video of John C Dvorak's Cranky Geeks. It is, without question, my favorite show on TV.

Last night I met David Spark, who is a part time comedian, but is also very well versed in the statistics around the search industry. I really like the way his discussion allows us to block and tackle what's what. He's gone video however and his video website allows for no RSS reading. Isn't there somebody somewhere who is creating a tagging format for video so that we can do the equivalent of video-browsing of vodcasts and such? I mean, Charlie Rose does exactly that at the beginning of his hourlong shows, we get a provocative highlight at the top of the hour that shows what's to come. C'mon Google, get with the program.

Anyway, I love Cranky Geeks and it's the center of my tech brain these days, even though I hate it when they have the young dorky millionaires on.

Managing Essbase Projects

I am learning what to do with frustration. Write.

It is turning out that I am beginning to become passionately intolerant of what I expect the industry to be doing at this late date and the industry has simply not done. And so I'm going to have to write the books. I might have done this long ago, but the passion simply wasn't there. Now I am convinced that without my input, certain things that are possible, simply won't be attempted, and I further realize that I will not be able to help personally, no matter how much I would like to. And so I am initializing my new writing project: Managing Essbase Projects.

It might all be for naught, but even with the assumption that the current installed base of full Essbase licenses continues to shrink at 15% per year, there are still going to be projects out there that need to be managed. And I suspect that even those transitioning out of the product will benefit from the stuff I'll put in the book.

I'd like to get on to the next big thing, which is (Yay Research Channel) DISC in my Tabletop multitouch metaphor, but I'll have plenty of time to get familiar with that. In the meantime I need to put all of this Essbase behind me. It came to me today when I realized that the first Admin Guide that I wrote for Essbase is about 10 years old, and yet in those 23 pages are things that many customers - even owners of Essbase for five years still don't know.

The book has to be written. And so it begins.

It will include Design for Analysis, which is an iterative JAD/RAD methodology - the necessary documents, the attitude, the skillsets, the pitfalls and opportunities of building custom Essbase projects. It will include meta-information surrounding master data management, hub & spoke strategies, data management, performance tuning, testing, support, rollout, strategic assessments, capacity planning and a host of other issues. Not so much about doing them, but how to manage doing them in the context of a successful project. The very process of building analytical systems is a mystery that I will clarify. So what if it's the 100th book on IT methodology? There isn't one about Essbase, yet.

More OBIEE Rumors

I now have it from a third source who understands such things why OBIEE is destined to be a force to be reckoned with. They have done some serious analytics on top of supply chain, and it sells like crazy.

According to my new friend, the fate of Essbase is still up in the air but there are some considerable things to think about. First of all, a 'rationalization' of the platform means that whatever Oracle thinks it can cobble together and sell will set the strategy rather than pure technological merit. Case in point, Oracle's own application hosting offering. Apparently these very profitable packages use Noetics instead of Oracle Warehouse Builder. IE there are standards groups within Oracle that authorize technology standards (see something called 'AIM') that don't even include possibly superior inhouse technologies.

Naturally, we geeks have our own ideas about what pieces and parts work best together, but that doesn't change Oracle's or any enterprise company's salesforce's ability to assimilate a platform of technologies and make a strong case. Remember Oracle was the company that made billions promising first as Oracle and then figuring out how after the deal was done. Nobody has patience for that any longer, so a platform that can be sold and is marketed as a solution is better than the best architected solution that has no marketing and only selling. Good enough is good enough, and that is why Essbase is in the Oracle middle tier where things are swappable.

'Operational analytics' was my answer, but the fact is on a big enough hardware with a decent enough star, you can get that. What you cannot get is the pure technical goodness of multiuser concurrent read-write multidimensional access with full security out of the box. How much of BPM needs that? Some magical percentage. How much of 'operational analytics' needs that? Some magical percentage. How much of the whole BI market needs that? Some magical percentage. Question is, who is addressing that market, and will it fall to custom apps only?

My angle would be to sell an analytic platform for its own sake. The path to making Essbasable data marts in the world of 'subject-specific data warehouses' seems obvious to me. All the parts are there, DIM/INFA, MDM of any sort, Essbase and the panoply of System 9 front-ends. At the very least, I could do that bizdev (hint, hint) and extend the usefulness of an Oracle Analytic Tier for every repository based enterprise application out there. But I suspect that the NQuire people who did that for Siebel are already hip to that game - the question is which technology makes a more cost effective play. I think Essbase has the technical edge, but OBIEE has the marketing and sales edge. Again, a well-marketed solution sells better than a well-built one with no sales support. But an OEM product requires more thought, and that's where Essbase can destroy, ahem, the competition.

Speaking of which, MSFT is announcing it plans to sell a billion dollars of Sharepoint this year. A non-trivial market if I ever heard of one.