IBM

Try user-mining in writing data warehouse specs

Learn some techniques for mining user knowledge that will help you create an effective data warehouse.

In a typical user interview taken while working up an online transaction processing (OLTP) application, the idea behind the interview is to collect details about a specific, identifiable need of the user. Also, the interview could possibly analyze some process or potential process the user has knowledge of in order to translate that knowledge into a realizable IT process. But in data warehouse applications, the job is not to replace or modify an existing process, but to uncover potentially useful knowledge that is presently hidden. The irony is, that's exactly what the interview is like too!

Difficulty often ensues because the user is usually new to "business intelligence" and can’t really articulate what is needed, let alone how to get there. Here are some suggestions for user-mining that might make the process easier.

Take what you get
As awkward as it might be for you to be uncertain of what to ask in order to ascertain what is needed, imagine how awkward it might be for the interviewee. They may have some vague idea of what they can learn from data viewed from certain perspectives, but it's guesswork at best. The relative importance of their potential discoveries, too, is somewhat speculative. How can you know the business priority of the analytics they suggest? Well, often you can't, at least not early on. Enter into this process with an expectation that clarity may emerge slowly, and feel satisfaction in whatever progress you make in any one interview, however slight. Don’t let yourself become frustrated; this is normal.

Three is better than two
When a user is describing what is wanted in an analytical app, the discussion usually centers on processes and can cover tremendous vistas of territory that are unfamiliar to you. How do you follow what is said, make notes, keep track of where you are in your discovery process, and think of the next leading question, all at once? You probably can't. Since this isn't going to be the simple back-and-forth that you're accustomed to, consider taking a colleague along. One of you asks questions, the other takes notes. That way, you can stay focused, and you create opportunity for real direction to emerge in the dialogue.

Four is better than three
As effective as it may be to have another person on your side of the table, it may be more effective still to have another person with the user. Consider interviewing users in groups of two or more. Let them go back and forth. Let them think through the hidden possibilities, reminding each other of overlooked points. There will be occasions when it's advisable to let them run free a little, while you work toward a clear picture of what they will want to see, and your partner takes notes.

Flush out new data sources
When sniffing out and analyzing data sources, the development team is going to naturally focus on physical resources. IT people tend to think in those terms; the available data is found on the available media, right? But users don't think that way. To an employee who contributes day-to-day to business decision-making, data comes from the computer on the desk, from magazines and journals, from news releases on the Web, from satellite television. They are indifferent to the conveniences and constraints that rule the thinking of the IT people who list the data sources. You need to listen to the users! The data they use is the data they need, whether it's convenient for IT or not. If they get important industry data from a print journal they receive, and it affects the analytical process they require, then it's your job to capture that fact and seek out ways of obtaining that information and getting it into the warehouse. It won't be fun, but that's why they pay you the big bucks.

Follow up on the business end
When the information you need is on the far side of the actual business processes—and is inferential, to boot—you’ll do well to have a real understanding of those business processes. Ordinarily, a cursory understanding is adequate, because there are people around you who can keep the app on track if your comprehension isn't exhaustive; they’ll correct you if you miss. But with an analytical app, you're one level removed from that safety net. If you miss on the business rationale, you could write online analytical processing (OLAP) procedures that seem to give the user what is needed, but actually miss—and it might not get caught. So you need to go the extra mile in understanding not only the processes that produce the data being analyzed, but the implications of those processes. If need be, schedule interviews with others to fill in the gaps in your knowledge, even if they don't directly contribute to your specs.

Come back for more
In the OLTP world, you do a follow-up interview or two when it's called for. You expect it; they tolerate it. In the OLAP world, it could be more than two interviews. It could become a ritual. And once you've opened the doors, they could be calling you for follow-ups. Don't let it surprise you. Go into this process expecting an ongoing interview process—and if the users aren't clear that this is how it will be, break it to them gently.

Last, but not least, here are some suggested questions
  • If you could see into the future, what would you look for?
  • What’s your wish list, with regard to what you don’t know that you wish you knew in order to do your job well?
  • Performance-wise, what does a home run look like?

…And finally, the big one:

What holds you back?

About

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

0 comments

Editor's Picks