Published: July 29, 2010 - 02:00

Query Federation – Done Right

What you need to know: It's not just black or white!

Strong query and content federation capabilities are a must have for enterprise search  applications as knowledge workers need to retrieve the enterprise’s internal content as well as important content that nowadays often resides outside the enterprise.

As we mentioned in our previous blog there are several ways to connect with standard and even highly customized line of business applications. An effective information access tool needs to facilitate users’ access to all of these content sources while preserving value and context of each information object and knowledge asset.

Query Federation Architecture

Federation raises its own challenges

  • Each repository offers different levels for searching and accessing its content. Starting with simple metadata search in a database and standard full-text search in documents up to highly sophisticated enterprise search capabilities with dynamic facets, adaptive relevancy models and advanced possibilities such as actionable results.
  • Most repositories support different authentication standards and protocols like Kerberos, OAuth, OpenID, SAML or just Basic Authentication.
  • Very often the repositories maintain their own user administration.
  • If you have five repositories you might have at least five different ways of how these rank their results.
  • Different and often very slow access times to information in federated sources. What about quality of service to your end-users, how can you make sure you can meet their needs?
  • Do you need real-time alert on information / data changes over all your data sources? This can be tricky or impossible to realize for federated sources.

Even with standards like OpenSearch, CMIS or OData, which leading-edge content applications support today, there is no standardized route to success.

5 most important questions you should think about

So what are the 5 questions that need to be taken into account to decide whether you want to connect or federate a data source?

  1. Supported search capabilities:Does the federated source have sophisticated search capabilities? You might want to use e.g. navigational elements all over your data sources for unified information access.
  2. API: Does the federated source offer an API to access the information objects in a secure and fast way? Does the API offer contextual information such as actions for a document/object? Is there a way to access an object/document and not just the abstract thatcan be used for features like entity extraction or fact extraction from your enterprise search software? Note: If your content application vendor supports a standard-compliant exchange format you should stick to those open standards to make sure that your investment will last for a longer period.
  3. Authentication: What about authentication? Is Kerberos or SAML already in place?
  4. Authorization: Make sure access is checked when using the API as well. This should bethe case with most content applications I know of. But is the performance to authorize the retrievable information online really fast enough and scalable?
  5. Ranking/Relevancy model: What about the result ranking of your federated source? Is there a relevancy model? Do you need to unify the relevancy with your enterprise search solution? Often a search group or portlet for exclusive display of the federated results is a good enough and often easy way to start.

Our perspective: For federation to succeed, information repositories will need to offer more meaningful access than returning the top few results for a search query. If we can support you, let us know:

Adaptation Mandatory for Enterprise Teams in2012 : Beyond Search

solution is the key to all of the potential IT woes in 2012. One suite of
solutions we like is Fabasoft Mindbreeze. They excel in assigning meaning to
results in a way that others, namely SharePoint, lack. “There [...]

Submitted: December 13th, 2011 07:01