DM Review Published in DM Review in October 1998.
Printed from

Building a Business-Driven Data Warehouse

by John Onder  and by Todd Nash

Summary: The key principles outlined in this article will help you implement a top-down business-approach data warehouse that will add real value to your organization.

All too often the purpose of building a data warehouse to allow business people to get timely answers to business questions is overlooked in the development of that data warehouse. For a technology that can have a dramatic impact on a business, many data warehouse architectures miss the mark and rarely achieve the business goals initially anticipated. The cause: rarely do the individuals responsible for and involved in the development of the warehouse take a true "top-down," business-driven approach to building the data warehouse.

The top-down, business-driven approach is as much a philosophy as it is a methodology. Over the past years, consultants have seen it all--from technically superior projects that are met with indifference to technically controlled projects that are met with disdain. We hope to share our real-life experiences and a practical approach to help your organization succeed.


Within every organization that is considering a data warehouse development project, many of the same frustrations exist. These common themes are true business opportunities that a data warehouse can assist in achieving. Whenever one or more of the following is heard, it is a signal that a true business reason exists for building a data warehouse:

  • We have all the data in our systems. We just need access to it to make better decisions for running the business.
  • We need an easier way to analyze information than training our business people in SQL.
  • Our people cannot do their jobs to analyze data if the majority of their time is spent gathering the data, joining tables, formatting reports, resolving data inconsistencies, etc.
  • Information access, analysis and distribution are critical to the current and future survival of our business.
  • We could save millions and point out opportunities if we could identify trends in our business.

One or several of the above should be the driver for development of a data warehouse. An equally important business thermometer to validate the viability of a warehouse is the business value to be realized from the implementation:

Operating Efficiency:
Will the organization save money?

Increased Revenue:
Will the organization make more money?

New Markets and Products:
Will the organization be able to develop and support the future direction of the business?

Improved Customer Service:
Can the organization service and educate its customers better?

Competitive Advantage:
Will the organization be able to meet or exceed competitor capabilities.

Data Warehouse Crossroads

When the business criteria is evident and a data warehouse is thought to be the correct technology to assist the business in achieving its goals, the next step organizations face is what approach should be taken to design and implement a data warehouse that meets its expectations. This is what we have coined as the "data warehouse crossroads." It is one of the most critical junctures of any data warehouse project. The direction taken at this point will either steer the project to a data warehouse application and environment that is understood, embraced and used by the business or a technology-driven project that doesn't meet the business expectations or needs and is usually met with a collective business yawn.

The following are some of the common dilemmas and questions facing an organization starting development of a data warehouse:

  • Do we buy some user friendly tools, replicate our current operational database and turn the business users loose?
  • Do we take our current data, select the pieces that users want and place it in a separate structure for user access?
  • As a first step, let's start with evaluations and purchases of the different technologies (databases, access tools, etc.).
  • Just build it and they will come--we know what the business needs.
  • Let's start with the enterprise data warehouse and solve all the business problems at once.
  • Do we try to understand the business problems and provide a data and technical architecture based on business needs?

The last item is the approach we have seen to be the most successful. Invest the time to really understand what the business wants and needs. Get below the surface of obvious information needs. Question everything. You must approach the development of the data warehouse and think like a businessperson.

It is important to realize that we do not intend to minimize the importance of selecting a proper technology, but we strongly believe such decisions should be driven by and performed after gaining a solid understanding of the business problem to ensure the involvement of the business. This business-focused approach is possible and successful for a key reason--the technology is proven and it works! Many organizations are operating technologically successful data warehouses. Additionally, the vendors have spent millions in R&D; to meet the needs of the marketplace. If the initial focus of your project is based on a technology "bake off," you are headed down a path that is usually unnecessary, ends with an uninvolved and disinterested business sponsor and, even worse, the business probably has limited buy-in and ownership of the project.

The Four Key Components

Any approach to developing a business-driven data warehouse should revolve around four keys: the organization structure, change facilitation, expectation management and a proven methodology. Each of these components has a distinct purpose but must work with the others to support the guiding principles and philosophy previously mentioned.


The overall structure of the business support and management team should mimic the inherent structures of the business. For most organizations, two groups are key to the success of the project--senior management and "working" management. These two groups represent the strategic and tactical perspectives, respectively.

Specifically, three key organization components need to be put in place:

  1. A senior level business sponsor/ owner must be identified. This individual must have a respected voice within the organization and the ability and authority to lead the project and make decisions. His/her role is to be the overall project director, leader, champion and evangelist.
  2. A steering committee consisting of a manageable number of senior business executives. This cross-functional group sets the longer-term direction of the data warehouse, decides the priority of applications and has project approval, funding and acceptance responsibility. Equally as important, this group must proactively communicate to the organization as a whole, and to its direct reports involved in the project, the importance of the warehouse to the business.
  3. A user group that contains a select group of "working management" that will be involved in the details of the project. From requirement definition through testing, this body of individuals must be highly knowledgeable about the business, goal oriented and analytical in nature.

In many organizations a common complaint is business-user apathy or unresponsiveness. It almost comes to forcing involvement. This should be a very large red flag. Either the guiding principles to justify a data warehouse project were not met or the business objectives have changed. Whatever the reason, building the warehouse in a vacuum will not have a successful conclusion.


