Almost everyone involved with data warehousing faces the big question from time to time: "Am I on the right data warehouse platform?"

Rick Burns, vice president of engineering, and Richard Winter, president, of Winter Corporation offer tips on how to choose the right data warehouse platform.

This question is asked when:

	An organization's growing requirements trigger a need for a major new investment in the platform
	There are changes in the executive suite
	Performance or availability problems are not easily resolved

Many people dread the big question, because it is never easy to answer and the process of answering it is complex and fraught with risk. When you face the question, you will want to avoid certain pitfalls and consider some techniques we at Winter Corporation have found helpful.

Take a fact-based approach to platform selection
Potential failures can be traced to a common cause: lack of a fact-based, engineering-oriented approach to evaluating database products.

This approach is grounded in a crucial tenet of platform selection: Success hinges on the ability to derive quantitative scalability requirements from the project's business objectives.

Remember that data warehouse platform requirements are about the future as well as the present. When you select a platform, you want it to be the best choice for the next several years. That means you need to project your requirements into the future, taking industry trends into account.

The platform differences that matter are the ones that affect the prospective business outcomes. Focus the evaluation on revealing these differences by means of facts. Directly link the ones that matter most to the quantified requirements and then to the business objectives. Not only will you focus your team's energy on the technical issues that matter most, but you will also end up with a recommendation that makes sense to your business sponsors because it links your choice to their business interests.

Once you have developed the technical requirements, you have the information in hand to qualify bidders. You can then ask your short list of vendors to propose configurations that satisfy the specified requirements. Additionally, you can—and should—insist that bidders prove their proposed configurations will meet your needs.

Get proof before you commit
Proof can come in many forms. The best proof is a convincing demonstration of product performance and scalability through a full-scale benchmark using your queries and your data. While you are testing, do not forget to test the proposed availability solution.

If you cannot conduct a benchmark (and many times circumstances preclude one), other types of proof can be obtained. Your own experience with the database products on similar projects is very valuable. Product references from current business users (i.e., detailed explanations of how other users solved similar problems at similar scale) are also helpful.

The softest, but still quite useful, proof consists of detailed architectural explanations by the vendor of how the product handles specific queries or solves specific scalability problems.

Invest the time to ensure a big payoff
In short, an effective product evaluation strategy will:

	Quantify project requirements by assessing all of the dimensions of scalability as they relate to your business objectives
	Provide a comparison of product capabilities to quantified requirements
	Require proof

This strategy will avoid mid-project scalability surprises, provide a basis for comparing proposals from different vendors and allow you to pick the right platform to meet your specific project needs.

Despite the clear benefits of these product evaluation techniques, companies often short-change the evaluation process in the face of time and budget constraints. We have seen organizations invest tens of millions of dollars in a new data warehouse, only to have it fall immediately into disuse. Why? The vendor never had to commit to specific database performance goals, because the engineering requirements were never quantified during the evaluation.

We have seen other projects canceled after hundreds of labor years of effort, because the selected database, which worked well at proof-of-concept size, could not scale to meet the data volume and workload needs.

The lesson is clear: A modest investment in an empirical, engineering-oriented evaluation approach pays off handsomely in lowering project risk and ensuring a scalable solution that meets business-critical requirements. T

Why data warehouse evaluations fail When a data warehouse evaluation fails, it is usually because the evaluation has succumbed to one of these problems: > The project team fails to quantify the impact of business objectives on data volume, data complexity, user population, query volume, query complexity and data latency. These are dimensions of scalability that can potentially strain system performance and affect business-critical operations. > The evaluation does not detect that the products or configurations being considered cannot meet the long-term business requirements of the project. This leads to unanticipated and costly upgrades, or worse, the inability to meet key project objectives. > Product configurations are not comparable, so price comparisons are meaningless. > The evaluation does not lead the bidding vendors to commit to solving a specific business problem, leaving the evaluation team with little or no leverage. > The evaluation does not elicit meaningful information about specific product capabilities or product directions. —R.W. and R.B.

Richard Winter, president, and Rick Burns, vice president of engineering, of Winter Corporation lead a consulting practice focused on the technology, architecture and engineering of large-scale data warehouse platforms and solutions. They conduct platform evaluations, benchmarks, architecture studies and engineering analyses, and they teach as members of the faculty of The Data Warehousing Institute.

Photography by Wayne Smith

Teradata Magazine-March 2008