In-Depth

When Web and warehouse unite

• By Julie Hahnke
• July 6, 2001

What was true in the "old" Olap days is true now... but some new Web vendors are lighting up the warehouse world.

Two technology juggernauts, Webs and warehouses, are coming together as businesses increasingly look to leverage the wealth of information in their corporate warehouses through Web-based user access. In its latest market intelligence findings, Software Productivity Group's Analyst Services division, Natick, Mass., reports the two leading technology initiatives among Fortune 1000 businesses are Internet/Intranet development and data warehousing. It is no surprise then that Web-based warehouse access, primarily Web-based decision support, is in such demand. According to SPG's report, 38% of warehouse developers use Web-enabling functionality as a primary selection criterion when purchasing decision support (DSS) tools for the warehouse.

Why is the Web such an attractive form of information access? Most warehouses are intended to serve enterprise information needs across an entire organization. If only a small group of users can access the data in the warehouse, returns on investment are much smaller and payback cycles are much longer. If access can be spread to a much broader user group, the business benefit will be significantly greater with a much higher return on the warehouse initiative. This is the single greatest advantage of Web-based warehouse access. With the only client-side requirement being a browser and a network interface, mass deployment of DSS applications is far simpler than in a client/server architecture. Through Web-based access, it is now possible to provide decision support functionality to thousands across the enterprise and truly harness the power of the information stored in the corporate warehouse.

Wag the dog

Despite the attractiveness and potential benefits of Web-based warehouse access however, selecting a tool based solely on its Web support is akin to the tail wagging the dog. While Web capabilities may be an important selection criterion for DSS products, it should not be the only one. Users can easily get caught up in vendor debates over topics such as fat client plug-ins, HTTP impersistence and ISAPI/NSAPI interoperability issues and lose sight of the bigger picture. In fact, vendors are notorious for touting the importance of Web functionality their products just happen to provide and for minimizing the need for functionality their products lack. The effect leaves customers adrift in a sea of cyber hype, worrying about the details of interoperability, persistence, interactivity and security, and not sure how to prioritize these issues with warehouse architecture and functional business requirements.

There are two steps that must be undertaken when purchasing Web based decision support products. The first is to demystify the cyber jargon that will be ever present during the buying process. What are the relevant issues to consider when evaluating Web features and functionality? By understanding these, one can filter out hype and better interpret and compare vendor claims. The second step is to balance Web requirements with the overall project requirements when making a final product selection. How one weighs Web functionality depends on a number of project factors including architecture and user requirements.

Web features

The following six questions should be answered when considering and comparing Web-based DSS offerings.

1. WHAT TYPE OF PRODUCT IS IT?

The core competency of the DSS vendor usually indicates what type of functionality to expect from their Web products. For instance, any Web-based products offered by vendors like Actuate or Crystal are probably limited to SQL querying and reporting, since this is what these vendors specialize in. Likewise, expect Web-based Olap capabilities from Olap vendors such as Information Advantage Inc., Minnetonka, Minn., or Arbor Software Inc., Santa Clara, Calif. While this seems obvious, it quickly reduces the number of products to consider based on user access requirements. Most of the vendors offering Web-based decision support are established companies with solid client/server offerings like functionality.

There is a smaller subset of Web-only startups, however, that should not be overlooked. Some of these companies have become acquisition targets, enabling the rapid if not seamless addition of Web-based capabilities to existing client/server products. That was the fate of Interweave, which was purchased by Cognos Inc., Burlington, Mass., in September 1997 and Netscheme -- acquired by Actuate, September 1997. But others offer viable Web-only DSS alternatives when client/server support is not required. Most of the Web-only companies are limited to query and reporting (such as Zanza and Influence). Infospace, however, has developed respectable Olap capabilities in a Web-only offering and has captured considerable mindshare for this subset of Web-only products.

2. HOW INTERACTIVE IS THE WEB INTERFACE?

