Tuesday, April 07, 2009

The last MDX holdout folds, but true OLAP interop is still a long way off

Oracle, the last major OLAP vendor to embrace MDX, has finally added MDX support to its server. The MDX Provider for Oracle OLAP, developed in partnership with Simba, implements the OLE DB for OLAP API and the MDX query language, and went beta this week.

The most obvious application of this technology, and I'm sure the initial revenue driver, will be to allow end-users to use Excel 2007 as their client for slicing and dicing.

Simba's architecture diagram shows the MDX provider loaded onto the same machine as the Excel client. It wouldn't seem technically difficult to run the MDX provider as a server, and have multiple clients connect via OLE DB for OLAP or via XML for Analysis. (Licensing may be a different matter.)


This announcement means that now it is possible to talk MDX to every major OLAP server. (Are there any OLAP servers that do not speak MDX? I can't think of any.) The OLAP market has moved very slowly towards standardization, but this is a significant moment, even a tipping point. In a conversation five years ago, Oracle executives agreed that MDX was a fine language, but said they would not support it, because that would be to acknowledge that Microsoft was the thought-leader in the OLAP marketplace. It's that old PR strategy: deny in public, agree in private. And in a sense their strategy worked, because without a standard language, the OLAP market could not begin to commoditize.

There is still a long way to go towards OLAP interoperability. Servers differ widely in their support of MDX. Unlike SQL, the MDX language is not in the hands of an independent standards organization; even the originators of the de facto standard, Microsoft, have not released a specification for MDX or XMLA for several years.

A query language is no good without an API to issue queries, and APIs only exist in Microsoft's own technologies: COM (OLE DB for OLAP), .NET (adomd.net) and web services (XMLA).

I have been advocating olap4j as the standard API for Java-based OLAP, but it has yet to receive public backing from vendors outside the open source community. And there are no OLAP APIs for languages such as python, perl, and php.

The final point of concern is the emergence of Simba as virtually the sole supplier of MDX, OLE DB for OLAP and XMLA technology. Simba is an excellent company, who understand MDX very well, and have invested in building a technology stack. But they also benefit from a close relationship with Microsoft. (Remember those specifications for MDX and XMLA I referred to earlier? Though they have not seen public updates for several years, I'm sure those specifications still exist behind the walls of Castle Redmond, and are available to Microsoft's partners.)

As far as I am aware, Simba have been responsible for all of the projects in the last few years to bolt MDX support on to existing servers and applications. (With a sole exception: I was never able to find out where JasperSoft sourced the technology for its ODBO Connect product.)

To summarize, this is a milestone moment in the development of OLAP technology, but there is still cause for concern. OLAP APIs exist only for a small number of languages, vendors show little inclination to provide true interoperability, and the key technology is provided by a small number of players.

You can help. If  you are a user of OLAP technology it is in your interests to see the emergence of standards in the OLAP marketplace. So, please ask your vendor what they are doing about interoperability. Ask them whether there are OLAP clients, other than their own, that run on their server. And ask them for APIs to connect to their server from all of the languages you use in your organization. Then, we may move a little closer to the goal of OLAP for all.

8 comments:

Amyn said...

Thanks for the mention Julian. Just to clarify, the only MDX query language specifications that Simba has received from Microsoft are the same ones that Microsoft has made available to everyone. Simba's success has been due to our people who have spent an inordinate amount of time understanding the MDX query language and figuring out how different products like Microsoft Excel use MDX to talk to MDX data sources. We are very excited about the MDX provider for Oracle OLAP and look forward to feedback on it now that we are in public beta.

Julian Hyde said...

Amyn,

The last publicly released specification for XMLA -- as far as I am aware -- is version 1.1, released in November 2002. Are you aware of a more recent version of the specification? Likewise, are you aware of a recent MDX specification?

To clarify further, can you confirm that Simba employees would never claim to have an 'inside track' with Microsoft when entering a business relationship?

Julian

Unknown said...

Julian,

From what I can see, it's not Oracle that have added MDX support to the Oracle (database) Server, it's Simba offering MDX to Oracle OLAP connectivity through their connector API. Oracle (from what I can tell) are backing Simba in this exercise but it's a product provided by Simba, not Oracle.

Now this is anyway good news, but it would be even bigger news if Oracle started to natively support MDX in the Oracle Database Server, which is what your initial headline suggests. However I doubt very much whether this will happen as Oracle's strategic query language for Oracle OLAP is SQL; MDX support is something they provide through Essbase, Oracle's /other/ OLAP server.

regards

Mark

Julian Hyde said...

Mark,

It's always risky to read too much into marketing announcements, but Simba seem to have had Oracle's full support.

Oracle's December 2008 OLAP newsletter announced it as a partnership: "Simba Technologies, in partnership with Oracle, has announced a native MDX driver that allows Excel 2007 to connect directly to Oracle OLAP 11g cubes. [...] Simba has announced a Beta program which will begin soon. Participants in this program will get an early look at the Oracle/MDX/Excel 2007 solution, and will have the opportunity to influence the final feature set of the solution and develop a relationship with the Oracle OLAP and Simba Technologies development teams. Please contact us [Oracle] if you are interested in participating."

In Simba's April 1st press release Oracle's Ray Roccaforte said "Simba's deep knowledge ... made them the clear choice to build this native connectivity". Sounds to me as if Oracle sought out Simba.

Oracle are cooperating fully with this effort because they know that this feature will make their offering much more attractive to their customer base.

You say "MDX support is something they provide through Essbase, Oracle's other OLAP server". If a prospect says they want to connect to their data warehouse using Excel, is an Oracle salesman going to tell them to install Essbase? I doubt it.

And if Microsoft Analysis Services is mentioned in a deal, you can bet that this product will be out of every Oracle salesman's bag faster than you can say 'jackrabbit'.

Oracle chose to launch the product via a proxy so that they plausibly continue to claim that SQL is Oracle's strategic language for OLAP. But I don't think anyone believes that anymore.

Unknown said...

While I completely agree with you that MDX standardisation would be great to have, my understanding is that the relevant people at MS don't have the time to support such an effort and aren't convinced it's worth their while commercially (which I think is debatable). The comments on this blog entry sum up the arguments pretty well: http://sqlblog.com/blogs/mosha/archive/2008/10/14/score-another-point-for-xmla-and-mdx.aspx

I can also back up what Amyn says - no partner I've met has privileged access to Microsoft's specs.

Julian Hyde said...

Mosha contradicts himself. First: "The main thing in XMLA is MDX support. Everything else ... is close to trivial."

Second: "XMLA is not dead, it is alive and well, even though there were no changes in the standard since 2003".

MDX is the essence of the XMLA standard, and it has changed radically since 2003, yet Microsoft has not issued a specification. Those of us trying to implement 'standard MDX' are essentially in the same position as AMD, trying to reverse-engineer a spec for Intel's opcodes.

Of course the low-level folks at Microsoft are too busy to invest in a standardization process. But Microsoft management do have the resources, if only they had the will. It's probably not in their interests to standardize. I doubt that Oracle was in any hurry to standardize SQL, until big customers like the Federal Government started to demand it.

Standardization will only start happening when OLAP customers start asking their vendors -- mainly Microsoft, Oracle, IBM and SAP -- to support standard MDX via standard APIs.

joeharris76 said...

I've been told by Jasper that the ODBO component was crated by Cincom (of Smalltalk fame). They did not ask for any confidentiality so now you know.

While looking into using jPivot + XML/A + Essbase (oh the horror…) I also discovered that Cincom have an open source tool called REX - waRehouse EXplorer that has been integrated into Jasper's iReport tool.

They had a press release about this in early May so maybe you already know all this… you spend all your time reading press releases right?

Joe
@joeharris76

Julian Hyde said...

Thanks for the info, Joe. I didn't know either of those things.

I'm still sad that JasperSoft's ODBO connector is not open-source. It would be nice to be able to power Excel OLAP with a software stack is all open-source. (Yes, Pentaho's ODBO connector is closed source too, but the technology was licensed from Simba so open-sourcing it was not an option for Pentaho.)