In the mid to late nineties, I was well known for speaking about the Seven Deadly Sins of Data Warehousing. It was always a popular presentation, a timely topic and a lot of fun to share the experiences I had gathered through more than two years of research on data warehouse projects and their outcomes. Although my publisher wanted me to author a book on the topic, the time constraints of building our company prevented me from delivering it during that time frame.
I was recently contacted by my book editor about producing another book, and the subject of the Seven Deadly Sins came up. We both thought it would be interesting to revisit them and see how the industry is doing in these categories.
In reviewing the Seven Deadly Sins of Data Warehousing, I found that we have made significant progress on many, are stuck in the middle on others and have dismally failed to make any measurable progress on some. Regardless, I think you'll agree that it is relevant to measure our progress, or lack thereof, against these milestones.
For those of you who are unfamiliar with the Seven Deadly Sins of Data Warehousing, they are:
- Persp ective
- Tunnel Vision
Here's where I think we are, in inverse order, for each of these areas.
7. Tunnel Vision
The primary manifestation of this sin has always been an over-focus on technology at the expense of business focus and measurable business impact and solutions. Today's teams are much more business-aware, with the instances of pure vendor- hype-driven monuments to technology much fewer than in the past. This is not to say that this sin has been eliminated, as today's data warehousing teams are still slipping into the clutches of technology once they get their projects underway. Sometimes, teams get completely caught up in the details of the technology implementation and lose focus on why they are building the data warehouse system in the first place.
Tunnel vision is readily apparent in IT-driven projects. These initiatives rarely have a mission statement and are even more rarely in alignment with key business strategies. Surprisingly, you can still find a significant number of these IT-sponsored "build it and they will come" projects sprouting up. Their prospects of sustainable success are just as dismal now as they have ever been.
The classic perspective challenges in data warehousing projects have been centered around normalized versus denormalized data modeling, mission criticality of the data warehouse system and user orientation of the team. Of these issues, the mission criticality of data warehouse systems is more acknowledged today than in the past. There are still many teams caught in the ongoing modeling controversy. The message has not gotten through that there is no one "right" way to do data warehousing. There is no panacea. Every site requires an approach suitable to its unique circumstances, not a "one size fits all" approach.
The requirement for 100 percent user orientation of the team and the resulting system design is often traded for ease of construction and maintenance by the IT team. These projects inevitably suffer lowered utilization rates and often wither away as budgets dry up. It is critical that users remain number one on the priority list and that ease of use be the sole litmus test used in the design of the system.
The most prevalent signs of myopia have long been lack of design, staffing, budgeting and planning to enable a sustainable system. Teams often get so caught up in the near-term challenges of delivering the first few phases of the system that they lose sight of the long-term requirements for sustainability. Chief among these failings is not properly managing expectations of the team and the business. That the system will require significant, ongoing maintenance resources and funding needs to be stressed repeatedly.
The second most common case of myopia is building a series of non-architected data marts and calling it a data warehouse system. Non- architected marts may be quick and easy; but they are part of the problem, not part of the solution. Teams would be well served by remembering to architect first and build second. A short investment in the development of an enterprise data mart architecture (EDMA) will save countless hours and dollars when the inevitable edict comes down the line to integrate the non-architected data marts.
Next month we'll look at the remaining sins and see how we've done overall.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access