The issue remains controversial. While IT departments might prefer the former on the basis of "let's take the trouble to get it right first time, and not leave anything out", the hectic pace of business life usually militates towards the sprouting of locally-owned, "quick win" data mart flowers, irrespective of whether any data mart can communicate or exchange with any other, or even an enterprise data warehouse built elsewhere.
The bottom up approach
Wolfgang Martin, former senior vice-president, application delivery strategies, at Meta Group, advises against big bang deployments. "Enterprise data warehouse is not big bang at all," says Martin. "You build it data mart by data mart, slice by slice, iteratively."
By building a series of data marts to an agreed architecture, the enterprise data warehouse can be assembled slice by slice, until it is complete enough to regard the data marts as subsets of the now much greater whole. Architecture is key to success, as the data marts must not be built in isolation. Users need therefore to design data marts in the knowledge that each will eventually form part of a larger enterprise data warehouse.
Such an approach can prove attractive to businesses. Each data mart can be implemented within six to nine months. Each can tackle an identifiable business problem making it possible to calculate returns on investment (ROI). The approach also offers a valuable learning curve for the build team, who can test out products and processes until they get it right.
But there are several disadvantages. Since they are so easy to implement, users may be tempted to save time by building a data mart that does not comply with the business' overall enterprise data warehouse strategy. This will make the offending data mart instantly obsolete.
Martin says the only time when a standalone data mart is justified, is if it solves immediate - and temporary - pain. "If the business benefit of the data mart comes from solving an urgent problem, that's okay - if you're prepared to throw it away afterwards," he adds.
Building a temporary data mart may also give a valuable insight into corporate business intelligence problems overall, and how to solve them. But, he warns, make sure users know if their data mart is to be temporary.
"Agree before you start that it will have to go," Martin says. "If you build it, and then switch it off without telling them, you'll be killed."
Even when a bottom-up strategy is built with the enterprise data warehouse in mind, it is more difficult for IT - and the data mart users and sponsors - to see the big picture affecting the whole enterprise when only modelling a part of it in a single data mart.
In addition, if several data marts are built simultaneously, albeit to the same enterprise data warehouse blueprint, there is a resource and project management implication of multiple teams and parallel build. Finally, a successful data mart can be a problem in itself - happy users will want more and more bells and whistles, not caring that other departments are still waiting for their first data mart.
The opposite of starting with individual business issues and expanding up the organisation hierarchy is to start at the top. A top down enterprise data warehouse and a subset data marts strategy is "the most elegant design approach", says Doug Hackney of business intelligence systems specialist, the Enterprise Group ( www.egltd.com). He says that such an approach would vastly ease maintenance, summarisation, metadata management and extraction, transformation and loading (ETL) of data.
But which of these opposite approaches works? In a nutshell, if the business pain the data warehouse will solve is felt at the highest, most enterprise critical levels, and the CEO wants it solved, but can afford to wait for an enterprise data warehouse, go for top down. If the pain is hitting lower down the organisation, time is of the essence, and quick ROI is key, go for bottom up.
Reasons for failing
Failure probably will not come for technical reasons, but political ones according to Hackney. "Enterprise data warehouse projects are inherently cross-functional. IT managers are not usually highly practised in the political skills needed to prosper in the sometimes bloodthirsty area of competing functional, geographic and organisational [fiefdoms]," he warns.
Another point to consider is that the enterprise data warehouse must map to the structure of the company. "If the business is organised into stove-piped functions that don't exchange data, [trying to build an enterprise data warehouse] will draw you deeper and deeper into the problem," warns Martin. "Business intelligence systems must be related to the business process - and to business performance management."
What this means is that any business department that is totally isolated from the rest of the business "might as well be outsourced", Martin argues.