When evaluating database engines, there is a temptation to believe the hype of the terabyte-capable vendors--that performance is measured in speeds and feeds, that your database engine should be the fastest, the biggest, the latest and greatest. But before you sign that purchase order, you should give some thought to what high performance means to your organization.

For some, "high performance" is undoubtedly translated as a sub-second turnaround on a query. But what if you never had access to that information before? Isn't a five-minute turnaround on information that was previously unavailable also high performance if that information delivers business value?

Although many on the IT side are searching for the ultimate testosterone high ("I can do my TPCD# running on a SUN Sparc station 550...."), how to provide value-based information to users should not be a hormonally influenced decision. Nor should it be an issue for technologists alone.

When selecting a database, an organization should refer back to the age-old adage--aim for quality rather than quantity. What data goes in is often more important than how fast you can extract it.

Ensuring that the right data goes into, and can be extracted from, the database involves getting business users involved in its selection. The demand for high-performance databases arises out of business users' inability to find answers to their questions with the data currently available. Therefore, business user requirements, not techno-guru wish lists, must drive the process of selecting the most suitable database.

Granted, the typical business user may not be well versed in the latest techno-terminology or fluent in database measures, but they know what information they need to do their jobs. Users also often know where information is buried within the organization or which sources must be combined to derive the answers they need.

One way to ensure that the database selected can deliver is to actively involve the business users in its requirements-gathering process. The best way to do this is to conduct impartially facilitated, cross-functional workshops. There are several approaches you can use for these requirements- gathering workshops. Many of them employ team building and brainstorming exercises, but the really good ones empower the participants to find answers for themselves instead of directing them to a predefined conclusion.

A cross-functional workshop is also an appropriate setting for matching the organization's goals and objectives to the database's performance features. The performance of the database ultimately depends on how well its data is aligned with the business requirements--or strategic goals and objectives--of the organization. In the end, the organization needs a database that contains and provides information that enables sound decision making.

This information can only be useful, though, if it is viewed as supporting a series of High Impact Processes (HIPs) that span departments. HIPs are those processes that the business must execute to achieve success.

It is precisely these HIPs that drive the data needed for the new database. Therefore, HIPs for every business function that the system will support must be analyzed. The data flowing into and out of the HIPs becomes the data requirements for your database. Also, because this data will often bridge departments, HIPs must be defined with the participation, guidance and buy-in of all individuals and groups who will use them. Having a database that supports the HIPs and is supported by the organization increases the chances of realizing tangible business benefits from the investment.

There is another danger to selecting a database engine based simply on its feeds and speeds. A pure technical evaluation of database engines can be dangerous. Product enhancements and features aren't everything when functional factors don't match. It is essential that you pick a "winner," a database that supports the functional needs of the business and can be adequately supported in your environment.

When evaluating the various products available, consider the following:

  • Technical Support: Will the database vendor provide technical support for its engine? If not, does my organization have the internal capability to support it?
  • Staffing: Will I be able to recruit and retain the technical talent to support this database? Will I be able to afford them?
  • Functional Enhancements: Is this database vendor making a significant investment in the development of new functions and features for their product?
  • Financial Stability of the Company: Is this company profitable? Are they in danger of being acquired? Does my CFO think this is a good company to do business with?
  • Market Share: Does this company maintain a significant share of the market? Or is it a niche player that I should worry about?
  • Partnerships: Partnerships are a critical part of business today. Does this company maintain value-added strategic partnerships that can help me with my business problem?
  • Satisfied Customers: Most importantly--do they have satisfied customers? And can I talk to them?

A high performance database engine must be defined as one that adds value to business operations and has a significant positive impact on the bottom line. Wouldn't you rather get meaningful information quickly than receive the results of a possibly pointless query in record time? The question should be what are we doing with the data, not how fast does the data come to us.
The key to selecting a database that performs to your organization's optimum expectations rests in the answer to this question: Which database engine will provide the right information to the right people at the right time?

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