A friend of mine (call him Bruce) recently accepted a job as an HRIS manager for a mid-sized company. During the interview process, he asked questions about the company’s current systems’ infrastructure and architecture. Bruce was told that there were “challenges”, to put it euphemistically. One of his chief objectives would be to attempt to simplify what had become a very complicated albatross of financial, HR, and payroll systems. Suffice it to say, this would be a Herculean endeavor.

Upon starting his position, Bruce did what most professionals would do in this situation: he talked to people about what they liked, didn’t like, and expected from their applications, systems, and data. Among his findings, his colleagues wanted the following in the near future:

• better reporting
• less redundancy among systems
• improved access to data
• simplified versions of the truth

Now, a few of the financial and HR folks threw out a potentially dangerous term: data warehouse. Why do I qualify data warehouse with the phrase “potentially dangerous?” Because it’s one of those terms that laypeople often mistake as silver bullet.

Soon after speaking with Bruce about his next steps, I had a conversation with another friend of mine – data warehouse expert Rob Paller. (I was pleased to learn that I have at least two friends. Whoever bet the under, pay up.) Rob largely confirmed what I believed to be true – i.e., that non-techies often mistakenly believe that all data problems will be solved merely by putting the data in a place in which people can access it. Such places include:

• data warehouses
• data marts
• OLAP cubes
• really big tables

A Bricks and Mortar Parallel

I have always thought of data warehouses in terms of their bricks-and-mortar equivalent. Since I always seem to be at the local food store, let’s use a related example.

I’m hungry and have a craving for cheddar cheese potato chips, preferably Pringles. (As an aside, I love how Pringles has its own website, but I digress.) Let’s say that I can’t find the Pringles because someone won’t give me the key to the pantry. Maybe I can’t find them in my unorganized kitchen cabinets. Or I could be somewhat of a slob who keeps stashes of food all over his townhouse in New Jersey. (Oh yeah, we’re really being hypothetical now.)

Now, someone magically puts all of my food in my walk-in pantry. I can now finally and blissfully see the potato chips. All of my food is stored in one place. But does this necessarily solve my problem? (No whammies, no whammies….)

No, it doesn’t. Consider the following questions:

• Are the potato chips now stale?
• Is this the right type of right potato chips? I want cheddar cheese flavor and they’re many types, you know. (See referenced website above.)
• Do I have dip? I’ve got to have my dip.

Simon Says: The Data Warehouse isn’t a Panacea

I could go on, but my fundamental point is this: Don’t expect a data warehouse to solve all of your organization’s data problems. You’re bound to be disappointed. Perhaps better access to data will manifest the core issue – specifically, that your data is messy, redundant, incomplete, contradictory, or some other choice adjective. Merely populating data warehouses with tons of information doesn’t magically cleanse that information any more than a pantry can magically restore an inedible, open six-month-old can of Pringles to an edible state.