Search Drives Adoption and Engagement
The interwebs are alive with blog posts and sometimes not-so-cleverly hidden vendor messaging describing the many ways that you can increase your SharePoint adoption. As the shift in attention moves from IT Pro to business capabilities, adoption and engagement (or some variation of them) are quickly becoming the most discussed topic in the community, which really isn’t any surprise. What fun is it to throw a big (expensive) party if nobody comes? And yes, getting your organization to use the platform which you spent so much time and effort to deploy is as much about building buzz, running contests, and constantly educating your users as it is about building and deploying the platform. Yes, ultimately, you need to deliver the features and business value — but even then, you’re going to need to employ some degree of salesmanship. No matter how solid the solution you deploy, adoption takes work.
So how do you get them to stay? A cool splash screen? A dancing kitty? Bribery?
The best way to get users to stay is to make it effortless for them to get what they need. I’ve often written about change management and governance, which are important in the ongoing support of any healthy SharePoint environment. But those strategies become important once the system is in place — and are irrelevant (well, for the most part) once people are using the system. The problem is, as with everything in this world, first impressions are everything. If your users come to SharePoint and it’s not faster and simpler to operate than what they’re currently doing, they’re just going to go back to doing what they did before.
Search in SharePoint has always been more of an art than a science. A couple years back, I took a workshop with my friend and BA Insight CTO Jeff Fried (@jefffried) to learn more about the technology behind search, and while I took copious notes and understood much of the content shared, I quickly realized that a search expert I am not. But the concepts are fairly straightforward, and worth sharing: crawl, index, query, rinse and repeat. The challenge is getting the terms right. With SharePoint 2013, these core concepts are pretty much the same as previous versions, but there were some other fairly noteworthy features that were added. For example, an analytics processing component was included that allows for search specifically by activity.
I know there is new capability coming with SharePoint 2016, but often people are still unaware of what is available today — and taking advantage of the current search capabilities will greatly impact your user experience today, i.e. adoption and engagement.
Similar to previous experience, the crawl component goes through the all the content sources (web sites, file shares, SharePoint, profiles, etc.) and temporarily stores all of the information in the temporary crawl database. The crawl database contains detailed information about items that have been crawled such as last crawl time, crawl ID, and type of update (full or incremental). If there is a large amount of content to crawl through, you can simply add more crawl components to do the work.
Once the items have been crawled, content processing takes the crawled information and feeds it into an index. The index parses the documents using iFilters, and then transforms the crawled content into indexed content. There is also a separate link database that writes the information about the links and URLs associated with the information.
The analytics processing component has two separate components itself. Search analytics goes through the crawled items to find activity information such as links, related people, and metadata. Usage analytics contains information like views on an item from a front-end event store. The processing component then returns the information to the content processing component to include them in the search index. Default usage events are things like views, recommendations displayed and recommendations clicked. Results from usage analytics are then stored in the analytics reporting database. Along with the new analytics processing comes some new default reports such as popularity trends and most popular items.
The index is different as well in 2013. This time around there is just a single index, but the partitions can be stored across multiple servers. The upside is it’s easier to add a new server to share the load, but it’s also difficult to remove one, should you need to. There are also separate index components and partitions. Each index component takes in the information from the content processing component. Queries are then sent to the index replicas from the query processing component. As a general rule, you should add one index partition per every ten million items and a replica should be created for each partition.
The last piece of this puzzle is the query processing component. This little guy sits between the search front-end and the index component. The purpose of the query processing component is to analyze and process the search queries and results. Once done, it submits the query to the index component and then returns it to the front-end.
All in all, it’s really not as complicated as it sounds. If your search is going slower that you’d like, add more horsepower. For faster crawl times, add more crawl databases and content processing components. If the results are taking too long to be returned, replicate the partition. Or in the case of a larger farm, split the index into more partitions. To increase the availability of query, create an extra query processing component on different application servers.
So why go to all the trouble of learning how all of this works? Because search is the backbone of SharePoint and, as I mentioned up top, a key ingredient in making SharePoint perform under the scrutiny of discriminating end users. How do we get adoption to where we want it? Configure a fast, accurate, efficient search so your users can find what they’re looking for.