Products can vary widely on this single question, yet it is all important when addressing specific user requirements. The simplest Web capabilities support the viewing of static reports. In some cases, the browser is limited to pre-generated reports stored on the application server, while in other cases the report query can be issued from the client. Business Objects Inc., Cupertino, Calif., offers static HTML report viewing while Kingston, Ontario, Canada-based Andyne Computing Ltd.'s GQL bypasses the limitations of HTML and HTTP. Andyne provides report access via Java applets on the client communicating via Corba directly to the application server.

The next level of interactivity allows dynamic analysis of the query results from the client. This is a minimum requirement for Web-based Olap. This dynamic analysis can include drill downs, pivots, charting, etc., with the specific functionality varying between products. Brio Technology Inc., Mountain View, Calif., Cognos and Infospace are good representatives of vendors offering this degree of dynamic analysis. Complex dynamic analysis takes this functionality one step further and allows the customization of dynamic functions. This enables the development of Web-based applications specific to given business functions. Oracle's Express and Arbor's Essbase are examples of products providing this degree of interactivity.

3. HOW IS PERSISTENCE HANDLED? (AND CONVERSELY, HOW MUCH PERSISTENCE IS NEEDED?)

Persistence and state have been major weaknesses of the Web. They give an application a "memory" of where it has been and what has been done. Stateless applications (which are the most typical implementation of HTML pages) lack this knowledge or memory. Each client request has no knowledge of what has come before and must therefore provide all required information and parameters anew. Clever scripting tricks and the use of magic cookies stored on the client are all attempts to overcome the HTTP protocol's inherent impersistence and lack of state. This is not much of an issue when viewing static reports, but is a critical factor when trying to perform Olap analysis where the forward direction of analysis is directly dependent on what has gone on before.

The first issue to address when considering a product's ability to handle persistence is whether it is required. Can the user's data access requirements be handled by the static viewing of stateless reports or are the analytic needs more complex, requiring persistence and state? If the latter is true, then how is state managed? If the client connects to the Web server via HTTP, try and identify what tricks the product is using to retain state. Arbor's Essbase Web Gateway passes a cookie to the client where state is stored. Cookies or magic cookies are small files saved on the client that store information previously provided by the user). Brio takes a different approach and downloads a client plug-in that works in conjunction with the browser. The plug-in is retained in memory for the length of the session and provides state and persistence during this period.

Corba-based object messaging and remote procedure calls (RPCs) are persistent alternatives to HTTP. Typically Java applets on the client that communicate directly with application servers use these "stateful" middleware alternatives. This represents the high end of persistent messaging between Web-based clients and application servers and eliminates the problems of HTTP's impersistence. Examples of products that communicate in this way include Arbor's recently acquired Wired For Olap, Andyne's GQL and Infospace's SpaceSQL and SpaceOlap.

4. HOW INTUITIVE IS THE USER INTERFACE? (THIS IS ALSO REFERRED TO AS THE "MOM" TEST.)

Is the user interface so intuitive and easy to figure out that your mother would be able to use it without special training? (Note this test assumes a non-rocket scientist mother). Ease of use is a very important consideration for Web-based applications because they are often distributed to large numbers of users over potentially vast environments. It is not always practical or even possible to provide training for everyone. Therefore the interface must be clear, intuitive and non-threatening.

