Jan
I recently purchased a copy of How UK academic libraries choose metasearch systems from Emerald Insight. I was reading the article on my way to writing a review of it when I was struck by this statement:
Advice comes from successful, as well as unsuccessful implementations. One of the most common pieces of advice is that libraries should remember to treat metasearch as a service, not a product, and to ensure that there is adequate post-installation vendor support.
What struck me was that the statement, which seemed so obvious to me, was deemed important enough by the authors to state explicitly. Of course, federated search is a service. Whether or not you host federated search on your own servers with your own staff managing the server hardware, software, and application there’s plenty of service that someone will have to perform, and it’s on an ongoing basis. Off the top of my head, here are some service aspects to federated search:
- Building connectors - the more work that goes into building connectors the better the search experience
- Monitoring/disabling/re-enabling connectors when sources become unavailable and when they come back
- Updating or rewriting connectors when sources change their search interface
- Updating the application when the vendor provides new maintenance or feature releases
- Customizing the application to suit your needs
None of these tasks are easy. Each requires vendor support or time from your staff.
I wrote an article, Federated Search: 10 unrealistic expectations, that included two important considerations related to service:
- Federated search is simple to deploy and configure, and it requires no maintenance. Federated search is complex software. Except for hosted solutions, expect a system administrator to spend time installing software, upgrades, and patches, not to mention spending time studying system requirements, installations steps, and performance considerations. The software work may be related to the vendor’s product, to the server’s operating system, or to the web server. Problems may also crop up related to storage, user load, or network traffic.
- It’s easy to create and maintain my own connectors. Building connectors, assuming the vendor even supports this functionality, is complicated and time consuming, especially if you want the connector to work well with fielded search and with the quirky syntax of some sources. You’ll have to learn the connector language, which will have a steep learning curve if it supports sophisticated features. You may have to deal with authentication, sessions, cookies and other surprises. Plus, you’ll need a way to monitor your sources, if the vendor doesn’t provide a tool for this, so that you can rewrite connectors when a content provider suddenly changes its search interface, which happens more often than you think. Read What is a connector? to gain an appreciation for the hard work that connectors do.
The “UK academic libraries” paper I quoted from in the beginning of this article cites three articles that mention the product vs. support theme. I’ve tracked down the articles and the relevant references within them. Here they are. The emphasis is mine.
The Truth About Federated Searching
Federated searching is software.
Reality: It certainly is software, but it’s best consumed as a service. A federated search engine searches databases that update and change an average of 2 to 3 times per year. This means that a system accessing 100 databases is subject to between 200 and 300 updates per year—almost one per day! Subscribing to a federated searching service instead of installing software eliminates the need for libraries to update translators almost daily so they can avoid disruptions in service. (Translators convert search queries into something that can be understood by the database that’s being searched.) Without frequent updates to these translators, entire databases can become periodically unavailable for searching. It’s unacceptable for a database subscription that could cost a library $10,000 or more per year to be offline for any amount of time.
Federated Search at the Intel Library
Federated Search is more of a service than a product. It depends on many factors that can change over the life of the solution. It requires ongoing monitoring and source adjustments as changes are inevitable. Ensure the vendor is flexible and agile enough to meet your organization’s needs.
Griffin search: how Westminster College implemented WebFeat
Hane set out to dispel some common misconceptions about federated searching by publishing a list of five problems that the vendor WebFeat had identified. A few of the misunderstandings dealt with de-duping results (eliminating duplicate records) and relevancy rankings. The misconception that is discussed here that really rang true for our library was treating federated searching as software instead of a service. On our first venture into federated searching, we looked at it as software, and in doing so, we became a victim to the daily upkeep of the software. This upkeep drained our resources and would have been better served with a full-time programmer for the software.
I hope that next time someone writes off federated search as a simple product that you buy from the cheapest vendor that has enough of the features you want that you’ll let them know that, unfortunately, it’s not nearly that simple.
If you enjoyed this post, make sure you subscribe to the RSS feed!
Tags: federated search
