Ruminations on the System i Market
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
| 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 |
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.