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

Software Magazine, May, 1997 by Dan Richman

Some specifications are being ignored, even though the user community desperately needs them.

What if they made a standard and no one conformed? A move to develop a standard so that on-line analytical processing (OLAP) clients and servers from multiple vendors could work interchangeably is on the road to failure.

Only a few major OLAP vendors are adopting the Multi-Dimensional Application Program Interface (MD-API) specification developed by an industry group. And with software behemoth Microsoft Corp. about to enter the OLAP market -- possibly establishing its own de facto standard in the process -- the odds of the spec's widespread adoption are sinking even lower.

Although only developers would use the OLAP spec directly, its ultimate beneficiaries would be end users, who strongly favor a standardized OLAP client/server interface. "It could be enormously helpful being able to choose the best tools today while knowing we could snap another product in if something better comes along," says Dan Greenberg, vice president of global Internet services for A.C. Nielsen, the market research firm near Chicago.

The standard is important because existing OLAP tools are geared to different types of users. At least four types of workers often want to access the same data but use different types of software, explains Richard Creeth, president of Creeth, Richman & Associates Inc., an OLAP consulting firm in Norwalk, Conn., and a coauthor of the specification. These include financial analysts, who often use spreadsheets; senior execs, who need executive-proof executive information systems with graphical formats and drill-down capabilities; departmental managers, who need specialized reports; and marketing types, who want specialized browsers.

"But most OLAP tools favor one front-end tool over another," Creeth notes, adding that the same tool should be able to access data stored in different servers. "This standard could be a big win for the consumer," he says.

The OLAP Council of Boston released MD-API (now at version 1.0a) in September. The 18-member Council, founded in January 1995, is a not-for-profit association made up largely of vendors of both relational OLAP (ROLAP) and multidimensional OLAP (MOLAP) client and server products. You can download the 250-page, C-based, call-level interface spec from the OLAP Council's website (http://www.olapcouncil.org).

This summer should see the completion of coding for a Driver Manager, a layer that will sit between compliant clients and servers, says John D'Albis, chairman of the Council's API Committee. To use the spec, every vendor must rewrite its product to communicate with the Driver Manager. Once that's done, compliant clients will gain read-only access to compliant servers.

Seven of the 18 members of the Council say they will implement the standard, but only one--Planning Sciences Inc., of Wakefield, Mass.--has already done so. Another five say they haven't decided, and the remaining four say they won't; two members' responses were not available or applicable. For more details, see www.sentrytech.com/dwindex.htm on the web.

MD-API could also be adopted by the several dozen other companies in the OLAP market. But of 10 such vendors contacted for this article, only one says it will support the spec, one hasn't decided, four say they won't, and the rest hadn't heard about the spec.

Some of the companies that say they'll implement the standard, like Business Objects, of San Jose, Calif., hedge as to when, saying they'll do it when others do. That's one of the biggest problems with this and all new standards, notes Herb Edelstein, president of Two Crows Consulting Corp., a Potomac, Md., data warehouse and data-mining consulting firm. "It's a chicken-and-egg thing and, too often, nothing ever gets hatched."

The API faces a number of other challenges besides vendors' wait-and-see attitudes. One is that it's late. Many vendors that want to do so have already opened their engines to other vendors' clients or enabled their clients to access other vendors' engines, using their own APIs. For example, Arbor Software Corp., of Sunnyvale, Calif., which produces the popular Essbase multidimensional DBMS, already allows access by about a dozen front-end tools written to Essbase's native API, says Kirk Cruikshank, vice president of marketing. "More companies are writing to our API all the time. Why should we rewrite our server and complicate our lives?"

Seagate Software in Vancouver, British Columbia, shares that attitude. According to a company spokesperson, the company would have written its Holos client and server software to the API had it been available in March -- when it was promised -- instead of September. It would have been simpler to write to the API, but Seagate had to write several native interfaces because of the delay with the spec.

Another drawback to MD-API is that it only offers read-only capability. That means users can't add to or change data, only examine it. Though OLAP does involve primarily reading data, losing write capability is a step backwards compared to what many native interfaces offer. "That's a big issue we know we have to resolve quickly, because it's a useful feature, but the technical difficulties of implementing that would have delayed release considerably," D'Albis says.