If the data warehouse is going to have the significant business impact anticipated, some level of change to the way the business operates must occur. Business users will have the ability to interact with the data to identify and provide value quickly, more easily and with more flexibility. This type of change does not happen immediately after you roll out the application. There are many areas to address the transformation of current procedures to realize the ROI of your investment. These include:

  • How should the organization as well as roles and responsibilities of the business users in the area impacted change?
  • Is tracking the return on investment important to the organization and the future of the warehouse?
  • What type of communication must occur for the warehouse to be successful?
  • Do we have the proper training program in place so that the users understand how to best achieve the expected business results?
  • What procedural changes can best leverage our investment?

The ability to identify, plan for and manage change will be the difference between success and failure.


The data warehouse is too often viewed as the "silver bullet" that will solve all the problems of the organization. Everyone reading this article should realize data warehouses are good at some things and not good at others. The key is scope for success, educate and communicate. If the business receives what is expected, when expected, the probability that your data warehouse will be viewed as a success will be greatly enhanced.

Education, both formal and informal, is important to level the playing field and set a common foundation of project knowledge across the organization. The business users must understand the intent and purpose of data warehouse technology. They also need to know what business functions data warehouse technology is good at supporting and what functions are best left to other technologies. The business users must also have a full understanding of the business scope, the target audience, the time frame for roll out, the information scope, etc. An educated, informed, involved business user is, in the end, usually a happy business user.

Proper expectation management will result in "good news often in the project and bad news early." These systems are usually heavily scrutinized. In these projects, the organization needs to hear good news often to show progress. On the other hand, when there are areas for concern, the organization needs to understand the issues and have alternatives and recommended actions to turn issues into opportunities.


The fourth key component of our approach is the methodology and business tools utilized to execute the project. This area of the methodology must be clearly understood by the business people involved and tie directly back to the goals of the data warehouse. The following simple tools and methods have been very successful in ensuring the project stays on track with the business objectives:

1) Requirements Gathering

  • Performance Measure-Based Requirements. Business performance measures derived from the strategies, goals, objectives and direction of the business are the absolute key to the business success of any data warehouse. It helps the business people understand and document the goals and deliverables of the warehouse, define the information the business people need (not what they currently have) and facilitate the modeling design process.
  • Enterprise Requirements Gathering. Even if the initial scope of the data warehouse is limited, an understanding of the enterprise-performance measures can provide many short and long-term benefits including positioning the data warehouse for growth and flexibility as well as helping plan and prioritize future business direction.
  • Cultural Requirements. Who are the stakeholders? What are the behind-the-scenes drivers of the business and project? What are the politics of the organization? What type of technical and analytical skill levels exist?
  • Technical Requirements. What are the current architectures, capacities and contracts? What is the planned future direction?

2) Scope for Success

Identify a business priority application with a manageable scope to get it done quickly and supply value to the organization. Remember data warehousing is an iterative process of supplying business value. Prioritizing and planning the scope of applications to be rolled out over time will set expectations and ensure continual business focus.

3) The Business Conceptual Design

This is a very simple pictorial representation of the technical architecture and the database design. It helps the business people start to complete the picture, understand how all the pieces fit together and understand their role in the project and the use of the warehouse.

4) Meta Data

Business terms for business people. There will be several layers of meta data within the applications. Providing the business users with a simple interface to the meta data will be essential for understanding the data (e.g., HTML via a Web Browser).

5) Sample Queries and Reports

Develop queries and reports using spreadsheet software, word processing software or whatever gets the idea across. Develop five to ten "standard" queries/reports that will be delivered with the data warehouse. Get the targeted user thinking analytically.

6) Quick Reference Guide

This tool acts as a "cheat sheet" for the business user. In the early days of implementation and roll out, it provides the user one place to go for answers to many of their FAQs.

7) Training

Training needs to address several areas of the warehouse including end-user tools, data models, application, architecture and the business-user role. This training facilitates how a business user will be transformed into a business data analyst.

Pitfalls and Lessons Learned

Over the years of working on, observing and discussing data warehouse projects with our colleagues and clients, many recurring themes have emerged. Most of these themes are really the pitfalls of taking a purely technical approach. Make their pitfalls your lessons learned.

  • The business, not IT, determines if the data warehouse project is a success. No matter how technically "perfect" the project, it is not a success if the business needs are not met.
  • A multi-disciplinary project team is essential: business (working management and up), IT (data warehouse and operational system representatives) and project management.
  • Do not over-complicate the implementation. Often the architecture is just too complex to easily understand and maintain to keep pace with the business changes.
  • Do not take a technology strategy that is independent of or radically different from the business direction and culture.
  • Do not attempt to solve all your information access and analysis needs within the scope of one too-large-to-manage project.
  • Replicating operational data without consideration of the true information requirements will result in a warehouse of limited use and capabilities.
  • Never underestimate or minimize the importance of business participation, understanding, communication and hands-on training.

Remember, developing data warehouse applications from a top-down business approach is more than a methodology. It is a philosophy. The key principles outlined in this article will help you implement a data warehouse project that not only meets the basic needs of your organization, but adds real value to the business.

John Onder, a partner in Chicago Business Intelligence Group (CBIG), has extensive experience in all facets of providing information technology services, business reengineering, system assessment and planning services. He has in-depth expertise in business planning and practical implementation of business intelligence and data warehouse applications across many industries. CBIG is a full service, vendor-independent DW/BI consultancy staffed by senior level professionals. Onder can be reached at or (773) 477-8783.

Todd Nash, senior manager of data warehousing at Sysix Technologies, is recognized as a thought leader in the area of data warehouse business architecture requirements, design and implementation in the financial services, health care, reinsurance, managed care and pharmaceutical benefit industries. Nash can be reached at

Copyright 2005, SourceMedia and DM Review.