I came across a shop recently that was reeling from a data warehouse failure. It had spent millions with a consulting organization building a very robust data warehouse. The users loved it and were eagerly using it. Then, several months into production, one of the source environments was upgraded. Several fields no longer contained the same data as before. The upgrade was not an unexpected event. Upgrades had happened at least yearly since the source system was implemented and, each time, there was impact on the fields.
Unfortunately, they had turned the data warehouse project over completely to the consulting organization and had no internal knowledge of how to fix the DW to adjust to the new fields. Slowly the users began to lose faith in the data warehouse while the data warehouse team scrambled to learn the system, fix it and do damage control at the same time.
After daily directives akin to "this field is named x, but it really contains y, please adjust your reports", the users began to go back to the old ways of getting data and doing business. They had been burned and the next time around getting their buy-in will be much more difficult.
There are a few morals to this story. One is to insist on knowledge transfer as part of any consulting engagement for data warehouses. Insist on it in very tangible ways and use consulting to augment your in-house skills, not for a complete take-over of the project.
The second moral
Requires Free Membership to View
has to do with making your ETL metadata-driven such that it truly is
understandable in a layer removed from code, and therefore manageable. Also get on the change
control for all source systems feeding your data warehouse!
For more information, check out searchCRM's Best Web Links on Data Warehousing.
This was first published in November 2001
Join the conversationComment
Share
Comments
Results
Contribute to the conversation