Death of an OLAP spec - failure of standardization efforts - The Many Faces of OLAP - Technology Information

Software Magazine, May, 1997 by Dan Richman

Then there's the problem that's unavoidable with any standard: to increase universality, one must sacrifice particularity. It's the curse of the lowest common denominator. MD-API won't let any front-end tool access any engine with the full range of features that a native API would. What endusers might gain in universality -- by using other than a dedicated client/server pair -- they may lose in features and performance. Not all users will think that's a good tradeoff. Even those vendors that embrace the API say they'll retain their native APIs, too.

Another fly in the MD-API ointment is the MOLAP-ROLAP schism, which has haunted the OLAP Council since its formation. To succeed, the spec must get buy-in from vendors of relational database management systems and ROLAP engines. ROLAP is generally believed essential for the largest OLAP environments. No production MOLAP sites exceed 100 gigabytes, while ROLAP servers are capable of supporting far larger databases, according to the Meta Group consulting firm in Stamford, Conn. RDBMS giant Oracle Corp. of Redwood City, Calif., has agreed to support the spec for its Express ROLAP/MOLAP engine.

Theoretically, the spec is neutral as to whether data is stored in MOLAP or ROLAP format. But Red Brick Systems Inc., of Los Gatos, Calif., which Meta Group says holds nearly one-quarter of the ROLAP server market, isn't so sure. "The name `multidimensional' scares us," says Steve O'Brien, Red Brick's director of product marketing. "The only way we'll sign on is if it starts to be an evaluation criterion by which front-end tools vendors decide which servers to support or if end-users start demanding it."

Red Brick isn't the only vendor wary of the spec. "It hides all the strengths the ROLAP vendors can provide," complains Manish Acharya, director of marketing for Microstrategy Inc., of Vienna, Va.

The final nail might be Microsoft. Last October, it bought hybrid MOLAP/ ROLAP technology from Panorama Software Systems of Tel Aviv. Microsoft's first OLAP offering, part of Back Office and linked to SQL Server, will ship sometime this year, says Dan Basica, a lead product manager.

"The client side will be open to COM or OLE DB or some combination," Basica says, referencing its Common Object Manager and the Object Linking and Embedding technologies. "We're not getting into the client side. We'll partner with Pilot and others but will offer a universal access strategy." Microsoft doesn't plan to join the OLAP Council, Basica adds.

It won't have to. Many anticipate that whatever interface Microsoft uses will become the de facto standard. "Based on its history, it likes to set its own standards, and because of its size and clout, these often become industry standards," says Creeth. Microsoft will "generate universal front-end support for its OLAP server product," the Meta Group predicts.

Some of the cynical members of the industry regard the OLAP Council as primarily a marketing organization designed to popularize OLAP. It has succeeded at that, but its attempts at anything more have been less successful. A benchmarking specification that it released in April, APB-I, has not been used by a single vendor or end user, Arbor's Cruikshank says: "The first penguin has yet to enter the shark-infested waters." Vendors are loath to engage in benchmarksmanship, given the enormous amount of manipulation that normally accompanies any benchmarking effort.