I struggle with the term "best practices." Who declares something as a best practice? Is there some governing body that evaluates submissions and elects those that are indeed the best? What are the criteria for awarding something the distinction of being a best practice? The reality is, of course, rather arbitrary. Best practices are, at their best (forgive the pun), more "rest practices." Rest practices are those practices that are used by the rest of us. Best practices, at their worst, are something that has been proven to work once; so, naively, it is believed that they should be leveraged elsewhere.
My difficulty with best practices is not their arbitrary designation, but how the majority of users interpret them. Industry best practices are guidelines, not a religious ideology. I can guarantee you that the world will not come to end nor will your company’s stock collapse if you snowflake a star schema, allow users to query your data warehouse or, heaven forbid, let users update the date within your ODS. As guidelines, these are all very valid, but they are not absolutes. Best practices should be open for questioning as well as customization to fit your organization’s specific needs.
If your organization is beginning its very first data warehousing effort, undoubtedly you will find someone in your IT department walking around with either Ralph Kimball’s Data Warehouse Lifecycle Toolkit or Bill Inmon’s Corporate Information Factory. I personally find this sight both encouraging and cautionary. Both these methodologies are clearly industry-proven best-practice methodologies. Either works very well in a variety of circumstances. While it is wonderful to see someone try to learn and leverage the experience of our industry’s thought leaders, a little alarm begins to go off in the back of my head. This alarm reminds me from painful experience that no best practice works for all companies in all circumstances and complex methodologies like these can cause people to focus on the details and loose sight of the prize.
Your Best Managed Reality
As Jan L.A van de Snepscheut said, "In theory, there is no difference between theory and practice. But in practice there is." I recommend taking this saying to heart. Instead of focusing on implementing a best practice, focus on implementing your best managed reality while leveraging available best practices. The phrase, your best managed reality, is quite short, but has a few powerful ideas hidden in just four little words.
Figure 1: Your Best Managed Reality
Its All Yours
Rest practices, as the name implies, are used by the rest of us. Is your organization unique in any way? Do you have any key differentiators that give you a competitive advantage over your competitors? If so, do you really want to adopt the rest practices used by your competition? Also, does your organization have any key constraints that could limit the implementation of the best practice? Your selected best practice methodology may call for an ODS to feed the data warehouse that will then spawn data marts, but what are the associated operational and infrastructure costs with this architecture? Can your organization afford them?
Treating a best practice as a guideline allows the practice to be customized to your needs. You do need to understand why the components of the guideline are there but should also feel empowered to make intelligent, informed modifications to the best practice to fit your unique situation. A common argument against altering a best practice is you may not understand the nuances of the practice enough to make intelligent and informed modifications to it. However, that argument works both ways. You should definitely never implement something you do not understand.
In for the Long Haul
When working on a data warehousing project, I often find too great of a focus on architecture and actual implementation of the data warehouse and too little on the long-term business functions that the data warehouse will enable and the ongoing care and feeding the data warehouse requires.
I once watched in dismay as an IT project manager continually corrected the project sponsor in his use of the term data warehouse. "We’re building a data mart not a data warehouse" was the response the project manager used every time the words data warehouse were uttered. Technically, the project manager was right. It was just a data mart and a wonderfully architected one at that. Eventually, the project manager did get his way and everyone used the correct term when referring to the data mart. A year after being implemented, though, the data mart was shelved for lack of business value. In this case, the architecture was correct; the terminology true to the methodology, but the business value just wasn’t there. In short, the project team forgot why they were there.
While this may be considered heresy, I firmly believe the implementation of a data warehouse offers absolutely no tangible return on investment to an organization. A data warehouse does, however, enable processes that can offer substantial ROI. This distinction is subtle but extremely important. The business side of the organization must recognize that the implementation of a data warehouse is just the beginning of the work involved. After implementation, the focus may shift from IT to the business side but, nonetheless, the work remains.
One of the keys to implementing a successful data warehousing initiative is ensuring that the project does not end at implementation. The project must continue throughout the enablement of the processes that can leverage the data within the data warehouse in a valuable way. The fact that your customer-centric data warehouse contains information that could provide your organization a 360-degree view of your customers has little value unless the processes to get this information into the hands of the right people at the right time are enabled, the users are trained to use these processes and have bought into the value this information can provide.
Once implemented, the data warehouse implementation team goes away, but who is going to support the data warehouse? Many companies frequently underestimate the care and feeding required for monitoring the ETL processes, performance tuning and incremental changes that will regularly be required to manage a data warehouse. Realistic operational costs of the data warehouse need to be factored in when building the project’s business case.
Is your data warehouse truly flexible? What is the work effort involved to add a new data source, table or field of data after the data warehouse is live? These questions should be analyzed and tested as part of your project’s implementation.
Reality not Ideology
How do the theories and best practices align with your organization’s reality? Many companies, especially those in the SMB space shy away from data warehousing because they believe it’s too expensive. Data warehousing is not too expensive; however, some full blown data warehousing enterprise architectures are. If you can’t afford to implement a best practice dimensional bus or Corporation Information Factory, you should be looking how to leverage key parts of these methodologies to meet your needs.
During the analysis and design phase, leveraging best practices may be important but validating these best practices against your situation and business needs is even more so. I have one client who has a data mart that appears to follow all the principles of good dimensional modeling. However, one of the key reports the users need out of the data mart ultimately required a twelve table join and the creation of a temporary table within a stored procedure to produce the required report. While the data mart may appear to follow the principles of good dimensional modeling design, it does not adequately meet the user’s needs.
In the case above, perhaps the dimensional model was the right approach, but the implementation was off or perhaps given the unique reporting requirements the dimensional approach wasn’t appropriate. If it was the latter, one should not be afraid to adjust a best practice to conform to your best- managed reality.
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