Databases Reference
In-Depth Information
Both the bottom-up and top-down approaches have developed strong
advocates, and both have hundreds of implementations. For each, a few are
wildly successful, many are moderately successful, some struggle, and a few
fail outright. One of the biggest hurdles in defining an architecture is that
many people become entrenched with one approach and are unable to look
objectively at the overall situation. You want to involve intelligent, strong
people, but they must still be able to consider alternatives to make the right
decision for the organization.
Established industry approaches provide the benefit of the culmination of
many years of experience. However, several common mistakes are made when
adopting the approaches described here.
Common Mistakes Adopting the Top-Down Approach
It is too easy for IT to fall into their comfort zone and perform traditional
entity-relationship modeling without frequent, ongoing communication
with the business.
The project can get caught up in foundation work with no line of sight to
any real business purpose.
Organizations can build the data warehouse foundation with no end user
deliverable. The project can lose funding before finding a worthwhile
business problem to solve.
It is too easy to build non-integrated data marts. These marts are tailored
to different business needs and the data is often transformed differently
for each mart. This creates multiple, usually differing versions of what
should be the same data.
Building an entire data warehouse prior to delivering any business
intelligence applications takes too long and costs too much.
Common Mistakes Adopting the Bottom-Up Approach
Building dimensional data marts that do not integrate.
Too often, projects pull only data needed to support a specific report or
target.
Quickly populating the data marts without a sustainable set of processes
to maintain them.
Abandoning all system development rigor to move data faster.
Moving data into dimensional structures and then asking whether this
would be useful. This is often done with frequent iterations and without
careful data analysis and an understanding of real business needs.
