Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

January 14, 2002

The Anti-Architect

How not to design and roll out a data warehouse

By Ralph Kimball

Data warehousing is interesting because it involves so many different kinds of businesses and because the responsibility is so central to the mission of IT. But, as important as this job is, I have often felt overwhelmed when I listen to someone explain all the data warehouse manager's responsibilities. Be responsive to the business. Be responsive to the end users. Use technology wisely. Don't forget anything. Deliver results on time. Be courteous, kind, thrifty, brave, clean, and reverent (like a Boy Scout).

Sometimes I find that casting data warehouse responsibilities in the negative is an effective way to cut through the vagueness. We've always been told what to do; now let's balance the list with what not to do. I list the mistakes in order of increasing seriousness here. Of course, all of these are showstoppers, so you might order them differently.

Mistake 1: Rely on past consultants or other IT staff to tell you the data warehouse requirements. Don't interview the end users. The reality: Nothing substitutes for direct exposure to the end users. Develop and trust your instincts gained from firsthand experience. Develop the ability to listen.

Mistake 2: Live with the assumption that the administrators of the major OLTP source systems of the enterprise are too busy and important to spend a lot of time with the data warehouse team, and they certainly cannot significantly alter their operational procedures for passing data to or from the data warehouse. The reality: If your organization really understands and values the data warehouse, then the OLTP source system administrators should be effective partners with you in downloading the data you need and uploading your cleaned data, such as customer names and addresses.

Mistake 3: After the data warehouse has been rolled out, set up a planning meeting to discuss ongoing communications with the end users, if the budget allows. The reality: Newsletters, training sessions, and ongoing personal support of the end-user community should all be part and parcel of the first rollout of the data warehouse.

Mistake 4: Make sure all the data warehouse support personnel have nice offices in the IT building, which is only a short drive from the end users. Set up a data warehouse support number with lots of touch-tone options, and a guarantee that you will get back to the end users as soon as possible. And of course, assure the users they can email the support team any time, day or night. The reality: Data warehouse support people should be physically located in the end-user departments, and while on assignment, should spend all their waking hours devoted to the business content of the departments they serve. Such a relationship engenders trust and credibility with the business end users, which ultimately is the "gold coin" for IT.

Mistake 5: Declare end-user success at the end of the first training class. Make sure that the end-user tools are very powerful and be sure to train every feature and every command, including building complex reports, in the first training class. Defer training about the content of the data, because you have scheduled the training class on the dummy data you have been using for development, and the real data won't be ready for another few months. Don't bother to schedule follow-up training or training for new employees. You've met the milestone. The reality: Delay training until your first data mart is ready to go live on real data. Keep the first training session short and focus only on the simple uses of the tool. Train 50 percent on the tool and 50 percent on the content of the data. Plan on a permanent series of beginning and follow-up training classes. Take credit for the user success milestone when your trained users are still using the data warehouse six months after training.

Mistake 6: Assume that sales, operations, and finance end users will naturally gravitate to the good data and will develop their own killer apps. The reality: End users are not application developers. They will use the data warehouse only if a killer application is waiting to beckon them.

Mistake 7: Make sure that before the data warehouse is implemented you write a comprehensive plan that describes all possible data assets of your enterprise and all the intended uses of information. Avoid the seductive illusion of iterative development, which is only an excuse for not getting it right the first time. The reality: Very few organizations or human beings can develop the perfect, comprehensive plan for a data warehouse up front. Not only are the data assets of an organization too vast and complex to describe completely up front, but the urgent business drivers, and even the staff, will change significantly over the life of the first implementation. Start with a lightweight "data warehouse bus architecture" of conformed dimensions and conformed facts, and build your data warehouse iteratively. You will keep altering and building it forever.