This roadmap series raises and addresses a number of issues that prospective customers of federated search solutions will encounter. It is based on the outline I published last week; I’ve made a couple of changes to the outline to reflect reader input. Here is the new outline:
In Part I of this series I wrote about a number of issues with the RFP process that increases the cost of doing business for federated search vendors and raises the cost of procurements for libraries. In this article, I consider ways of mitigating the costs. Much of the information for this series comes from an article written by Carl Grant: Choose wisely: making the library’s money work for the library in the system procurement process.
Grant makes the important point that vendors and libraries must collaborate to bring costs down. If libraries insist on continuing to use the current RFP process then vendors will be forced to use it as well. The first step in this collaboration is for the library to clearly articulate its goals to the vendor and to have both parties consider what needs the vendor can realistically meet. This also requires the vendor to be honest and up-front about what it can reasonably deliver. While Grant’s article is biased in its outlook - libraries are made to look like the bad guy - I’ll state that vendors own some of the responsibility. If vendors were really clear and honest about what they could deliver, on what schedule, and at what cost, then libraries wouldn’t be grilling them so hard.
I recently published a review by Carl Grant, President of CARE Affiliates, of one of the chapters in Christopher Cox’s federated search book. Beyond addressing the content of his review, Grant wrote that he didn’t think the RFP process worked well for either customer or vendor. He is referring to the process where a library issues a “Request for Proposal” (RFP) with difficult and detailed questions which each prospective vendor has to make a significant time commitment to respond to. The vendor in turn has to bury the cost of responding to RFPs in the purchase price of the systems it sells.
For many readers of this blog, I suspect that the roadmap to a federated search solution is not clear. How do you get from “We need federated search” to a deployment that meets your organizations needs and that you can feel proud of? Below I present an outline of a process I believe can help you to organize your thinking, your planning, and your actions towards the goal.
Note that the outline below is just that, an outline. The value to you will come during the next several weeks as I discuss, in individual blog articles, each item in the roadmap.
In a recent article, Infotech reported that Oxford, Cambridge, and Stanford have each announced federated search systems.
The press releases provide some insight into what was important to each of them:
At the 1999 American Society for Information Science and Technology (ASIS&T) Annual Meeting, Dr. Matthew Koll delivered a presentation titled “Major Trends and Issues in the Information Industry.” In a set of post-presentation notes, Dr. Koll made some powerful statements that, nearly 10 years later, still resonate with search in general, and with federated search in particular.
Koll defined information retrieval in a novel and elegant way:
Information retrieval is the science and practice of trying to show people the document they would want to see next, if they had total knowledge and hindsight.
[ Editor's note: Carl Grant, President of CARE Affiliates, was one of the volunteers who took me up on my offer to review several chapters of Christopher Cox’s book about federated search. Following is his review of one of the chapters: “Developing the Right RFP for Selecting Your Federated Search Product: Lessons Learned and Tips from Recent Experience” by Jerry Caswell and John Wynstra.
I appreciate that this review comes from a seasoned federated search vendor; Carl Grant has been in the library automation industry for a long time and raises an important concern about the RFP process, how his experience is that the current RFP model doesn’t really serve the customer or vendor, and he touches on what he sees as a better approach.
Last week, federated search vendor MuseGlobal announced that it had partnered with consulting firm Adhere Solutions to provide federated search for the Google Search Appliance. Dubbed the “All Access Connector,” MuseGlobal and Adhere have developed an extension to Google’s Search Appliance. The press release announcing the partnership lists a number of features:
I’ve had discussions recently with Abe Lederman and Darcy Pedersen regarding how organizations go about selecting a federated search vendor. (Darcy runs marketing for Deep Web Technologies, this blog’s sponsor, and Abe is my brother and runs the company.) I wanted to know how Deep Web’s customers went about choosing a vendor, whether it be Deep Web or one of its competitors. What questions did prospective customers ask? What were their concerns? How did they formulate requirements? How did they conduct pilots? How did they ultimately evaluate vendors?
To synthesize our discussions, Darcy drafted a checklist of questions. I’m not ready to post the list yet because I’m interested in fleshing it out a bit more and I want other input to improve and extend the questions, hence this post.
If you follow this blog you know that I rarely write about metasearch engines. It’s not that I dislike them, there’s just too many of them out there, it would be hard to keep track of them all, and few capture my attention. Plus, even though metasearch engines are federated search applications in their own right — they aggregate search results in real time from a number of sources (which may consist of live or crawled and indexed content) — I mentally place them in a category of their own.
Last December I wrote about Rollyo, a personal search engine that you can customize with a list of URLs to search. While one could argue that Rollyo is not a federated search application (it’s got to be searching crawled and indexed content rather than live sources if it searches arbitrary web-sites) I found it to be innovative enough to warrant a post. Addict-o-matic (hat tip to Web Worker Daily) is another metasearch engine that intrigued me.
