The very definition of business intelligence (BI) continues to evolve with each passing year. It should therefore come as no surprise that as little as 15 years ago, "data warehousing" was the term in vogue, yet no one would have known what you were talking about had you mentioned business intelligence. Sales analysis begat data warehousing; data warehousing begat business intelligence; and so it goes. Like all technology, defining the very thing you're looking to accomplish can be a dangerous (and sometimes misleading) undertaking. It seems reasonable that the act of selecting anything should be preceded by creating a definition that accurately describes your business objectives.

Like all good (ahem) writers, I followed my own advice prior to writing this article and went out on the Web to see how others had bothered to write about this topic. I found it to be an enlightening and somewhat expected exercise in futility. It was enlightening in the sense that I discovered words and terms I had never heard before, yet it was expected because I think that, to a large degree, software vendors throughout the marketplace have failed the customer in defining the products they sell. So I can appreciate that it can be a real challenge to define what business intelligence means to your organization when you're scratching your head over some of the acronyms and terms at BI Web sites. Here are some good ones I found:

• Customer Data Integration Hub
• Scalability Assessment Framework
• Unified Dimensional Model

I'm sure all this means something to someone, somewhere. But shouldn't it mean something to the consumer as well? When you approach any software evaluation, it's probably a good idea to be able to clearly describe what any given product does. If you can't explain it to a coworker, that's a red flag right there. Unfortunately, this concept has eluded BI vendors and even their customers for a couple of reasons:

Complexity Equals Big Business

"Business intelligence" is really just the latest catch phrase in a long line of catch phrases. In the 1990s, you never heard the term "BI," but you heard about data warehousing. Could a data warehouse really just be a large array file or a series of summary files on the AS/400 or elsewhere? As the vendor supplying the solution, the answer was a categorical "no"—not if you were hoping to sell a large company a multi-million-dollar software solution. Separate software and hardware for data cleansing and multi-dimensional data storage were added to the actual analysis software before a "real" solution could ever be considered. Of course, these products were extremely expensive and difficult to understand, so you needed to hire consultants to actually implement the data warehouse. If you were talking to a Windows-dependent vendor, it was critical for you to get the data off the platform you were on. Why? "Because you have data contention issues!" The sales reps for these extremely expensive solutions were well-armed with technical gibberish and logical replies to the gibberish itself. It should come as no surprise, then, that the burgeoning $20 billion data warehousing market that analysts like Gartner and others predicted only partially materialized. And much of that did not end happily.

Big Companies Like Complexity

Writing this article reminded me how unkind the mid to late 1990s was to the AS/400 marketplace. If you've ever worked for a big company, you know there are many inefficiencies in place, but perhaps the worst inefficiency of all is the large-company IT culture. The general idea is that in order to survive as a manager, you must have large, visible projects associated with your area. In order to thrive as a manager, you must have many employees or consultants reporting to you. So first you get the project; then you get the money. That statement is extremely cynical and may not apply to every large company, but it really hits home when it comes to what was happening with the AS/400 back then. If you were a corporate IT manager, how could you get more people to work on something that already works well? No, that wouldn't do at all. Listen closely, and you can almost hear it still: "The AS/400 is antiquated, doesn't play well with others, and must be assimilated."

Oracle and SAP were the happy recipients, as were the many managers and consultants who laughed their way through years of incomplete multi-million-dollar projects. (This is becoming a common refrain).

It was no different in the area of data warehousing, when the death throes of that multi-dimensional database could be heard several cubicles away. In all fairness, the idea behind this software was before its time, but it had to run on a shaky Windows operating system and an underpowered PC. You could only stuff so much data into that can before it would gurgle and expire. Whatever you want to call it, business intelligence was not off to a great start. Fortunately for the consumer, things changed for the better with more reliable operating systems, better software, and cheap memory. Solutions that aggregate and analyze business intelligence have perhaps been one of the biggest beneficiaries of technology commoditization, but the business model of some of BI vendors is dependent on old assumptions about performance and data consolidation. Educating yourself on which issues have changed and which ones haven't will help you sift through the sales-speak and focus on the real issues at hand.

Questions, Questions

So how do you decide on a business intelligence solution? You should ask everyone involved in the decision-making process a number of questions, including these:

• Who are the users of the data? Will they be only analyzing data, or do they need to create their own requests as well? What business metrics are they interested in measuring? You need to actively solicit and organize input from everyone who is involved with using the solution. Users buy into (read: value and appreciate) a solution that's tailored to their specific business needs more than one that provides aggregate data based on assumed needs. This point is a given and is thankfully a common message conveyed by most BI vendors.
• Can the business metrics your users want be extracted from your production data? If so, is it all on one platform or on multiple platforms? The iSeries might be the home of some of your valued application data, but it's also very possible some of that data resides elsewhere. Any solution you choose should be capable of extracting data from any SQL-compatible database. Conversely, just because you have other kinds of production servers, does that mean you should always remove the data from the iSeries? Hardware and software performance improvements make these kinds of arguments far less meaningful than they were even just a few years ago. Storing your business intelligence in one place may still make sense in many cases, but it's also quite possible that your data abstraction can be handled completely by your software solution. Let reason be your guide here. If there's no functional reason to compartmentalize your data into newly organized tables or a repository, then why should you?
• If summarized/cleansed data is necessary, is it because of performance, clarity of the metadata associated with your database elements, or both? Traditional big-ticket BI vendors heavily rely on your purchasing expensive ETL (extract, transform, and load) software to cleanse and summarize your data prior to the actual loading of a data repository associated with the end solution. There's no question that cleaning data is often a necessary adjunct to creating a successful BI experience, so look for solutions that have an integrated approach to both the cleansing and analytical sides of this equation. It's not desirable to be dependent on a tool that's external to the BI software itself or one that relies on ODBC for that matter. In either case, you likely lose some of the inherent metadata (like field descriptions) that make the solution capable of operating under circumstances in which data abstraction might otherwise be unnecessary.
• How complex or easy is it to get the solution working "out of the box"? What are the hidden costs generally associated with more-complex solutions? A good rule of thumb is that if the prospective BI vendor will only give you a dog and pony show over their own data, warning alarms should be sounding in your head. Limiting the demo to canned data with predefined analytics is a tried and true method of separating fools from their money. Unless you have unlimited resources, you should be considering how easy it is to make this thing actually produce results without having to pay consultants from XYZ BI vendor, right? Don't get me wrong; sometimes, generating a production-quality result requires more than just a cursory view of the data, but does that always have to be the case? You should be able to summarize data, drill down to subsequent detail hierarchies, produce graphical dashboards, etc. without having to essentially buy the product first.

Assessing a BI solution isn't always simple, but good partners should try to make understanding and using their software as simple for you as possible. You shouldn't have to depend on that partner to create something that your instincts tell you should be easy for you to create on your own. Try not to evaluate software for requirements that might need to be addressed in a year or two. Buy software that solves today's problems in a cost-effective, reasonable manner, and you can't go wrong.

Chris Wilson is Director of Sales for Advanced Systems Concepts, Inc., a Schaumburg, Illinois, software company that develops and markets SEQUEL, the iSeries business intelligence/reporting tool. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

9 data governance strategies that will unlock the potential of your business data

Data observability: The missing piece in your data integration puzzle

From Legacy to Modern: Upgrading Your BI Strategy with LANSA BI for IBM i