Back in the days of my youth, a rock group named the Who asked the timeless question, "Who are you?" In today's world of data warehousing, many organizations would be hard pressed to answer that question. While many have a burning desire to subscribe to a top-down, enterprise data warehouse identity, neither their business priorities nor characteristics will support this approach. Still others eschew this approach and charge down an incremental data mart path, oblivious to the inherent challenges and prerequisites therein. Before you begin your data warehousing journey, it is imperative that you answer the question: "Who are you?" This can only be accomplished by understanding the options and your organizational identity. This month's column will address the options, and next month's column will discuss assessing the strategy and evaluating your organization.

There are two basic strategies in use today, the "top-down" and "bottom-up" approaches. The "top-down" approach mandates the construction of an enterprise data warehouse first and then the distribution of subset data marts from that parent data warehouse. The "bottom-up" approach uses a series of incremental, architected data marts to build up toward the goal of the enterprise data warehouse.

Although the "top-down" strategy was favored in early initial enterprise data warehouse projects and is the most elegant design approach, high rates of failure for initial enterprise data warehouse projects have led the majority of current projects to the "bottom-up" approach.

Each strategy has its own set of strengths and weaknesses, and each should only be used where appropriate. Although each is viable in a suitable site, the misapplication of strategy can doom a project from the start.

The Pros of a "Top-Down" Strategy:

Inherently Architected ­ A "top-down" strategy delivers a data warehouse that is inherently architected. Every subset data mart that is created from that parent data warehouse stands to inherit this architecture, greatly easing maintenance.

Enterprise View ­ The enterprise data warehouse will allow the business to look at all activity from the "top down" and easily summarize activity up to the enterprise level.

Single, Central Meta Data Repository ­ The enterprise data warehouse provides a central meta data repository for the system, making the maintenance of the system much less complex than multiple repositories.

Centralized Rules and Control ­ The "top-down" approach ensures that there is only one set of data extraction, scrubbing and integration jobs or processes to monitor and maintain.

The Cons of a "Top-Down" Strategy:

Very Long Implementation ­ Enterprise data warehouses are typically built in an iterative manner, subject area by subject area (i.e., sales, finance, human resources, etc.). Even so, it typically takes 15 or more months to bring the first subject area to a production status. This is a very, very long time to maintain political and budget support in the face of ever-shifting priorities, emergencies and team members.

High Exposure/Risk ­ Enterprise data warehouses are inherently high exposure ventures. It is a prerequisite for success to have the sponsorship of the CEO and/or board of directors. At this level of exposure, there is little to no room for error.

High Level of Cross-Functional Management Skills ­ Enterprise data warehouse projects are inherently cross functional. IT managers are usually not highly practiced in the types of political skills needed to survive and prosper in this challenging arena of competing functional, geographic and organizational managers, directors and vice presidents.

Challenging Expectation Management Environment ­ IT managers are usually from an OLTP background and are poorly suited to the data warehouse environment where the user is paramount and the need for constant "selling" and "re-selling" of the project to upper management (to justify its never-ending delays and ever-increasing resource requirements) is coupled with the need for constant "selling" and "re-selling" of the project's unique "never-ending" and "always-changing" status to the team.

The Pros of a "Bottom-Up" Strategy:

Fast Implementation ­ Because incremental architected data marts are built to a tightly focused scope, they can usually be brought to production status in six to nine months.

Fast ROI ­ An incremental architected data mart can demonstrate value and return to the business much faster and provide a foundation for further investment by the business with a higher level of confidence in further efforts.

Focused Pain/Focused Team ­ One of the greatest management challenges in data warehousing is keeping the team focused on a deliverable scope. Incremental architected data marts are inherently focused on solving focused pain, thus limiting the trend for teams to expend efforts on areas that are not essential to the problem at hand.

Inherently Incremental ­ An incremental architected data mart strategy mandates a step-by-step approach to delivering information assets. This allows the team to grow and learn--low risk step by low risk step. Tools, technologies, consultants and vendors can be subjected to a "test and toss" process. Those that work can be retained for the next step; those that don't can be replaced, with a natural breaking point between incremental steps.

The Cons of a "Bottom-Up" Strategy:

Danger of LegaMarts ­ One of the greatest dangers in all of the data warehousing world is the creation of non-architected data marts. The advent of easy drag-and-drop tools has facilitated the urge to simply build an individual solution to a business need, with no regard for the overall enterprise architecture. These non-architected data marts become legacy data marts, or LegaMarts, and are infinitely challenging to integrate at a later date. LegaMarts are part of the problem, not part of the solution.

Challenging to Obtain an Enterprise View ­ While you are building incremental data marts, it is challenging to answer the "40,000 foot" questions about the entire enterprise. It requires more work to extract the answers and combine them from the individual sources than it does from an enterprise data warehouse.

Managing and Coordinating Multiple Teams and Initiatives ­ Incremental architected data marts are very popular to build in parallel. This can lead to management challenges in trying to coordinate the efforts and resources of multiple teams, especially in the areas of business rules and semantics.

Curse of Success ­ Incremental architected data marts are almost always burdened with the "curse of success." In these cases, the target users of the data mart are overwhelmingly happy, while wanting more information added to their data mart. At the same time, other homogenous user groups in the enterprise are clamoring for their own incremental architected data mart. This leads to political, resource and management challenges for the data mart team.

Next month -- Who Are You? Part II.

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