Continue in 2 seconds

How to Implement a Data Warehouse

Published
  • April 01 1998, 1:00am EST

Bringing Value to the Business Users

Two data warehouse (DW) analysts are camping deep in the forest. Their sleep is interrupted abruptly when a man-eating bear attacks their tent and rips it to pieces. The first DW analyst leaps out of his sleeping bag and runs down the trail for help. Meanwhile, the second DW analyst calmly grabs his running shoes and laces them up while seated at the picnic table. The first DW analyst returns screaming,"What are you doing? We've got to run away from that man-eating bear as fast as possible, and you are wasting time with your shoes!" The second DW analyst smugly replies, "That's always been your downfall--the failure to understand the problem. My problem is not that I have to outrun a man-eating bear--I just have to outrun YOU!"

Understanding The Business Problem First

Many times technical support staffs become focused on the technical solution that a DW can provide rather than the business value. Failure to understand the business problem first launches projects that are technical successes but business failures. History rewards few efforts that maximize performance for multi-table joins at the expense of accurate sales results by region. Business value begins with a solid understanding and validation of the true problem. Business users need data that is flexible, accurate and timely to access. Many times the true business value lies hidden below the surface. Incremental implementation of business value allows validation of both technical and business assumptions and reduces risks that can crater a DW project.

Think Globally, Act Locally

After modeling the enterprise DW subject areas and dimensions, incremental implementation of a subset of the DW (Data Mart--DM) can validate the technical architecture and deliver rapid business value. In a health care business model, the enterprise DW will contain financial, demographic, administrative and clinical information for production of routine reporting views and facilitate the search for "high quality, low cost health care"--the holy grail for health care. To seek the grail, one must not only be true of heart but also build a foundation of incremental data that can be validated along the way.

Initially, the desired health care business value may be as simple as "What medical procedures do we perform at our clinics?" This may be all that you are asked to provide. Your initial DM should be able to answer with a simple query and be considered a success. Slam dunk--the power of relational technology cuts through the legacy data jungle with one slice. Mission accomplished--right? Well, not exactly. Only if you asked the appropriate follow-up business questions of the user before building the DM will this project succeed.

Delivering Real Business Value

Once you know the count of the medical procedures performed, users will ask, "What are the frequency of procedures and distribution of procedures by clinic." Okay, you thought of that and included it in your data transformation. High five. Logically, the next questions might be: "How much does each procedure cost? Does it vary by clinic, by doctor, by demographics?" You can get that, you'll just add a stored procedure. Hey, they never made a big deal over the costs--but you threw it in anyway. Break out the bubbly. Who says IS never delivers! Next: "Who is referring which patients for specialty care?" It just so happens that specialty care accounts for 80 percent of the medical cost for treating patients, so without this information, the rest is interesting, but really not all that useful. Oops. Recork the bubbly. Where is the business analyst? Cancel the project success T-shirts. Just as the business users were getting excited, you had to tell them-- "We can't get that data." You didn't include the referral data from the primary care physician to the specialists. They didn't ask for it in your interviews. This is known in the aviation world as a controlled flight into ground. Crash and burn.

Beyond What to Why

Before modeling the data, defining the source/target map, generating schemas, writing transformation logic and building the DM, you must understand the real business problem. In this case, "What activities are we performing? How frequently are we performing them? Who is performing them, in what locations and at what cost?" were all just the validation of the "what" foundation. The real business question was "why" are we doing it this way? Should we be doing it this way? Is this the lowest cost, highest quality that we can provide?

Chance favors the prepared mind. "What" is expected. "Why" adds business value--and gets you the corner office.

Next month: How do I evolve our DW to keep up with the business demands over time?

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access