Many clients are struggling with the concept of Enterprise Search.  While the last post  discussed ways to improve search results, this post will discuss thoughts and experience with a recent client focused on Enterprise Search.

Enterprise Search – What are the requirements?

Like many Enterprise Search efforts, our discussion started with a broad mantra of “I want to find anything, anytime from anywhere”.  Teams need to identify that this is more of a vision than a requirement.  For those of us in content management, imagine if we had a requirement that said we want “any document to be routed to anyone, anytime for approval?”  Experienced content management teams would work that “vision” scope to focus on certain documents, routed to certain people to reduce scope and make the initial effort a success with the goal of adding more documents and people in later efforts.  Enterprise search teams should look to reduce initial requirements as well.  Requirements we discussed included:

• Published Content – Finding “anything” was scoped down to talk about “published” content.  For published, we identified that a user had to identify in some way that this document was ready to share with a broader group or the world.  This helped differentiate between collaboration content that might not be ready to be viewed by the world.
• Secured Content – Similar to published content, finding “anything” was reduced to talk about access to both secure and unsecured content depending on the individual’s security profile.
• Silo versus Cross Silo – We identified that, for certain “Siloed” groups, search would really be limited to their department or group and that allowing access to other groups information would really just result in extra clutter and could result in performance issues.  For other groups, the need to access across silos for an enterprise search would be required.
• Document Types – The team wanted to focus on “published formats”, mostly PDF if possible but realized that other document types could be supported.  The team wanted to stay away from “author” formats (ex: Word), where the retriever might be able edit the document inappropriately.
• Watermarks – Consistent with certain document types, the group wanted to add watermarks to retrieved documents where appropriate.

Enterprise Search Strategy

The team talked in high-level terms about how the strategy should embrace both the groups that wanted everyday access to departmental/group documents, while allowing cross-group access to certain users.  Overall, consistent with other clients, the concept of one monster repository or one search infrastructure didn’t meet many of the enterprise goals and would be difficult to implement.  Some important points:

• Logical Authoring Repositories – Groups would have access to author/approve content.  For this client, this is Documentum but it could also be SharePoint or other content management tools.
• Logical Published Repositories – logically (or physically) caching published/approved documents for consumers, both within the department/silo as well as for external cross-silo search.  The team thought this was a better approach than providing too much access to source repositories.
• Scenario based user search requirements – The team spent time discussing how best to determine which groups needed cross-silo search and which groups would only want searching within their silo. 

Enterprise Search – It is not just a product

One thing we took away from the conversation was that, while software vendors like to label their products as “Enterprise Search”, an Enterprise Search strategy should not rely on just picking one product.  As a very obvious example, most of the Documentum users remember how ESS (Enterprise Search Service) turned into DSS (Documentum Search Service) and is now xPlore (limited to Documentum content.  Specific user requirements will drive out multiple search engines and repositories, each to fulfill specific search scenarios.   A “one-size-fits all” approach will struggle to address unique user scenarios specifically in regards to security and access.