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.