Consider these situations:
1. Organizations predisposed to EDW that have business units with short-term needs and low organizational appetite for consolidating departmental data marts for longer-term gain. There is an interesting assumption that doing it "right" means that it will take longer. Short-term needs will continually be met by short-term solutions.
The trick is to be ready for the short-term solutions by establishing the EDW architecture as soon as possible and then properly architecting the short-term solutions (think globally, act locally). I prefer to look at it as though there may be an investment required - concomitant with business value delivery(s) - in an unarchitected environment to create an efficient architecture and establish a workable BI methodology.
Figure 1: Enterprise Data Warehouse Architecture
There are different maturity levels for EDWs. If the team is difficult to work with and has not established flexible rules of engagement, the EDW, though architected well, will not see new data and users. Marts will sprout in those organizations, taking down the maturity of the EDW in the process. On the other hand, an organization needs to learn how to work with an EDW and have top-down direction for adherence to EDW principles. Without them, the EDW approach will suffer.
2. Organizations with a data mart orientation or a belief that EDW equates to failure because it is too much to bite off at once. The invalid implication here is that the EDW architecture must be implemented with a methodology that has unbearable, year-plus timelines to business value delivery.
Architecture is different from methodology. EDW failures are mostly the result of methodology, not architecture. I am often asked, "When do you achieve an EDW if you take a step-by-step, incremental approach?" The question is theoretical. Who cares when the label can be applied to it with a clear conscience if you have a flexible, scalable architecture?
3. Organizations without an architectural foundation. Our knowledge-workers come to our programs with different levels of understanding about what an EDW is - and, for that matter, what data marts, ETL, data warehouses and enterprises are. It requires a strong commitment on the part of BI leadership to define corporate architecture and terms, and instill their understanding into the build team and the user communities. Until this is achieved, it is difficult to effectively discuss EDW.
Successfully defining architecture, perhaps with the CIO, is a good start; however, you cannot expect the CIO to follow through with the education and selling process to peers and constituents. If you leave a steep hill of acceptance for the CIO to climb, nothing will happen.
Define your enterprise based on a reality check of what parts of the organization are possible to subsume into the warehouse in the next several years. It will not necessarily be the entire entity that rolls up to your stock symbol. EDW is a "big tent" architecture, and the bigger, the better; however, there still must be digestible pieces along the way.
You can't have solid EDW architectures when the organizational mind-set is data mart-oriented or in enterprises where architecture is not considered important. One size does not fit all when selling EDW architecture in your organization. Take realistic inventory of the implemented and desired architecture, and approach the organization with targeted messages to fill the gap.
William McKnight brings process, organizational and architectural focus to building strategies and implementing master data management and data warehousing programs that have consistently, for many years, improved the productivity and performance for his clients including several global corporate giants. McKnight, award-winning consultant and author, can be reached at McKnight Consulting Group.
Be the first to comment on this post using the section below.