On June 26, 2008, Dan Keldsen and I hosted the webinar in which we reviewed the findings from our Market IQ report on Findability. (The report will be published in the first half of July).
As is customary, I will answer all of the questions posed that we did not have time to answer during the recorded webinar.
Over 400 people registered for the webinar, and discussion was lively. so there are indeed a few outstanding questions that need to be addressed here.
I will continue to post questions and answers until all have been answered.
Before I start, however, I would once again like to thank our underwriters: Google, OpenText and Vignette. This is not an endorsement of their respective products or a market push. It is simply and sincerely a thank you as it is through the support of sponsors such as this that AIIM can provide its research at no cost to the general public. From the scores of Findability technology providers in the market, there were the ones that were generous enough to step up and support our cause to educate the market. So again, Thank You.
Now to the questions:
Q: What is your definition of an internal search tool?
A: Our definition is a software-based tool that can be deployed inside the firewall, and can be directed at any or all content within the firewall. So, this does not include internet-based tools such as Yahoo and Google (differentiated from Google Search Appliance, which is an internal search tool). These tools provide interfaces that allow those that implement them to customize them in a variety of ways.
Q: Can you comment on the difference in nature between public search engines and search inside the firewall; and any suggestions on educating stakeholders to manage expectations?
A: This is actually something we talked about in detail during the webinar and cover in the report. From a technology perspective, there is little difference between public search tools (internet search) and search inside the firewall. Yet, as our research found, functionally there is a big gap between the two search environments. That is most enterprises have not strategically addressed search - or Findability. The more popular public search tools provide more than just search - per se. These search platforms have a gambit of functionality integrated and running in background. The end result is a "search" experience that is usually easier to interact with and capable of locating relevant content more consistently and intuitively. Inside the firewall, most organizations address search as a function of an application (e.g. one search for e-mail, one for ERP, one in each DM/ECM system, etc.). Further aggravating this approach is the lack of customization undertaken. Despite the availability of complementary functionality, most organizations utilize the basic core search tool only.
This is what stakeholders should be educated on. Demonstrate search on your favorite websites to them. Point out some of the finer, perhaps subliminal features that make the sites effective (such as a taxonomy front-end, effective relevancy ranking, see alsos, etc.). If possible demonstrate a "simple search" on corporate content and highlight the lack of interaction and complementary functionality. Another way this may be accomplished is to have prospective Findability solution providers run demonstrations on the effectiveness of their "basic search" on your content, versus a more sophisticated implementation of their product.
Q: The key in the enterprise search enterprise is that we have to understand SINS = Search Is Not Simple.
A: OK, so the preceding question is really a statement, but I really liked this participant's statement and wanted to share it, especially in light of the preceding question. Search is not simple, or at least potentially. That is why we drew a difference between search and Findability. Search can be "simple" - but non-effective. Providing an effective approach to users interacting with content and enabling intuitive, quick and effective retrieval of content based on that interaction is not simple. It requires a deliberate strategy that takes into consideration Content, Community and Context - as we discussed in the webinar and will be in the market IQ.
Q: Were do you see Automatic Categorization and text analytics in the marketplace, as part of a solution?
A: Automatic Categorization and the broader functionality provided in text analytics are a powerful group of functionality in the market. There are several providers of such technology, and when this technology is purposely and deliberately integrated into a Findability platform, they can provide most powerful capabilities. Automatic categorization can facilitate the creation and/or ongoing maintenance of a taxonomy, which in turn can be used as a backed tool, to aid in search precision, or front-end tool to facilitate post- and pre-query navigation of content. Text analytics can be used in a wide variety of ways, ranging from concept-based clustering (which can provide greater precision in retrieval), to sentiment analysis (which could be used in many ways including in e-Discovery as a way to quickly ascertain the pro versus con evidence). the point is that both of these technologies can provide tremendous benefit, if used in an integrated platform, for very deliberate purposes. Neither technology is fool-proof (what is?), but both can provide great advantage over systems that do not deploy such functionality. It is important to stress however that the technology itself is not the solution. These technologies, like most Findability technology have little value if they are simply pointed at content with no thought as to how they will be specifically leveraged.
Q: How do search engines separate the relevance of content thats in the managed repositories versus discussions, wikis etc.
A: Relevancy ranking is actually a rich and interesting topic. Any Findability strategy should minimally, and early on, determine the degree to which relevancy ranking will be valuable to the environment. If relevancy ranking is considered important, then it is equally critical that the strategy include a determination on how relevancy should be determined (there are many ways that this can be done - not all supported by all vendors). One way - and only one that could be integrated with others - is through file type. Search and retrieval tools can be instructed to weight different types of content differently in ranking results. For example, a WIKI entry could be weighted lower than a BLOG entry, which is weighted lower than a PDF file. These values are tracked in meta-data. Typically, implementers should look for tools that allow them to customize relevancy ranking, to determine what values will be factored into the ranking, and for the capability to customize these values. Shy away from ranking algorithms that are pre-determined. Although these may save much time initially, results will likely be generic, not fine-tuned to your business settings and needs, and thus far less valuable.
Q: Is federated search the solution for finding all of our information?
A: No, although federated Findability might be. Sorry to nitpick here, but it is a point that needs to be understood. Search technology alone probably will not solve all content retrieval needs. A federated approach to Findability, that provides a single point of access to a host of underlying Findability functionality, tailored for effectiveness in particular collections of content and types of users, can be the solution". Of course, the development of such a solution platform requires a fair amount of work, and vigilance from a manager or owner of Enterprise Search.
OK - enough for this post. But stay tuned, there are many questions left that will be answered.
