Product Lines

Ruminations on the System i Market

June 11, 2007

When Does a Query Tool Become a BI App?

I've just spent a couple of days researching a product roundup on query and reporting tools. (You'll get to see the results in the Route Finder insert of our August issue.) That exercise brought home to me once again just how fuzzy the dividing lines are getting to be between such concepts as "query and reporting tools," "business intelligence applications," "executive information systems," "data warehousing solutions," and utilities that help developers query databases as part of building such applications. And I guess I forgot to mention online analytical processing apps, extraction/transformation/loading utilities, and decision support systems, but you get the idea.

It's not that what each of these application types does is imprecise. With nearly any search engine, any of us could come up with explanations for all of these terms in about five minutes that would show a separate, well-defined area of the business intelligence (BI) turf for each one. The fuzzy part is where any company's solution stops being one BI product type and starts being another. And, more unfortunately, how some people are coming to refer to BI in general.

Query and reporting tools are a good example. You might think it would be fairly easy to come up with a short list of products that let you structure a database query and write the results into a predefined report template and send it to the boss. It isn't, really. Because most programmers could do that ad hoc on their own, vendors of third-party products realize that to sell software, their product has to do a little more than that, even if the intended audience is a bunch of relatively nontechnical end users rather than programmers. So the vendors add more features, more spoon-feeding so even a nontechnical administrative assistant can use the software, more output options, maybe an analysis tool. . . Pretty soon, though, you've crossed the line to a BI app. But where exactly did that happen?

I turned to an expert for help: Scott Steinacher, our technical editor who focuses on BI (and who happens to be the author of the cover article for the Query and Reporting Route Finder in August). I asked him, "Where do you draw the line between a 'query and reporting tool' and a 'business intelligence application?'" His answer was pretty much what I feared.

While he drew a distinction between BI and data warehousing because the latter "implies a specialized database built specifically to support analyses," he also admitted that any more "both terms are used interchangeably" and that, when you really got down to it, a list of query and reporting tool products had to include all products of any BI type because all offer query and reporting functionality. But really, among those who aren't BI experts, aren't all these BI product types and terms becoming somewhat interchangeable?

Another area of blurred lines are several products in the application development tool area. Mrc offers m-Power and mrc-Productivity Series, two solutions known primarily for helping developers build System i apps in Java and RPG, respectively. Developers can use both to create queries and associated reports that they then pass on to end users, so can they be employed by an end user to query databases and generate reports? I asked Heather Gately, mrc's marketing director, and she assured me they can. "Yes, end users can use [both products] themselves to query the database and create reports, etc. In fact, we have many customers who do just that." There are other products that are primarily programmer tools that also provide a query and reporting function, such as Linoma Software's Surveyor/400, but this example makes the point.

So where do the lines get drawn between these product types? I realize one can make the argument that this is a discussion without a real meaning if you look at products being important only in terms of the functions they offer. You buy software that does what you need it to do and on a certain level, who cares if the vendor calls it query or BI or decision support?

But that's only true to a point. And that point is when your CIO says to your IT manager, "we need a BI app, go find us a good one." What does she mean when she says that, and what does her IT manager think she means? Probably more discussion takes place, but maybe it doesn't, and maybe it does but doesn't do much good. The IT manager might be afraid of appearing to be ignorant or rude if he should ask the CIO to define what she thinks a BI app is. But maybe they actually have two different concepts in mind. One wants a data warehouse, the other is thinking of a nifty little query-and-report writer that end users can check order volumes and customer credit status with.

If we can't agree on terms, if we don't really know where a query tool stops being just a query tool and turns into a BI app, a fundamental miscommunication can take place that maybe no one sees until considerable time and money's been spent following the wrong path. So I leave it to you, the jury. Where should the lines be drawn? When does a query tool become a BI app?

Posted by at June 11, 2007 2:27 PM

Comments

I would have to agree about the blurred line between what would be considered a query and reporting application and what would be called a business intelligence application. However, whether a comprehensive Mrc-Productivity Series or a less expensive programmer tool like Applied Logic's FEU database tool that also provides query and reporting functions, the aim is the same - to provide vital information in a meaningful and efficient manner. I might suggest that a BI application is primarily used by non-programmer staff, while a Query/Reporting application would more likely be used by a programmer type.

Posted by: Bryan Schaap at June 13, 2007 12:31 PM

I've just spent about 3 months trying to find a 'query and reporting' tool. And ended up looking at everything from simple shells over the iSeries SQL functions to ETL/warehouse/query and reporting combinations. I think that I would parse the difference between 'query' and 'BI' on three axes.

1) Query generally costs less.
2) Query hits its technical limits pretty quickly either in the complexity of the queries or the ability to excute the queries. Whereas BI seems better designed for on-line access to the information.
3)BI is marketed toward dashboards and other 'big picture' presentation, query is focused on getting specific answers or reports. BI often lacks reporting tools, or has to offer a separate tool set.

But I agree it is really a distinction without a difference, you would use either query or BI to do the same thing, and want to be able to do it the same way. At this point I view BI as simply more expensive, query faster. And I've concluded that most CRM systems actually offer a better combinations of features and price for reporting and dashboards than either query or BI tools do alone.

Posted by: Gerritt at June 13, 2007 12:50 PM

Delivering reporting and analysis applications is more than selecting a tool for the job. It means ensuring that each application provides each class of user with the function, ease of use and affordability they need for their jobs.

These applications are data-centric NOT tool-centric!

Affordably providing the application’s users with a single, secure, trustworthy repository of ALL the data needed for reporting and analysis solves the problem! In fact once the data problem is solved there are hundreds of query tools, report writers, etc., capable of affordably providing the functionality and ease of use the users need.

GSS Group is delivering these affordable data repositories today! See gssgrp.com.

Posted by: Pat Gleeson at June 14, 2007 1:20 PM

Post a comment




Remember Me?

(you may use HTML tags for style)

July 2008
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Blog Policy

Our blogs are editorial content of System iNetwork. We welcome your comments and opinions and encourage lively debate on the issues, and we reserve the right to edit all postings for clarity, length, civility of tone, and appropriateness to the topic under discussion. Comments consisting of product or job solicitations and other spam, profanity, and extreme rudeness will be deleted. We also reserve the right to publish excerpts from the blogs in our e-mail newsletters and print magazine.

ProVIP Sponsors