If you've got a few tangible, documented business requirements to tackle and you're reasonably sure that a new data mart will do the trick, you may be asking yourself how to strategically integrate the new data mart into your organization. Even though (as usual) the answer depends on the specifics of your situation, you'll probably end up with a data mart that resembles one of two proven types ­ DSS application data mart or departmental data mart ­ and the integration that goes with it. The definitions may help you understand the differences between these two types of marts.

Departmental Data Marts: The definition of a departmental data mart is a decision support database that solely belongs to a particular department or division within your organization. For example, the sales department may wish to create a decision support database containing sales data specifically. These data marts are fairly generic in functionality and serve as repositories of historical data for use by that department's personnel only. The design must be fairly generic as well, not focused on any particular functionality or process.

DSS Application Data Marts: DSS application data marts have a very different focus. They concentrate on a particular decision support process such as risk management, campaign analysis, head count analysis, etc., rather than generic utilization. Because of their universal appeal in the company, they also are seen as an enterprise resource. They can be used by anyone within the organization with a need for its analytical capability.

Each of these types of data marts results from the answers to three basic questions: what does it do, who is it for and who is paying for it?

What does it do? First and foremost, the answer to this question should be that it efficiently solves the tangible, documented business requirement. In addition, if the nature/scope of the requirement is clearly comprehensive, then a DSS application data mart is in order. If the nature/scope is limited, then a departmental data mart is probably better.

Tip 1: For departmental data marts, don't forget to determine whether other departments have the same requirement, i.e., would be interested in sharing the benefits and the costs. This may lead you to change the scope of the mart.

Tip 2: For either data mart type, manage user expectations. Make sure that they understand what the data mart will and won't do. Famous last words: "Our new data mart will answer all our questions."

Who is it for? Although the roster of users who access the data mart is important, this question goes to the politics of the situation and performance-based compensation. The real question is who will ultimately benefit the most from the data mart's success. If the answer is the business analysts and executives of a single department, then the data mart should be departmental. If the answer is the folks at many levels throughout the organization, then make it a DSS application data mart.

Tip 3: Once you've identified whom it's for, invite them to be the project sponsor(s). If you can't sell them on the role, then consider delaying the implementation until you can; because if they won't fight for the project at the start, they may fight against it later.

Who is paying for it? Although budgeting practices differ widely and IT departments often function under their own budgets, you should maximize the association between costs and benefits. If only one department is willing to cover the costs, a departmental data mart is needed. If the budget sponsor(s) have overall or inclusive responsibilities or include many departments, then a DSS application data mart is the right one to build.

Tip 4: If the senior project sponsors don't have budget authority, consider whether the ultimate benefactor is actually higher up in the food chain.

Once you've answered the three questions, you should compare the answers to the inherent features of each type and evaluate which approach is needed. Keep in mind that there are pluses and minuses for each type of mart (see Figure 1). Go into the project knowing the shortfalls of each type.

Departmental Data Marts
Pros:
  • The users are usually very involved in the design and usage of this mart. You have a good chance of delivering what the department wants.
  • You can get good funding since the department owns this mart.
  • Most IT projects are funded this way - one department paying for its own system - so it is easy for the department to build a business case.
  • The department controls the mart and, therefore, can make it perform almost all of the department’s very proprietary analyses.
Cons:
  • Performance issues due to the data mart not being optimized for any set of queries - or worse, being optimized for some queries that cause performance problems for other queries.
  • Redundant queries run on different data marts throughout the organization. (The result sets from these may not be consistent. This is somewhat mitigated by having the data warehouse feeding all marts, but it is certainly not guaranteed that two marts will produce the same numbers.)
  • Minimal sharing of findings between departments.
  • No desire to support an enterprise view of the information.
  • Difficulty in getting funding for the data warehouse (an enterprise resource).
DSS Application Data Marts
Pros:
  • It is possible to create standard analyses and reports from these marts.
  • An analytical functionality is created only once and is used by the business community.
  • The data mart is easy to tune and capacity is predictable.
  • There are many vendors today offering specific DSS applications that can plug into your data warehouse environment, thus speeding up the implementation of analytical applications.
Cons:
  • It may be difficult to customize the views or queries enough to satisfy the diverse set of users.
  • Funding must come from an enterprise source rather than a single department.
  • It can be hard to get the business community to agree on the overall design of this application.
  • Some of the analyses may be suboptimized due to the nondepartment-specific nature of the mart; that is, the mart may satisfy only 80 to 90 percent of a department’s needs because it is an application for the entire enterprise.

Figure 1: Inherent Features of Two Types of Data Marts

Departmental data marts usually satisfy departmental requirements for the departments that pay for them. DSS application data marts usually satisfy requirements for multiple departments or the organization as a whole and are funded within enterprise-level budgets. Neither type of data mart is necessarily better than the other, although each has its own ramifications. Each organization has its own unique cultural, political, technological, budgetary and human resource issues. In practice, you may end up with a combination of both types of marts because you need to tailor your solution to your situation.

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