Online, online analytical process mixer in New York, New York
- By Jack Vaughan
- July 16, 2001
NEW YORK CITY'S Penn Station houses a Houlihan's Pub, and it is not a bad place to wait for an hour-late train on a return trip to Boston from DCI's Data Warehouse World. From behind Houlihan's picture window you can watch Penn Station's eternal human school in procession. And as the Jersey and NewYork
commuters are actually a friendly lot, you may meet, as I have, an information technologist, or "IT hand," on his way home.
We are discussing technology and because the metaphor is so close at hand my new friend says:
like a martini."
"How's that?" I ask.
"It could be I am the client and this bartender is the server, right? But if I order a martini, the bartender could mix up the drink -- gin, vermouth, olive -- or he could come to the edge of the bar put down the mixer, gin bottle and other ingredients, and walk away." Thus, I infer, leaving the client to assemble the martini.
"That," says the New York IT hand bound for New Jersey, "is client/server."
Now this analogy can play out in many ways. It is an essential truth that predates client/server computing. Everyone knows -- whether it is a mainframe-based EIS app, a client/server-based ad hoc query system, or a set of patio furniture -- some assembly (or C++) is required. But it bears repeating.
The analogy postdates client/server computing too. Again, everyone knows that if you buy a $100,000 package, you better have a $100,000-hand on hand to work with it. You may find a lot of useful CGI scripts for free on the Web, but, again, you know that you had better have good hands around to make the scripts work at all.
In scenario after scenario, the application software -- like the gin -- is "off the shelf" but you have to take care that you understand what you are buying. This tune is playing out again in Web-enabled online analytical processing, or Olap, which I prefer to call online online analytical processing, or OLOlap. At recent data warehousing shows, most every Olap vendor -- and even some of the hot dog vendors -- had a Web-enabled solution.
New and traditional vendors alike are fashioning their client/server Olap systems to work with the Web. But, your development burden will vary, your performance "hit" will vary, and your customer satisfaction levels will vary, depending on which Web-enabled solution you embrace. As with previous-generation systems, your chances for success may decline as you enable increasingly complex queries. And success can turn to failure as you roll Olap out to an ever wider audience. But, as the Web is the latest word in ubiquity, you will be challenged as never before to support more users.
Wayne Eckerson of the Boston-based Patricia Seybold Group has done a good job of identifying four distinct generations of Web-based architectures and how they relate to business intelligence. First-generation sites, says Eckerson, save reports as static HTML files, and there is no analytical interaction. Second-generation Web solutions provide dynamic HTML, whereby files are spawned from database data upon request. Users interact with back-end databases by filling out HTML forms and submitting requests through CGI, NSAPI, or ISAPI gateways. Third-generation sites, according to Eckerson, represent the level at which Java appears, but only as client-side applets. In fourth-generation Web-enabled Olap, it's all Java.
So, clearly, Web-enabled Olap is different things to different people. Eckerson's four generations, which he described earlier this year in Seybold's report on "Web-based Query Tools and Architectures" have all occurred in quick succession, and sorting out vendors' claims is as difficult as ever. Eckerson notes that I/S buyers must identify the levels of interactivity they need to achieve. They must also estimate the amount of functionality that a traditional intelligence system vendor actually brings over to the Web. Load-balancing, scalability, database driver support, and administrative access control are all areas that can cause happiness or headaches.
Eckerson also notes that, in order to support sophisticated HTML reports with pivots and the like, some tools require I/S to do scripting in HTML or CGI. For many programmers, pitting olives would be a
Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.