Content Federations is one of the cornerstones of a Content Services Platform (CSP). Content federations have been growing for the last two years. Federations go back to 2000, but the concept is still new to some. I’ve seen some recent confusion about the difference between Content Federations and Federated Search. I thought I might provide some clarification.

Federated Search is all about taking a single search statement and running that search across multiple content stores. Federated search goes back to at least 1999 with the Xerox AskOnce product. What started as a web search aggregator quickly filled the enterprise gap by searching content stores within the enterprise.

The challenge with federated search is that it is very difficult to combine search results effectively. A search result run against the same platform may return content with different scores because the score is based on the entire repository of content.

For this reason, many federated search engines have started to create their own index. This type of federated search engine is still not the same as a content federation as it does not support the creation or editing of content in third party repositories. They only support read capabilities.

Content Federations

Content federation is about giving the end users a single location to access all of the content in the enterprise. A CSP differs from Enterprise Content Management (ECM) in that CSP recognizes that content will not exist in a single repository but all of this content must work together.

Content Federations go back to 1997, but they have changed a lot in 20 years. Faster networks, stronger APIs, and more open storage architectures are all supporting the newer content federations.

Content federations are now following three different approaches. Those are:

• Interoperability approach - automatically registers content from third party repositories in the content federation. This approach is used by Alfresco and Nuxeo.
• Metadata approach - requires a user to select which third party repository content will be registered in the content federation. This is the approach used by M-Files and Systemware.
• Syndicated approach - works from the direction of line of business application by ensuring that as many of these applications store their content in a CSP. This approach is used by Box and OpenText.

These approaches are all based on a single index of content being managed by the CSP and the content being treated by the CSP as if it were stored in that CSP. The goal of content federations is to create a single location for content while allowing the controlled use of content in various applications across an enterprise.

By using a content federation, the location of the content is transparent to the application using the content. This can be a line of business solution, content solution, or even another repository, like a records management solution.

Unlike a federated search platform, using a CSP as the index means all of the functionality of that CSP can be performed against the content even if it is located in a third party silo. That means workflow from one system can include content from various repositories. The end user does not need to know where that the content is stored.

Content Federations and Federated Search both have uses in an organization. Both are designed to minimize the sprawl of content across an organization’s various repositories.

Content federations recognize the challenges of consolidating search results by creating cross repository indexes of content. But the real power of content federations is the ability to not only read content or metadata in another repository but the ability to write back or update metadata in the original source repository.

Marko Sillanpaa is co-founder of the blog Big Men On Content and the founder of BMO Consulting. He has been working in ECM for over 18 years for vendors like Documentum, EMC, Hyland, and SDL Trados and systems integrators like CSC and Accenture. Follow him on Twitter @MSillanpaaBMOC.