But today's librarians aren't restricted to card-catalogs to find information. Now, they're using modern enterprise search platforms to sort through vast stores of Web data. And when tech-savvy librarians evaluate search technology, they do a lot of research.

At least, that was the case at the Berkeley, Calif.-based Librarians Internet Index (LII), the publicly funded organization that manages a collection of librarian-recommended -- and vetted -- Web links. The group maintains a MySQL database with more than 20,000 records that anyone can search via a free Web site. But a few years ago, dissatisfaction with LII's old search engine was growing, according to former director Karen Schneider.

It was difficult to browse the LII site, and the old search engine wasn't taking advantage of the carefully maintained metadata tags for each entry. So the organization began evaluating better options, engaging a search consultant and real users to test different platforms. LII ultimately chose El Segundo, Calif.-based Siderean's Seamark Navigator, a search and information access platform with relational navigation technology that leveraged LII's metadata. Schneider learned a lot along the way, too.

"People think that because they can do a Google search, they know search technology," Schneider said. "But there's a lot that people don't understand about choosing a search tool."

This sentiment is echoed by Susan Feldman, research vice president with Framingham, Mass.-based IDC Research. Many organizations still think of search too narrowly -- as just searching documents or Web sites -- and are not doing their homework before choosing technology, she said. So both LII's Schneider and IDC's Feldman shared their expert tips for evaluating enterprise search platforms.

1. Know the possibilities, then develop requirements

It's critical to understand what's possible with search engine platforms today, Feldman said. A search engine is only one potential application.

"The biggest mistake I hear [from organizations] is, 'We only need a search engine,'" Feldman said. "Very often they will get a simple search engine and then realize that they screwed up, because they are unable to tune it. Usually, they at least want some level of categorization to enable browsing."

Other search applications include guided navigation, browsing tools, text mining and business intelligence "light" functions. Once they know what's possible, organizations must consider short- and long-term requirements, Feldman said, offering some questions to get started. Will search be internal, customer-facing or both? What are all of the information tasks that could be optimized with search platform technology? What other departments might use search -- or already are using some kind of search technology?

2. Consider the costs of poor search technology

When making the case for purchasing technology, it's helpful to have an idea of how much money is currently wasted looking for information, Feldman said. For example, recent IDC research found that the average knowledge worker spends about 9.5 hours a week looking for information. Multiply that by the number of knowledge workers in an organization, mash it up with salary figures -- and that's just a starting point for how much money is wasted on poor information retrieval. Add to that the costs incurred when workers can't find information -- such as losing a sale or having to recreate a document -- and the costs rise further, Feldman said.

3. Investigate integration requirements, information types and sources

Once users have successfully searched and retrieved information, it's important that they be able to take action, Feldman said, and that often requires integration with other systems. On a customer-facing Web site, that can mean integration with transaction systems, so a user can place an order after finding the product he needs. For corporate searches, it may mean integration with a business intelligence application, content management system, document repository, or access-control system. Companies should also consider the varied kinds of content that search platforms may need to handle, Feldman said, including documents, customer records, transactional system database records, rich media, and third-party information sources.

4. Delve into implementation and maintenance requirements

In addition to understanding the technical requirements, organizations should pay close attention to a search vendor's implementation process, timeline and work that may need to be done internally to support the new platform, Feldman said. For example, some platforms may require a part-time or full-time administrator. Other technical questions to consider, she said, include: How scalable is the platform? How much information will it need to search -- and how quickly is this volume of data growing? What are the response times like -- and what's acceptable? How will response times change with more, or different, kinds of data in the system? How is content crawled and indexed?

5. Focus on flexibility

Relevancy rankings in search engines determine the order in which query results are returned -- but the definition of "relevant" can vary. So Feldman recommends evaluating whether, and how, relevance rankings can be customized to fit unique needs. That was important to LII, too.

"Now we can adjust the weight of each metadata field," Schneider said. "In tracking the search logs, we might find we have too much weighting on a given field, so we might drop that."

Organizations may also wish to consider whether they'll want multiple interfaces or varied taxonomies, customized to different kinds of users.

6. Scrutinize security

Information security and access controls are huge issues to consider when evaluating search platforms, Feldman said. For example, how will a platform restrict results so that users see only information they are authorized to see? Can the search platform inherit document-level security from other systems? Will platforms interface with existing access control systems?

7. Evaluate platforms with real-world users, queries and data