Ten Questions to Consider When You’re Selecting User Tools
Few things are more frustrating than successfully building a data warehouse and then having it rendered unusable by less-than-satisfactory user tools. This list presents some questions to consider when you’re evaluating tools that you might want to purchase.
Do I want a smorgasbord or a sit-down restaurant?
Bet you weren’t expecting a question like this to pop up, were you? This analogy often helps frame the discussion of what you’re looking at in a tool. When business intelligence was initially created, there was a broad vision that users could serve themselves.
The user would go to one environment, insulated by all the underpinnings of the data, and merely ask a question and get an answer, ask the next question, and so on. But IT has often restricted the tool so that end user can’t access it, so they can’t self-serve — like in a sit-down restaurant.
Can a user stop a runaway query or report?
Almost every tool user occasionally submits a query (or performs some other type of operation, such as running a report) that keeps going and going and going. . . .
A user tool must give users a way to stop this type of query or report gracefully, without doing any of the following:
Locking up the user’s desktop PC and forcing him or her to turn it off or reboot
Interfering with other users’ work (by requiring that you halt the database server and restart it, for example)
Otherwise causing a disruption in business as usual
How does performance differ with varying amounts of data?
You may have determined during the project scope that your data warehouse will start with 500 gigabytes of data, for example, and grow to 1 terabyte during the next two years. It pays to know, however, how each tool will perform with not only the initial 500 gigabytes and the eventual target, but also with 2 or even 3 terabytes, just in case.
In case of what? Here are just a few possibilities:
New data sources that no one could foresee during the project scope.
A decision to add an increased level of detail to the data.
A decision not to delete old data, but rather to keep it in the data warehouse.
An unforeseen merger occurs, and you must incorporate the new entities’ information into your data warehouse.
Can users access different databases?
I’m talking about different databases of information from the same tool, not necessarily different DBMS products. For example, a user may access the regular data mart stored on a local Windows NT server for most queries and reports and, by using the same tool, have access to this information:
Another department’s data mart, for occasional queries
The organization’s main data warehouse
An external data provider over the Internet
Users shouldn’t have to switch tools to perform similar functions (basic querying and reporting, or OLAP, for example) against different data sources.
Can data definitions be easily changed?
Although the process of getting the first set of data definitions up and running is fairly easy in most user tools, you need to ask yourself these questions about when you need to make modifications:
How easily can you update your entire user community’s data definitions, and how long does it take? (Do you have 100 users? 1,000? 5,000?)
How do you modify queries and reports that use data that no longer exists or data with a modified structure (its data type and size, for example)?
What happens to scripts and programs that are part of the tool?
How does the tool deploy?
Does the tool require desktop deployment, or can you deploy it within your organization’s standard browser configuration? If you’re looking at a tool that’s not available for deployment in a browser, you may want to reevaluate your criteria. Server-side deployment lowers a lot of costs that exist when you have to deploy tools on the PC.
However, most business intelligence suites haven’t advanced in one area — their modeling and administration tools. There still is a heavy leaning towards desktop tools in this area.
Considering that most organizations have internal standards for their client PCs, the process of figuring out how well a tool fits into your standard configuration should be straightforward. Assuming that the product runs on your desktop operating system (always a showstopper if it doesn’t), you should consider these issues:
How well the connectivity and interoperability software you need works, such as drivers for database connectivity and repository connectivity.
Whether you should load the software in any special order. Yes, vendors still provide software that conflicts if you don’t load it in the proper sequence.
When you have choices about where certain components of a tool can reside (on each client, for example, or located once on each server), determine the recommended configuration and whether any problems exist in your environment.
How does performance change if you have a large number of users?
You have to know how performance changes when the number of users increases. You should see little or no performance effect if a tool’s environment is designed correctly and efficiently — make sure the tool you’re considering falls in this category.
What online help and assistance is available, and how good is it?
Any tool worth its salt should include pretty extensive online help. Features to look for include wizards, tutorials, context-sensitive help, and templates for queries and reports.
Does the tool support interfaces to other products?
Although some OLAP products feature direct interfaces from their database into a spreadsheet (typically Microsoft Excel), even if you use a product’s reporting and querying capabilities, users should always be able to bring data back from the business intelligence tool and pop it into Excel for more analysis, manipulation, or whatever they want to do.
You generally should be able to include reports in word-processing documents (such as a Microsoft Word file), graphics and presentation programs (for example, Microsoft PowerPoint), a personal database (such as Microsoft Access), and (of course) a spreadsheet (such as Excel).
What happens when you pull the plug?
Go ahead — try it. In the middle of a query or report, turn off your PC and see what happens.
You want to ensure not only that users can restart a desktop PC without any leftover configuration problems (for example, temporary files and workspace errors that prevent the user from doing additional work until the errors are fixed), but also that the interruption doesn’t affect your warehouse’s database (and any intermediate servers).
Or better yet, find out whether the product is smart enough to welcome the user back through his or her browser, reconnecting that user to his or her query.