BI Scorecard: Information DeliveryBI Scorecard: Information Delivery
The BI Scorecard series continues with an evaluation of information delivery capabilities in six products.
This is part 3 of a multipart series comparing several major BI suites. For links to parts 1 and 2, see the Resources section at the end of the article.
Query and reporting allow you to transform raw data into powerful documents that facilitate action. Unless you put those documents into the hands of decision makers, however, the chain between data and action will be broken. In this continuing series, which has already examined query and report capabilities across several BI suites (see Resources), this latest segment looks at information delivery capabilities.
Two technologies have significantly affected enterprise information delivery: the Web and email.
In the past, information delivery consisted of walking to a printer and picking up a printout, or perhaps the mailroom hand-delivered a report to your desk. In the late 1990s, many companies implemented corporate intranets and began publishing standard reports to them. These initial reports may have been spreadsheet files or static BI reports saved in HTML format.
Today, BI reports are saved in the BI tool's native file format, allowing more interaction and the ability to refresh the data. The Web and email have also extended the reach of report delivery; whereas initial BI implementations of hundreds of users were once considered large scale, today large scale is tens of thousands. Thus, scalability is a key criterion when looking at information delivery capabilities: How many users must that one report reach and how will you reach them?
Scalability and Push/Pull
There's no easy way to evaluate vendor scalability, because the products scale in different ways, with different pinch points. Reviewing published benchmarks, checking customer references, and understanding the architecture are essential steps for evaluating whether a product will scale according to your expectations.
When assessing scalability requirements in terms of information delivery, you also need to consider how users will interact with the reports. A push (versus pull) approach has the BI tool generating reports on schedule and pushing the results to end users via a portal, email, or a wireless device. At first glance, the push approach seems like an ideal way to manage scalability, as IT can determine in advance when the bulk of BI processing is done. However, as one executive told me, he got so deluged with emailed reports, he now routinely deletes them and assumes that someone will call when there's a real problem! Clearly, the measure of success is not how many reports you can push, but rather, who actually uses them for decision-making.
Further, you must consider what you push to the users: a static PDF attachment or a URL to the BI report that exposes all the real-time interactivity capabilities of the BI tool. In the PDF scenario, the scalability requirements are less critical: The PDF generation is scheduled and users don't stress the BI application server when viewing a report. However, the URL scenario will demand significantly more scalability because users will interact with the BI application server.
The push approach also may involve "bursting," or taking one big report and parsing it so that individual users get only the data they're allowed or need to see. For example, each personnel manager can see salaries only for his or her employees. This kind of personalization is important both for security reasons and managing information overload.
In most cases, bursting may take some of the load off the RDBMS because hundreds of personnel managers don't need to run hundreds of individual queries; instead, one large query runs and its results are split into multiple pieces.
Bursting can be implemented in different ways, however, and doesn't always provide this advantage. Of the two approaches Business Objects offers for bursting, for example, the one via Broadcast Agent Scheduler runs a query for each recipient. This technique allows companies to use individual database logins and the built-in security, but it can put an unnecessary load on the RDBMS. Cognos Impromptu also uses this approach.
Most of the other products I reviewed, including Business Objects Broadcast Agent Publisher and Cognos' newer ReportNet, use the approach of running one query and splitting it into individual reports, thus reducing the number of queries hitting the RDBMS.
When doing any kind of personalized push, it's important to evaluate how and where the personalizations are defined. BI tools use row-level security, which is what allows a North American product manager to see only U.S. and Canadian sales while a European product manager sees sales for only European countries. When you push a report, ideally this same security should be used. However, it's often not. Business Objects Broadcast Agent Publisher and MicroStrategy Narrowcast Server use a set of filters for personalized push that are different from those they use for row-level security.
Microsoft's Reporting Services, on the other hand, doesn't have built-in row-level security but enables personalized bursting through "data-driven subscriptions." Data-driven subscriptions can use information from a number of different data sources to define which users should receive a report and how the data in the report should be filtered.
The tried-and-true pull approach is the method that most end users prefer, yet it poses more challenges for IT shops and vendors. With pull, users log into the BI tool and selectively retrieve the reports they want.
The schedule-and-push approach is slowly being replaced with a schedule-and-pull strategy. Users who have recurring information requirements may schedule query refreshes to run during nonpeak times, or IT may schedule high-use reports to refresh overnight so that the results are precached for users. The schedule-and-pull approach reduces load on the BI application server to support concurrent query refreshes and generation of complex documents; therefore, the main scalability pinch points are the number of concurrent logins and interactivity.
Scheduling
Users may want to schedule reports for the following reasons:
The query is slow, so it should run overnight, during nonpeak hours.
The report needs updating once every defined period, such as for weekly open orders.
Users want an alert when a certain business event occurs, such as running low on inventory.
All the tools I reviewed support basic scheduling, although some have more flexibility than others.
Informatica PowerAnalyzer and MicroStrategy's products require the administrator to define a recurrence or event such as "books closed." Defining events in this way nicely allows multiple users to schedule reports under the same event; however, I would rather end users also have the option of creating their own events or recurrence. In both products, this option requires additional administrative privileges. Figure 1 shows how Microsoft Reporting Services allows both options.
Figure 1. Microsoft Reporting Services provides scheduled report distribution to multiple destinations in multiple output formats.
For scalability and performance reasons, administrators and users may schedule automatic refreshes of reports in the reports' native formats. With Informatica PowerAnalyzer, only shared reports can have a scheduled cache refresh. Therefore, personal reports that run slowly can't be scheduled in the native format.
When evaluating scheduling capabilities, you also need to look at both the output formats and destinations. As part of the scheduled refresh, users may want to automatically create PDF, Excel, or XML files for further distribution, analysis, or offline usage. Output destinations may include a file server, Web site, email, or printer.
Alerts
A business event is the occurrence of a particular metric condition: for example, when sales fall below target or inventory is low. Users can request "push" notification of specific business events via email, pager, fax, or PDA. Alternatively, users might log in to a portal that gives an overview of all the alerts.
Alert capabilities in BI products are often less robust than core scheduling features. Although Business Objects' Broadcast Agent Publisher sends users email notifications of business events, this product works only with Business Objects documents authored on the desktop and not with documents created via WebIntelligence (resulting in a yellow score in Table 1). The vendor claims that this meets the majority of their customer needs and, indeed, many companies primarily use the desktop product for report authoring. However, the limited email capability for WebIntelligence documents can be yet one more reason to dissuade users from migrating to WebIntelligence.
Table 1. Scorecard comparing information delivery capabilities of several BI suites.
In Cognos Series 7 (PowerPlay and Impromptu), Cognos NoticeCast lets users view a report and interactively request an alert notification. This intuitive functionality is not yet available in ReportNet; an administrator would have to define an alert condition.
Informatica's PowerAnalyzer has the most integrated and intuitive alert notification, letting users see alerts via a dashboard or receive push notification.
When evaluating alert technology, it's important to consider how the email addresses become associated with the subscribers. If individual users subscribe to events, then it's easy enough for one user to specify how the notification should be delivered. However, if you're using a push approach, maintaining multiple distribution lists and email addresses can be an administrative nightmare. Business Objects' Broadcast Agent Publisher provides plug-ins that will dynamically read email addresses from a Microsoft Exchange server or Lotus Domino. Although Microsoft Reporting Services doesn't provide business alerts, it does allow users to send scheduled reports to email lists. These email lists can be read from a relational database. Ideally, vendors will increasingly read email addresses from third-party directories, rather than requiring lists to be replicated in their own repositories.
BI Portal
Dedicated BI portals enable users to access standard reports or personal reports. For some companies that already are implementing an enterprisewide portal solution, integration with portal products such as Plumtree, IBM's WebSphere, or Microsoft's Sharepoint, to name a few, is important. Depending on your strategy, you may want to:
Embed specific BI functionality within the enterprise portal
Access the dedicated BI portal from within the enterprise portal
Access the dedicated BI portal through a Web URL.
The scorecard in Table 1 looks at only these last two approaches and considers what functionality is built into a dedicated BI portal. The best BI portals allow users to customize the portal into a pseudo dashboard (like My Yahoo) that displays multiple reports, Web sites, alerts, and report lists. (See Figure 2.) Standard reports are usually grouped by a topic such as "Sales Reports." Ideally, the BI portal allows any one report to be grouped in multiple ways, without making duplicate copies of the same report. Increasingly, vendors are allowing non-BI documents (spreadsheets, PDF documents, and so on) to be stored in the BI repository and displayed in the portal. Crystal recently introduced this capability in version 10; MicroStrategy is the only vendor reviewed here that doesn't yet have this capability. As BI content increases, users also need easy ways to search for individual reports either by author, keyword in the title, or some other way.
Figure 2. Business Objects' InfoView portal allows users to create a My InfoView that can act as a dashboard with content from reports, report lists, and Web URLs.
Additional Requirements
This segment of the BI Scorecard series looked at key aspects of information delivery, getting the information to the decision makers. I've focused on scheduling, alerting, and portal integration, yet it's important to remember that other functional areas affect how easily a solution can be deployed to all users. For example, reusable and optional prompts (covered in part one of this series) and intuitive interactivity (discussed in part two) clearly affect how easily one report can serve multiple users.
In addition, as soon as you start scheduling reports and alerts, both users and administrators alike need a way to monitor them:
What happens if a report run fails: Is it automatically restarted or is the user notified of an error?
How does the product architecture handle multiple, simultaneous schedules?
With multiple report refreshes, can users archive previous versions of the same report?
Next
In the next installment of this BI Scorecard series, I will look at how well the BI tools integrate with Microsoft Excel — the de facto BI tool for many companies.
Cindi Howson [[email protected]] is the president of ASK, a BI consultancy. She coteaches The Data Warehouse Institute's "Evaluating BI Toolsets" and is the author of Business Objects: The Complete Reference (McGraw-Hill Osborne Media, 2003).
Resources
Part 1: Query Capabilities - March 20, 2004
Part 2: Reporting Capabilities - April 3, 2004
Part 4: Excel Intration - May 1, 2004
Part 5: OLAP - May 15, 2004
Part 6: Administration - June 1, 2004
Part 7: The Best BI Tool - June 12, 2004
See Part I for methodology note.
About the Author
You May Also Like