This can be more easily achieved by less sophisticated products with fewer moving parts (for instance Andyne's QGL has always received high marks from users for the simplicity of its interface, but it is not as fully functioned as most other DSS products). It can, however, be a challenge to package more sophisticated Olap functionality in a "simple" interface. Clearly users' technical and quantitative abilities will affect to what degree the "Mom" test applies. But in general, the greater the number of users and the broader their distribution, the more intuitive the user interface should be.

It is important to note that in every case, Web-based DSS products contain only a subset of the functionality offered by corresponding client/server products. Smaller numbers of power users may be better served with a more fully functioned client/server application.

5. HOW PLATFORM INDEPENDENT IS THE CLIENT APPLICATION?

Client interoperability actually drops as vendors employ state of the art Web technologies. This is not surprising considering the most open and interoperable systems provide "least common denominator" functionality.

In Web terms CGI scripts are the lowest tech (and poorest performing) way for browser clients to communicate with Web servers. CGI, however, is supported by practically every browser on platforms ranging from Windows 3.1 to Unix to Macintoshes. The ISAPI and NSAPI interfaces (also based on the HTTP protocol) offered by Microsoft and Netscape respectively, allow better performance when messaging between browser and Web server, but require either a Microsoft or Netscape browser. This eliminates Web server access to Windows 3.1 clients and client access to proprietary servers that do not support ISAPI and NSAPI, such as Apache and Domino Web servers. At the high end, Java clients provide the most flexible client functionality, but they also can restrict client usage. Java applets require a 32-bit operating system (bye-bye Win 3.1) and a Java Runtime Kernel resident in the client browser (again requiring current Microsoft or Netscape browsers).

Plug-in-based clients must also be evaluated for client interoperability. Plug-ins require additional memory and possibly other desktop resources in order to run. While they can provide enhanced Web functionality (as in the case of Brio) users will need to have adequate desktop resources to run them.

The take-home lesson here is that to build clients that can run on the broadest number of user desktops, those clients should make the least demands on operating system level, browser and desktop resources. More fully functioned clients that require either more client resources or specific browsers are fine if one can ensure their users are adequately equipped.

6. IS SEPARATE SOFTWARE REQUIRED?

The final question to consider is whether or not a vendor's Web functionality requires separate software or is the functionality bundled in their client/server product? Depending on the project and the environment, this can have an impact on software purchases, installation and software maintenance. Redwood Shores, Calif.-based Oracle Corp.'s Express is an example of an Olap product that provides both client/server and Web functionality within the same product. Cognos, on the other hand, offers separate products including Powerplay Web Edition for Olap functionality and its recently acquired Interweave for query and reporting.

A related question to ask is whether a product creates a separate report file for Web access versus client/server access. This can quickly proliferate the number of files that must be managed for a given number of reports. This can also potentially create report versioning and synchronization problems between Web-based users and client/server users. Andyne's GQL is an example of a product that can provide both Web and client/server access from a single report file.

Balancing Web requirements

Understanding these Web features, how does one balance the need for Web-based access with other project requirements? While no given rule can be applied to every project, the answers to three questions can help clarify the various project priorities.

1. WHO ARE THE USERS AND WHAT DO THEY NEED?

Do not even attempt to select a Web DSS tool if you do not have a clear understanding of your users and their requirements. Who needs data access now, who is likely to need future access, and who may possibly need future access? What are their specific application requirements? It is very important to determine early on if the Web is capable of handling the types of required analysis. If user requirements are more complex, the Web may not be a viable option. Do the requirements break down into primarily query and reporting functions, Olap or a combination of both?

2. WHAT IS THE USER'S DESKTOP ENVIRONMENT?

What operating systems and browsers do the users currently have? How much memory is typically available? How much variety is there within the group of users defined for this project? (For instance, do some users have Windows 3.1 desktops while others use Solaris workstations?) How much control does the project have over the user's desktop and its configuration? These questions establish potential interoperability constraints. If the user group is broad and their desktop configurations vary, a DSS product with the fewest desktop/browser requirements may be more appropriate than a fancy, Java-based client.

3. WHAT CURRENTLY EXISTS IN THE ENVIRONMENT?

Is the warehouse data stored in a relational database engine or a multidimensional engine? What data access or DSS products already exist in the environment? Do users already have client/server-based access to warehouse data? The answers to these questions will determine to what degree existing products can be leveraged and what data storage interface requirements new products must satisfy. For example, if one is using Arbor's Essbase product for data storage, it would be worth considering their Web product's capabilities. Or if users already access warehouse data with Brio's client/server product, then there may be advantage to sticking with their Web product for user interface consistency.

These three questions will identify the most critical issues when weighing Web functionality with user requirements and current architecture. They will also better refine the understanding of requirements enough to evaluate the additional needs for application persistence, functional interactivity and ease of use.

Web-based capabilities should not be considered in a vacuum, but as an integrated component of an enterprise decision support architecture. In this way the Web can be used to extend enterprise data access and provide maximum business return on the corporate warehouse investment.