The Anti-ArchitectHow not to design and roll out a data warehouseContinued from Page 1 Mistake 8: Don't bother the senior executives of your organization with the data warehouse until you have it up and running and can point to a significant success. The reality: The senior executives must support the data warehouse effort from the very beginning. If they don't, or can't, then your organization may not be able to use a data warehouse effectively. Get this support at the very beginning. Mistake 9: Encourage the end users to give you continuous feedback throughout the development cycle about new data sources and new key performance metrics they would like to see. Make sure to include these requirements in your upcoming release. The reality: You need to think like a software developer and manage three very visible stages of developing each data mart: 1. The requirements-gathering stage, in which every suggestion is considered seriously 2. The implementation stage during which changes can be accommodated but must be negotiated and will generally slip the schedule 3. The rollout stage, where the project features are frozen. In the second and third stages you have to stop being a pal to everyone or else fall victim to scope creep. Mistake 10: Agree to deliver a high-profile customer-centric data mart as your first deliverable. Ideally choose customer profitability or customer satisfaction as your beginning point. The reality: These kinds of data marts are "second level" data marts with serious dependencies on multiple sources of data. Customer profitability requires all the sources of revenue and all the sources of cost, as well as an allocation scheme to map costs onto the revenue! Focus for the first deliverable instead on a single source of data and do the more ambitious data marts later. Mistake 11: Define your professional role as the authority on appropriate use of the data warehouse. Educate the end users as to how to think about the data, and what the appropriate uses of computers should be. Systematically raise the sophistication of the end-user community until most end users can develop their own data access applications, thereby eliminating the need for long-term support. The reality: Your job is to be the publisher of the right data. Your professional role is to listen to the end users, who are always right. The end users, not you, define the usability of the computers. You will be successful only if you serve the end users' needs, not the other way around. Mistake 12: Collect all the data in a physically centralized data warehouse before interviewing any end users or releasing any data marts. Ideally, implement the data warehouse on a single, monolithic machine where you can control and protect everything. The reality: More power to you if you have the organizational clout and the budget to implement a fully centralized data warehouse. But, in my opinion, a centrally planned data warehouse is as likely to be as successful as a centrally planned economy. It's hard to argue against idealistic inspirational promises made in advance of reality, but the truth is, the centrally planned systems often don't work. Instead, build cost-effective, distributed systems, and add incrementally to the logical and physical design as you learn from your end users. And finally, don't assume that your big, expensive, centralized machine is intrinsically secure because it is big, expensive, and centralized. If anything, such a centralized machine is a single point of failure — a system vulnerability. Ralph Kimball coinvented the Star Workstation at Xerox and founded Red Brick Systems. He has three best-selling data warehousing books in print, including The Data Webhouse Toolkit (Wiley, 2000). He teaches dimensional data warehouse design through Kimball University and critically reviews large data warehouse projects. You can reach him through his Web site, www.rkimball.com.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
