I have come across two approaches/practices in building data warehouses. One is constructing a data warehouse at the enterprise level and then having data marts based on the functions/business process of an enterprise. The other is constructing data marts based on functions/business processes and then integrating data marts to create a consolidated enterprise data warehouse. Which approach would you recommend and which approach will deliver a quick return on the investment and deliver a significant ROI?


Sid Adelman's Answer: The best approach is to know where you are going with an enterprise data warehouse and iteratively build and add each subject area into the enterprise data warehouse and then populate the data marts from it. This will give you iterative and additive ROI with each new subject area and will show progress to keep the budgets, resources, and management support you will need to build that enterprise data warehouse. Do not try to complete the enterprise data warehouse prior to delivering anything.

Clay Rehm's Answer: Either method will work; however, the enterprise method is much more difficult in an organization of any size. In an ideal world, I would recommend the enterprise method. However, due to politics, timeframes, department missions, budgets, resources, etc., the enterprise approach most likely will not be completed in your lifetime! There is another and better approach - using concepts from both approaches. You actually use a bottom up approach but think globally and involve members from all over the organization. Start small but keep everyone involved through periodic meetings and communications.

Les Barbusinski's Answer: The proper and least expensive approach (at least, over the long run) is to build an enterprise data warehouse first ... then build distributed data marts that feed off it. This insures that a) proper infrastructures (e.g., database, MOM, ETL, business intelligence, operational reporting, Web portal, etc.) are implemented up front and utilized from "day one" rather than back-fitted once the marts are already in place, b) operational data is extracted and transformed once (rather than once for the ODS and once for each mart), and c) tools and technology are properly leveraged. However, this approach almost always fails... and I'll tell you why.

The single largest cause of DW/BI project failures is lack of sponsorship or buy in from the business units. DW/BI projects sponsored by IT - no matter how well architected or executed - usually end up as "shelfware" because the affected business units either perceive the finished product as irrelevant (i.e., it doesn't address a critical business need) or useless (i.e., it doesn't present the right information to the right people at the right time in the right manner). Put another way, the "build it and they will come" approach fails every time. Involving business management and end users in an IT-sponsored project doesn't usually help either, because failure carries no adverse consequences for the business unit participants (i.e., failure is an option).

The best way to insure that your DW/BI project is successful is to get a business unit (i.e., an individual department or a business function such as sales, operations, marketing or finance) to sponsor the project. They fund it, they run it and they own it. Personal reputations are at stake, and failure is not an option. But here's the rub: the business executive sponsoring the project will not give a damn about "enterprise" anything, will not see the need for "scalable" and "extensible" infrastructure and will absolutely refuse to pay for anything not directly connected to producing the analytics he/she needs. Poof! All your visions of capturing enterprise data by subject area, employing the latest real-time messaging technology, building an integrated reporting Web portal, purchasing enterprise-class UNIX servers, etc. go up in smoke. Now what do you do?

You build a data mart: a killer data mart - one that wows the sponsor, his people and, most importantly, his boss. One that gets adopted by the business unit overnight and begins generating tangible financial and operational benefits from "day one." One that gets noticed - other business units will want the same kind of benefits for their organization. But you're smart. You build the data mart in a modular fashion, with an enterprise architecture in mind. Extract, transformation and load processes are segregated for future incorporation into a MOM network. Normalized dimension and transactional data sets are created as a byproduct of the ETL processes for future inclusion in an ODS. BI functions are "wrapped" in Web services for future incorporation in an enterprise web portal. And so on. Over time, you slowly add new technologies and capabilities to the mart. Eventually, after you've built three or four successful data marts, you can sell senior management on building a data warehouse to integrate them all ... and realize new economies of scale.

The short version is that (as counter-intuitive as it seems) building data marts first - then integrating them into an enterprise data warehouse - is the most politically palatable approach ... and also the one that generates the fastest and greatest ROI. Hope this helps.

Chuck Kelley's Answer: If you are lucky enough to have total control over the dimensions, then either method would be suffice. However, 99.9 percent of organizations cannot control this, so the enterprise feeding the data marts is the most widely used approach. If done properly, it can deliver a significant ROI.

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

Don't have an account? Register for Free Unlimited Access