As data doubles in the Enterprise every 12 to 18 months, the problem is only getting worse. Consider a query against 10,000 documents and 5% of those are hits returned in the search result. That’s 500 hits or 50 pages of results for your average 10 hit per page result. What is the likelihood that a relevant hit is found on the first page?

What’s interesting is that Google had this same challenge back in the late 90′s when the amount of content on the internet began to explode. Relevance started to drop like a stone. Google claim to fame was to take a somewhat obvious (in hindsight) approach to improving things. On the Internet users have a tendency to link to quality content. People are more than happy to subscribe to a useful blog, for example. The fact that a user took time out of his or her busy day to do so must mean they value that content. Google began to boost the relevance of this content, as if overnight people began to find what they were looking for.

One mistake that I’ve seen developers often make when deploying and optimizing SharePoint Search is to try to get it to do what it is simply not architected to do. One example that I seen recently was to extend SharePoint 2010′s faceted search to enable deep refiners, a feature seen in FAST Search for SharePoint. In this post I’ll explain why SharePoint can’t deliver this functionality based on the architecture of the property store.

I was recently asked about the differences of Autonomy’s IDOL Search platform and FAST Search for SharePoint. The project to compare these two products turned out to be a challenge and it reminded me of a similar project that I did many years ago while I was working at an energy company. The energy company was about to form a software development team and I was asked to compare the Java and .Net development platforms.

What makes these projects tough is that when comparing platforms, you can’t simply compare features because the real value of the platform flows from the fact that it can be customized or tailored to satisfy unique requirements. This is what makes selecting a platform so difficult; vendors will tell you that their platform can do anything.

I was recently asked to compare Microsoft Search (FAST / SharePoint Search) to Google’s Search Appliance Version 6.8. Both companies have solid search technology, but they are approaching the market very differently. This is reflected in their products making each better suited for specific types of search deployments.

Google shook up the Enterprise Search market back in 2002. The intent was to provide the market with a search solution that was easy to install and maintain. Surveys had revealed that generally speaking, users were not very happy with Enterprise Search. Google saw this as an opportunity to introduce a simpler search product. With the wind of Google’s strong brand at its back, the message resonated and Google quickly gained market share. By 2006 they had gotten close to entering the visionary Quad of Gartner’s Magic Quadrant for Information Access.