By J. J. Gahr

I know there a few folks out there that remember the B-52’s and their single "Love Shack." I personally loved the song and the band. Singing this song made me realize the number of "data shacks" that have been implemented throughout the business community. Unfortunately in the BI world, a "data shack" is not as fun as the "love shack"!

Data Warehousing / Business Intelligence projects have taken some strange paths over the past few years. The one common and positive theme that I have seen during this evolution is that the business community was usually at the forefront of the initiative. Decision-makers were experiencing an "information pain" that needed immediate attention. The IT (information technology) group wanted to get out of the report writing business to focus on application and web development. Allowing executives and business users access to data sounded like a quick and easy fix. We soon found out that this so-called "quick fix" needed further evaluation.

Data Shack v1.0

As the Director of Sales and Marketing, the green bar reports from IT were just not cutting it any longer. You have seen those cool tools that allow you to "point and click" for ad-hoc reporting. That multidimensional analysis and OLAP (online analytical processing) technology would really help you in your decision making process also. The call was made to the vendor and two days later you had the software loaded on your desktop and you were slicing and dicing. WRONG!

That operational system that you are going against was not that easy to decipher. There was a multitude of tables to navigate. The names of the tables and columns were somewhat cryptic and had no meaning to the business. To make things worse performance was horrendous. The queries were taking up to 2 hours to return a result set. What happened to those beautiful pie charts we were promised!

Data Shack v2.0

"I told those users that it was not that easy. We needed to get that data off of the production system and onto its own reporting server", was the statement made by the IT Manager. New servers and replication software were purchased, schedules put in place and now we would have a solution to handle our decision support needs. Well….

Even on the new server, the performance was nothing to write home about. The table names made a little more sense but do we really know what we are looking at? We were also missing some key pieces of information. Although we are capturing sales information such as dollars and units, there were no costs involved. As a sales manager you hold your reps accountable for selling high margin products. This so-called solution cannot answer that question. The most frustrating aspect of the whole encounter is that the reports from the so called "data warehouse" do not match the green bar reports from the operational system. Which numbers are correct?

I thought it was easy!

What were the primary problems during this whole initiative? There was no executive sponsor driving the process and business and IT really did not speak to each other.

Although business people know what information they need to steer the boat, they may not have a clue as to which system the data is coming from. IT has the information but does not know what format is required for presentation. This only speaks to a portion of our problem.

Data Shack v1.0 was an attempt make the data "pretty" and to have ad-hoc capabilities. Reporting against a transactional system can be frustrating for both parties involved. OLTP (online transactional processing) systems are architected to capture transactions. They perform this duty effectively.

Data Shack v2.0 also resulted in a crash. There was still no interaction between both parties and no methodology followed. An assumption was made that technology could solve a business problem. This is not always the case. Just because we have a new high performance server to handle reporting traffic is no guarantee that the data is "clean". What is worse is that we are still utilizing OLTP architecture.

We covered 2 examples of "data shacking" so far. Each was an attempt to solve a business issue. The problem was that there was no communication between the two internal organizations. The one thing to realize is that Business Intelligence is a process that requires a methodology. Each of the examples tried to solve a business problem with a quick fix. This is not reality.

Business Intelligence

A true data warehouse/business intelligence initiative requires a proven methodology and an executive sponsor. Per Bill Inmon, the data warehouse has certain criteria that must be met. The Corporate Information Factory (CIF) has various components to address certain reporting needs of the business. Regardless of the reporting needs of the enterprise, the data must be subject oriented and integrated. These two features of the CIF will help ensure the validity of the data throughout the system. If you look at the logical architecture, you will notice that regardless of where you are receiving your information, the identified criteria are met.

Technology solves a portion of the puzzle from a reporting and analysis perspective. Planning, analysis, experience, thought and technology solve the remaining piece of the puzzle. All parties involved are required to solve the latter piece of the puzzle.

About the Author

J. J. Gahr Jr. is the director of business intelligence at Emplifi. J. J. is a frequent contributor for Real-World Decision Support and may be reached at jgahr@emplifi.com or via phone at (412) 490-9710.