Thoughts on Open Source, Analytics

Why OLAP4J 1.0 matters

Julian Hyde and his cohorts on the Mondrian project have been busy at work for nearly 5 years (spec 0.5 done in 2006!) working on the difficult, but worthwhile effort of standardizing client side access to OLAP in Java.

They just released version 1.0! This is a big deal; bigger players have attempted and failed at this before (ahem JOLAP). Kudos to Julian, Luc and the others involved to get such a *real* standard in place!

There’s a few reasons why this matters to everyone in Business Intelligence. Not just Java devs and Open Source BI fans.

Only existing “de facto” standards are owned by MSFT

XML/A was touted as **the** industry standard for OLAP client server communications. You can think of XML/A as the SOAP equivalent of OLAP client libraries. There are a few problems with this.First is that MSFT always treated this like they do all “open” standards; just open enough to get what they need out of it (SQUASH JOLAP) but never really open. For instance, reading the spec, notice that the companies involved specifically note that they all absolutely reserve the right to enforce their patent rights on their technology, EVEN IF it’s part of the spec. ie, it’s open, but if you actually IMPLEMENT it you might have to pay MSFT for it.

Second is that XML/A is now a fragmented standard. Similar to SQL, MDX support and other line protocol extensions (ahem, Binary Secured XML/A) means that there’s no one really making any sort of technology toolkit, collection of drivers, etc. Simba does much of this in their lab in Vancouver, but they’re the exact opposite of open. In fact, when the XML/A council vanished they pounced and picked up the site which is now a simple shill for their products. A couple of guys at a single company without any open publication on variations in MDX/implementations is counterproductive to real interoperability.

Third is that SOAP is soooooo 1999. SOAP is fundamental in XML/A and there are many interesting (Saiku) ways of serving client server. REST, direct sockets, in memory, etc.

Helps keep Mondrian from being fused to Pentaho Analyzer

Mondrian is a very successful open source project and serves as the basis (server part) of Pentaho’s Analyzer (acquired from LucidEra). Pentaho has clearly signaled their (lack of) commitment to upkeep of their open source frontends; Analyzer is proprietary software that Pentaho has committed all their OLAP UI efforts behind, leaving the community with an aging JPivot front end to Mondrian. Clearly underestimating what the community has to offer, the community has delivered a replacement project Saiku to address this.

OFF TOPIC: I’ve made several Open Source BI predictions and with the exception of Pentaho Sreadsheet Services (which technically wasn’t OSS) I’ve been right every time. Here’s one for ya: Saiku will outshine Analyzer in the next 18mos and both technologies will be worse off because Pentaho, ironically and increasingly, chose proprietary instead of community. Ahhh… I feel better having said it.

Keeping Mondrians primary exterior API as a standard helps ensure that Mondrian can not be subsumed (entirely) by Pentaho and that innovation can continue with multiple community projects doing shiny UI work on top of Mondrian.

A single, pragmatically useful API enables binding to other languages as well (ie, non Java)

Saiku, basing their open source RESTful server on top of OLAP4J has now enabled cool mashable OLAP access to not JUST Mondrian (which was already available via SOAP/.xactions) but anyone else who creates a driver (SAP, SSAS, etc). By actually having a real project that can collect up a real open driver implementation with a few implementations means that projects like Saiku (which actually has client APIs for C, Obj-C, Ruby, ActionScript, etc).

I wouldn’t be surprised if there are others layers (ADOMD?) that leverage OLAP4J as well.