Archive for April, 2010

01: Security and Enterprise Search

Historically, enterprise search vendors have done a poor job addressing the subject of security.  In some cases, vendors didn’t have a good enough answer (and some are still struggling), hence the reason for the radio silence on the topic.  But in the main, I think we merely took the topic for granted and made assumptions that security would just be “taken care of” in the natural course of IT management.

With the continued rise in bigger and broader federated search deployments, security is only becoming more important, and as a result we’re doing more in terms of educating enterprises on the topic.  Our latest effort is a technical white paper titled, “The Principles of Security Management in the Context of Secure Search.”  While this paper won’t serve as a “how-to” manual on the subject of secure search, it does provide a suitable framework for better understanding the topic and ensuring your security managers are comfortable with the requirements.

No Comments  |  Post a Comment

02: Forget “Search” — It Is All About The “Virtual Aggregation” Of Data

I mentioned in a post late last year that 2010 would be the year of federated search, but now I think we need to go even further …

The number of record and content management systems that are coming onto the market (and the investment that is being made by vendors and customers alike) is simply staggering.  In isolation, a large number of these systems are good applications; some are even great … with some tremendous functionality.  But having spent time at the HP TRIM User Forum (TUF23) in Sydney last week, I can say they all have one thing in common – they require end users to know where content is in order to find it.

Think about this for a minute … if you know your content is in HP TRIM, then the search in TRIM will allow you to find what you are looking for, same if you know your content is in SharePoint.  However, no matter what role you have in an organisation, chances are you will interact with more than one of these data repositories.  From an enterprise perspective we cannot continue to expect our users to know where information lives.

The issue today is that data needs to live in different places.  These different repositories are purpose-built for the type of information that they contain.  The term “federated search” does not really do the concept justice … more accurately, what we are doing with federated search is providing users with the ability to find information by “virtually aggregating data” or allowing users to ask for some information that is likely scattered across multiple repositories.  

We can even take this one step further, following on from the commentary about “physical” data aggregation projects that are being embarked upon in Europe and the US after some high-profile information failures.  If you have a physical data aggregation project going on in your organisation, stop right now and see if there is a better way to accomplish the end result you are looking for. 

We can wrestle with terminology all we want (CMSWatch’s Theresa Regli recently presented some great thoughts on the related topic of “enterprise search” vs “federated search”), as long as we all agree that the true benefit of this technology is to locate and leverage information where it resides.

No Comments  |  Post a Comment