TechWeb

BI And The Web API

Oct 28, 2004 (11:10 AM EDT)

Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=51201246


Among enterprise applications, BI often leads the way in user interface capabilities. Think of tabular and chart output, pivot tables, and graphic reports on the desktop. Now the Web application programming interface (API), using a variety of tools from XML and JavaScript to Flash, allows BI vendors to deliver desktop-like clients in the more universally accessible Web browser. In effect, BI is on the forefront of the battle between thick and thin clients. It just so happens that BI vendors are adding a lot of user interface muscle to their thin clients so that, like Charles Atlas weightlifters, they don't have to worry about getting UI sand kicked in their faces by PC-based Fat Clients.

BI vendors have been courting the Web browser for the last ten years -- or is it the other way around? A Web browser can deliver BI Reports and output to any machine with an Internet connection. With just HTML formatting using tables, colors, and simple font control, the styling can still be quite a few steps ahead of what can be delivered on even most black and white laser printers. Yet those same HTML reports bypass printing (or allow printing on a few required pages), saving reams of output and speeding up access to data through text search in the browser. BI report output to the Web has seen many advances.

From the late 1980's to the early 1990's, when developing major reporting applications in Information Builders' Focus or in Oracle, it was easy to enhance the output-to-file capability. Thus, in the mid 1990's, the transition to Web output with the appropriate HTML headers and internal tags was trivial. Developers even added logos and background images with light watermark gray dates, "SEP 11TH 1996," for example, in bold across the page. At the same time, BI vendors like Crystal Reports and R&R Reportwriter were delivering charts and graphics to the Web. BI vendors then added sub-report blocks; first in the footers and headers, then embedded right on the page with the major report items. That was quickly followed by output to Excel files and then Adobe PDF -- and it was all automated.

Reports to Excel set a new standard because Excel allowed savvy users to hide columns and rows either by manually clicking with a mouse or with filters. Also the data could be easily cut and pasted into another spreadsheet table for further analysis or graphing/charting. On the high end, PDF output became popular because very high quality reports with embedded fonts and graphics could be shipped over the Web and then delivered by laptop or color inkjet output to decision-makers. The next real step up was customized reports, OLAP output and data mining views, again brought to your desktop in HTML format often as special pivot table applets or ActiveX-aided reports. More recently, Java report-writers like Actuate's new Business Intelligence Reporting Tools (BIRT) open source project are committed to the full set of HTML and Web-based output.




The Web Output Advantage In BI

When I talk with the BI vendors, I hear a consistent theme -- one echoed by Hyperion's VP of Product Marketing Rich Clayton. He sees "a clear advantage to our customers for Web-based output in many operational settings." Clayton went on to describe the advantages of BI output being centralized on a Web server as more secure, reliable, and decidedly lower in cost because of central control and one source for updates and distribution. Both Clayton and Srikant Gokulnatha, Hyperion's director of product strategy, describe a "pyramid" of BI usage that describes the ways people generally spend time using business intelligence applications. The pyramid breaks out roughly 65-75% as broad BI and OLAP reporting, 10-20% as analysis, and 5-10% as BI design and query, plus report creation. As you move up this pyramid, a gradual transition from Web browser-based thin clients to desktop thick clients becomes the primary mode of delivery.

Almost all the BI vendors I recently spoke with agreed there is a pyramid of BI usage. However, there was no consensus among the BI players as to the number of levels, nor the percentage breakdown at each level. There also was no clear agreement on the use of Web browser-based APIs in BI applications. For example, Paul Clenahan, Actuate's VP of Product Management, said, "We believe that the number of thin BI clients exceeds the number of thick, desktop clients today -- especially considering the number of reports that are delivered today as interactive, targeted BI content to end-users." So the base of the BI pyramid by consensus comprises primarily thin Web clients. But some vendors see thin clients being used up the pyramid. BI analysis and design programs are taking advantage of the growing richness afforded to thin clients by Java using J2ME, renewed applet approaches and JSF-Java Server Faces. Others see rich BI Web clients using Flash SWF as pushing the Web interface right to the top of the BI pyramid and BI design tasks.

All the BI vendors agreed that the Web interface demanded cross-platform and cross-browser support. None see their tools being dependent on Microsoft IE or the upcoming Longhorn version of the IE browser. However, there may be some optimism in these pronouncements. For example, some end users told me that Cognos ReportNet designer tools clearly work best in IE. And other end users noted they had to do extra testing to assure that operational reports that worked in Mozilla and Opera also worked in IE. Regardless of specific problems, the Web API and interface, as in so many areas of application development, emerged as the preferred delivery vehicle in a broad and apparently growing set of BI tools and tasks. But even more interesting was the ability of the Web API to respond to the need for user customization.




Design Migrates Down the BI Pyramid

Another major trend in the BI interface is the move to portal outlets and the subsequent need to provide more customization and dynamic design features lower down in the reporting process. Actuate's Clenahan cited this trend. "Vendors' initiatives to provide more capabilities to a thin-client application will certainly shift more and more advanced features into the thin-client world," he said. Already, many vendors supply output to Excel in their OLAP and reporting tools. Now these vendors are supplying Excel-like query and report sorting/styling capabilities through Web-based thin clients.

JavaScript, Java and Flash -- all Web-oriented tools -- allow BI vendors to deliver customizations and styling that can be handled locally. And if the data has been cached in XML or some other data format, that can include broader queries and data filtering without the delays of having to re-query the server.

Some vendors are including what can be thought of as design dialogs/pop-ups in their output. These pop-ups allow fairly radical changes to the nature of the report or chart (or both). These pop-up designers almost inevitably require a complete re-query back at the server. But they do allow savvy users to get the data and reports they want more quickly -- there's no waiting for IT to create a report for them. Of course, the best option is complete designer tools embedded in the Web API, which a few vendors are starting to support.

Jacques Surveyer is a consultant and trainer; see some of his tips and tutorials at theOpenSourcery.com