Search: are you willing to manage it as an application?

The question was asked, "how hard is it to configure FAST and what does that effort give you?" The none-too-helpful answer is that with every search product you get what you give. FAST happens to have more substance so logically there will be more to configure than some alternatives, and you can get more out of it in the long run and continuously grow its ROI as you learn its ropes.

First ask what you're searching for - know your corpus. How large is the corpus, how many users will you have in years 1/2/3, is this a single farm or several geo-distributed farms, and is there non-SharePoint content to index (databases, public web sites, file shares, etc.)? Just as important is your organization's previous experience with search - do people wince when search is mentioned? Have you used search applicances? Do you have librarians, taxonomy managers, or a dedicated search curator? Have you customized or built apps on top of search? If what you have now brings the shivers, then it's easy to win friends and influence people just by delivering search that doesn't suck.

And now we arrive at the central question: Are you willing to manage search as an application? Apps get attention. When they don't work, the business has no problem kicking butts until they're fixed. So when search is more helpish than helpful, why does no one fix it? Garbage in, garbage out. Search needs to be managed as an application.

No search product is great when left with a default configuration. All are built to be improved, and along with the sexiness of the UX, this is where you will find the important differences in features. Capture that in your evaluations. FAST is better than many - it does some automatic tuning - but I would never bet a career or reputation on out-of-box FAST. No application or product does an acceptable job in the long run with a "set it and forget it" mentality. You would never treat your LoB applications this way. Nor does it work for Google.com, the Google appliances, FAST search, or SharePoint Enterprise Search. Users can scream at these products to serve better results all day (and they do), and the net effect will range from zero to nil.

Even a part-time assignment - a half day every other week - will make a sizable difference to user satisfaction. That time is spent reading feedback (you do have a feedback link on your results page, right?), investigating the search logs to see if people are finding what they're looking for (and configuring synonyms and "Best Bets" if not), and building "canned queries" and other ways to ease the experience. This is how the nifty "metadata-based navigation" in SharePoint 2010 came to be, and I see other managed search applications serve magic in their companies year after year.

So is FAST for you? It depends. If your corpus is under a million documents, your current offering is weak, and you can only afford minimal management, then out-of-box SharePoint Enterprise search is a great choice. If your indexing requirements are more demanding, or users more accustomed to a great experience, then FAST is a great choice to build on. If prepared to make any meaningful investment in people to manage search, start with FAST because it provides a great growth path for features and scalability. The question remains: To what extent are you willing to manage search as an application?