The next stop of Search Explained Roadshow 2017 is New York City, NY!
Date: May 15-16, 2017
Venue: Avanade Innovation Center, 155 Avenue of the Americas, 6th floor, New York, NY
During most of my career, I’ve been working as a consultant.
My 10+ years experience is that being responsible for Search is a huge challenge in every organization. First and foremost, because Search is challenging itself. Second, because each organization is unique, therefore needs a unique approach. There are too many components to make fit together.
In the first part of this series, I introduced why Search is like gardening.
Now that we’ve covered the basics let’s see how to measure the success of any Enterprise Search implementation. The appropriate metrics have to be identified and defined in advance. Designate the team members who have a responsibility to analyze each of these metrics regularly, create reports, and decide on follow-up action plans.
While planning and implementing Search, keep in mind that it should be governed and managed, even long after implementation is complete. We usually say that Search itself never can be “done.” Consider it like gardening. You set up your garden, plant the trees and flowers, water them, and enjoy a beautiful first blossoming. However, the work has not ended at all. If you do not water it regularly, if you do not prune the trees, fertilize and weed the garden, or mow the lawn, your lovely garden can rapidly turn into a barren field or a chaotic jungle.
A couple of months ago, I wrote a post on the “Big Picture” of Search. This post describes how the logical concept of SharePoint 2013 looks like, how the components interact with each other and what is the relationship between them.
This, more technical post has driven several people to ask me about the business background of Search Based Applications. How to start? What to do? What to expect? How to plan for a Search Based Application project?
Here are some tips and best practices of mine.
First of all, let me clarify the definition of Search Based Applications. The main characteristics of SBAs are:
SBAs usually fit into more characteristics of the above, if not all. In a nutshell: we use a search engine to collect the data from various systems (crawling & indexing). The User Interface gets the data not directly from a database or storage but from the Search index, where we store structured and unstructured data together, from various content sources, with various data schemas. The UI is responsible to present this wide variety of information to the users, meeting their intents, expectations and need, while supporting their everyday job as much as possible.
First of all, one has to identify the pain points to get rid of, the needs and requirements of the business to fulfill. Implementing a Search Based Application is a project where you have to know the goals. For example, initial requirements of a Customer Dashboard:
As every project, creating a Search Based Application needs a team as well. Of course, this means the group of people who work on the implementation, but also a lot of others. You need someone who is the owner of Search in your organization. Who doesn’t own the SBA project only, but who is responsible for the continuity of the Search service, who analyzes the reports, collects the suggestions, suggests improvements to the business stakeholders, etc. As I usually say, Search needs gardeners. Planting the nicest trees and flowers is not enough. You need to garden them to keep the beauty of your yard while it grows and changes continuously.
You also need to have a plan for this growth. This is where Search Governance comes into the picture.
Once you defined the goals, it’s time to think about the UI. What users are the target group of this application? How your users will get the most out of this application? What they want to see? How they do work? What information they need, on what views, in which order? Etc. Etc.
You have to know the elements of the Search Experience in SharePoint to be able to talk about it. Some examples, still for the Customer Dashboard:
Besides these out-of-the-box elements you might need some custom components as well. For example, a map to display location information. Or a component for diagrams and charts. The limit is the sky…
Of course, it’s possible (and very likely) to define more than one search page in the application, in order to target the intent of users from different viewpoints. In this case, you have to identify the desired UI elements for each page. It’s very useful to create mockups for each and discuss them with the stakeholders.
Once you identified your goals and who will do what with the new application, it’s time to define the content sources that you want to work with now and later. Last summer, I wrote a post on Content Sources Best Practices, please use this for your reference here.
Besides crawling and indexing the various content sources, you have to be aware that Search Based Applications can use one or more Remote Search Indexes as well. For example if you would like to provide a “Related News” part on your Customer Dashboard, it might make sense to get the news from public sites like CNN or Financial Times. You might have customers who turns up in these news. The point here is to aggregate search-driven content into your application that you either don’t want or cannot crawl & index.
You can use a remote SharePoint (or FAST Search for SharePoint 2010) index this way, too. For example, if you have multiple farms in your enterprise.
Besides the special requirements of Search Based Applications, the implementation can be very similar to any common project. Deliverables make it to be special. If you prefer, it’s always good to follow an iterative, agile process where the business can follow the progress where everything is and can be really proactive. I really like this way of working.
It’s also important to talk about the performance. Usually, on the backend-side (crawling & indexing), a SBA application doesn’t need any more resources than any other search solution. These components don’t really care what we’ll do with the data stored in the index.
What might need more resources is the front-end: the WFE of SharePoint and the Query Processor. Maybe even the Analytics component.
What I would like to highlight in this post is three things: planning and gardening. Be prepared, plan your application, and don’t forget about the life “after”.