I would add to this that a company may want to hire an independent technology expert to help make the decision. I've witnessed on many accounts non-technology people making technology decisions that don't serve the organization.

Often a third-party technology person will avoid several of the items listed, for example, falling in love with the salesman.

A third party techology person will know the current network technology of the organization and can differentiate between the different database products that are being presented.

I've served in this capacity on a volunteer basis for a local company and believe that I chose the software program they were initially interested. Having a third party confirm their decision helped them feel good about the decision and reinforced the commitment to the software from management and the IT department.

Where does one find an independent technology expert? My org is in the midst of this situation, and an impartial voice would be very valuable.

Failure to "Reverse Engineer" the database

Non-technical managers MUST educate themselves on the essentials of database-centric systems. As a starting point, I suggest my mentor's book on the topic: A Manager's Guide to Database Technology: Building and Purchasing Better Applications by Michael R. Blaha

Databases can't hide. They're fundamentally "open" technology, and can't "black out" their quality (or otherwise) from a skilled pratitioner. With suitable tools and practitioner expertise, purchasers owe it to themselves to obtain an independent assessment of the system caliber, before investing precious money and time into doomed products.

The technique of "reverse engineering" offers such a method. I've distinguished excellent and inferior software by examining the underlying database structure. I look at table names. Index coverage. Relationships. Constraints. Coherence, and consistency, and componentization. I use experience to imagine how a skilled developer would use each database construct to provide each screen, each report and each data-extract capability. Some database structures make it *really* easy to build nearly any imaginable feature. Frequently, I've found technically inferior database structure and content in supposedly "big-name" products. After many years and many evaluations, it's inescapable:

Ugly database structures always product ugly apps. Buildings are no stronger than their foundation. Databases are the essential foundation on which all apps depend. Fund-raising database apps are the life-blood of not-for-profit organizations. When donor databases are fragile, error prone, difficult to use, teach, learn and extend, the programmers have hopeless challenges to surmount, and software quality suffers.

Sadly, the overall caliber of software practice is frighteningly low. Most programmers are highly-paid amateurs. (Consider that your 747's control systems were probably developed by somebody with no more computer training than yourself, just some self-taught experiements and a few copies of "Programming for Dummies" and "Teach yourself Technology in 21 days.") Most database structures are pretty bad. Database programmers frequently have little (or no) training or skill developing proper database structures, implementing those strutures, and exploiting those structures. These inferior practitioners create database structures doomed to fail. Features are difficult to extend. Screens are difficult to use, slow to navigate, and frequently under-accurate.

Anyone can buy the tools. Anyone can read the names of tables and columns and relationships. Anyone can see the consistence (or otherwise) and get the general ideas that "The Whole Thing Hangs Together", or "It looks like a dog's breakfast of different techniques, different styles and general sloppiness." The more subtle refinements require training and experience to really understand; that's why one spends the up-front time and money to get informed before committing one's organization to a huge investment on which the entire organization's long-term future is dependent.