Most people buy SharePoint for the features that its known the most for – Collaboration, WCM, team sites etc. However very few actually make use of all the features that are available with it. The feature having the most potential to radically change the effectiveness of the existing SharePoint implementation in my view is search.
Fast was a pretty popular search engine and were brought by people who had complex search requirements. With the SharePoint 2010 release, people had an option to use it or the regular SharePoint search, and in 2013 it is the only engine powering search in SharePoint(my bets are that Microsoft will do the same with Yammer).
So now someone buying SharePoint, would by default getting a powerful search engine as well. According to a Gartner session I had attended sometime ago, portals that had FAST implemented on SharePoint had much better user acceptance than those without. So using the engine effectively should be priority for CIOs.
Now here is a bit of a paradox. Microsoft recommends not to carry out much customization on the platform. However the max bang for the buck for using SharePoint search comes with writing some bits of code. As I mentioned in an earlier blog, company policies on SharePoint swing from ‘the business is the boss, give them what ever they want’ to ‘SharePoint is to be used OOTB, if you can’t achieve it using a browser the business should live with it’. The right approach should be a balance to figure out right amount of customization. Budget may be a constraint for some organizations, and I fully understand it, however it would be like having a SUV and riding it only in the highways since punctures and repairs are expensive. For those set of users using something like O365 should suffice. If it is on premise, might as well make use of the money spent on the licenses.
Giving hooks to the crawl pipeline enables a lot of flexibility in delivering results. I remember the case of a customer who wanted to filter and group search results by the site name on which the documents were residing on, the site name being the project name. There was no neat way to do this earlier, however now the content enrichment allows us to have the index include values that is not directly part of the content.
Another useful feature is the xRank operator with which the search results can be ranked better. We could have better contextual results; we could track pages that a user has visited on SharePoint to generate weighted tags that indicate his interest and use these to impact the relevancy when he does a search; eg. I browsed multiple pages and documents on SharePoint that have been tagged as C#; when I search for coding guidelines, the first result should be C# coding guidelines, not the document that had been downloaded the most by people (would be a nightmare if most of the developers use java 🙂 ).
I could go on and on.. the possibilities of using search to improve the application are pretty much limited by your imagination. Letting such a useful thing go underutilized seems to be just a waste.