The Rise and Fall of Microsoft Search
When Microsoft SharePoint launched in 2001, it was a time of substantial innovation in the enterprise search sector. IBM STAIRS, DEC BASIS, Verity and Fulcrum were already well-established applications. By 2005, the Gartner Magic Quadrant for Information Access listed 25 vendors, with FAST Search and Transfer, Verity, Autonomy and Endeca populating the top right leaders quadrant. By comparison, the search functionality of SharePoint was poor.
Autonomy bought Verity at the end of 2005, mainly for its customer base, leaving FAST Search and Transfer as the market leader. In 2006 FAST Search published its "Book of Search," which to this day remains the definitive guide on managing enterprise search applications.
The Rise of Microsoft Search: FAST Search Buy
Microsoft must have decided there was no way it was going to match either Autonomy/Verity or FAST Search, so in early 2008 it acquired FAST Search and Transfer, including its brilliant team of search technologists in Norway. I was very excited by the idea that Microsoft was going to take enterprise search seriously. The launch of FAST Search Server for SharePoint (FS4SP) looked like a step in the right direction. It also was probably the catalyst for a series of acquisitions of the leading independent search vendors (Exalead, Endeca, Vivisimo, Isys and Autonomy) by the IT mega-companies, which left a significant gap in the market.
To get a sense of the functionality of FS4SP you only have to look at the 2012 book, "Working With Microsoft FAST Search Server 2010 for SharePoint," which came in at 450 pages. Table 1-5 compares FS4SP with SP2010 search, with FS4SP scoring 56 and SharePoint 2010 scoring 25. One important difference was the powerful and flexible content processing pipeline in FS4SP. The performance and the branding combined to ensure many CIOs were under the impression they were running ‘FAST Search’ rather than a Microsoft product. Indeed, many continued to run FS4SP even after it was officially written off by Microsoft.
Related Article: Reading Between the Lines of Enterprise Search
And the Fall of Microsoft Search
The launch of SharePoint 2013 made it clear that Microsoft was planning to emasculate the functionality of FS4SP as it moved towards a hybrid and eventually a cloud-first strategy. The company also had to deliver a search application that its partners could support, many of whom struggled with FS4SP.
Microsoft later replaced the Classic user interface (which dates back in principle to 2002) with the Modern interface, and is now in the process of delivering a "one size fits all" strategy, which claims to deliver the same search experience across all its applications, across all users and across all shapes and sizes of organizations.
If you want anything slightly better, there is the PnP library of four web parts for Results, Filters, Verticals and Search Box. However this comes with a health warning!
“Between the four of them, there's somewhere around 100 different configuration options, which can be configured into countless combinations; and if you want to make the most out of them, you're also going to need to be somewhat familiar with SharePoint Search topics such as managed and crawled properties, refiners, result sources, etc. .... Point is, these web parts are not meant for the masses and can be a challenge even for the most super of super users.”
Does that seem like a good situation to you?
Related Article: Has Microsoft 365 Been Clinically Tested?
The concept of task-based search evolved in the mid-1990s. Search applications became a requisite to meet employee's specific needs in completing tasks. A vast amount of research is now available on this topic. It is especially interesting to look at the research into professional search, as used by lawyers, health care practitioners, patent agents and recruitment professionals. This research illustrates how very different the requirements are for both index management and the user interface.
Increasing interest in providing configurable user interfaces that support federated search across multiple applications and multiple languages is now evident. Both Sinequa and Coveo offer these features and many enterprise search applications are now specific for particular tasks, such as Exalead in the manufacturing sector.
Power Hybrid Work With Tech That Connects
Robin recently surveyed 300+ professionals to better understand what great leadership looks like in a hybrid world.
Empowering and Enabling Teams in the New Hybrid Workspace
As hybrid workplaces become the norm, intentionally embracing this new way of working is one key to success.
So on the one hand you have Microsoft with a strategy of one-size-fits-all, and on the other, all the other 70-plus vendors in the enterprise search sector moving towards delivering configurable user interfaces which support a range of tasks, diverse content types and non-Microsoft applications. In the near future it is likely that search product differentiation will be based around UI capabilities.
Ask Yourself: Does Microsoft Search Meet User Requirements?
Keep in mind that Microsoft Search isn't a stand-alone product. Rather, it's a search-based application that supports all the features of Microsoft 365, which means the experience depends on the product you are using. Microsoft therefore has limited capacity to make significant enhancements to Microsoft Search lest it break another product. No one has ever made a business case for a Microsoft application on the basis of its search functionality. The CIO made the decision to implement and search came along for the ride.
I would hazard a guess that the vast majority of CIOs have not been exposed to the search functionality offered by independent search vendors. According to the latest Gartner MQ for Insight Engines, Microsoft is now lagging IBM, Mindbreeze, Sinequa, Coveo, Lucidworks and Squirro.
A few of the feature gaps include:
- No configuration of snippets to support making effective relevance judgements.
- No solution to the complex UI requirements of federated and multi-lingual search.
- Poor support for entity extraction, acronym management and ‘sounds-like’ name search.
- Specialist skills needed to make use of PnP web parts, compounded by there being no auto-upgrade path from v3 to the recently released v4.
- Very limited analytics.
- A complete lack of transparency and customer control on how the underlying knowledge graph decides on personalization and relevancy.
- Constantly changing roadmap with no consistency from month to month on availability and delivery dates.
Adding to this list is the challenge that users have to know which site collections to search in for the information they need.
Of course, Microsoft search may be a good match for your enterprise-wide search requirements, but have you considered your employees' requirements at a persona/task/location level, and carried out a gap analysis between what they need and what you are delivering? There's no point asking them how satisfied they are with Microsoft Search when they have no experience with other search applications. If you've never driven an electric car how can you know if it's better or worse than your regular car?
A senior Microsoft manager made this comment at the IntraTeam Event in Copenhagen this March. And the outcomes of the ongoing IntraTeam benchmark survey support the remark. Microsoft's market share of enterprise-wide search is certainly of the same order of magnitude as the dominance of Google in web search. I assume it is merely a coincidence that ‘search sucks’ and that the vast majority of businesses rely on Microsoft Search.
About the Author
Martin White is Managing Director of Intranet Focus, Ltd. and is based in Horsham, UK. An information scientist by profession, he has been involved in information retrieval and search for nearly four decades as a consultant, author and columnist.