Realizing True Records Management with Microsoft SharePoint 2010 – the Webinar

Posted on 22/11/2011 by markjowen

I’ve just signed up for a webinar that KnowledgeLake are holding entitled “Realizing True Records Management with Microsoft SharePoint 2010“.

KnowledgeLake were gold sponsors at the SharePoint Best Practices conference that I went to in London earlier this year, and, I have to say, it was a top-notch event. I had visited KnowledgeLake’s booth and I’m curious about how good their product actually is.

So, it was with interest that I read the “Reasons I should attend“. These included the following:

LEARN how records management on SharePoint 2010 can lower cost and risk through transparent application of compliance policies and consistent disposition of content
DISCOVER why SharePoint will succeed in records management where other ECM platforms have failed
WATCH the demonstration of a document lifecycle in SharePoint: the capturing of paper and electronic files including email, application of metadata and classification criteria, search, retrieval, viewing and application of record declaration
RECOGNISE how to outline an enterprise approach for the implementation of SharePoint 2010 records management
HEAR the customer case study by MOEITS and how they are using SharePoint. The solution saved the union nearly $1 million and realised a return from their investment in four months.
CONTRIBUTE to the Question and Answer session

Now, the first reason seems to be pretty standard when describing the virtues of any content management system. As is a demonstration, as well as hearing a customer case study..(Just change the name of the ECM system.)

What really grabbed me by the short and curlies was the second reason “Discover why SharePoint will succeed in records management where other ECM platforms have failed“. Now, this is interesting…I want to hear about this secret sauce that McSharePoint has.

Reason 4 is also one that got my attention. Here the phrase “enterprise approach” really stood out. I’ve been involved with SharePoint since 2007, and, coming from an ECM background, it was very evident to me that SharePoint 2010 is now being hawked as a bigger beast. And this is not only in the “functionality” of SharePoint 2010, but also in other ways. There are more “enterprise-level” whitepapers out now, and the official Microsoft SharePoint training is focusing more on the “business-side” rather than just pure technology.

I’ve registered for the webinar. I’ll be taking notes, and will try and report back on my findings.

Reference Links

Realizing True Records Management with Microsoft SharePoint 2010
KnowledgeLake
European SharePoint Best Practices Conference 2011

2011 Content Technology Predictions from Real Stor...

AIIM’s Email Management Practitioner Course

SharePoint and 5 Reasons

Killa Hertz & The Case of the Missing Documen...

Will IT actually help? – A response to Dux

What the Hell Am I Doing? (or “Should I just...

Killa Hertz & The Case of the Missing Documen...

Post-move SharePoint site Comparison

We want Google! – The number one requirement in Enterprise Search

Posted on 29/07/2010 by markjowen

All the users wanted was Google

One of the things I come across often when discussing client’s requirements for an Enterprise Search system is that they “want Google search”.

When I delve deeper I often discover that the client wants to be able to type one or two words in a small text box, and get back exactly the document that they were looking for. Within seconds.

What they don’t see…

Unfortunately, what the client doesn’t always see, or is aware of, is that there is a lot of work put into making Google work efficiently and that there is a staff of Google employees monitoring, and tweaking, and caring for the Google search engine. What the client also doesn’t realise is that Google (the company) has over 100 million servers around the world dedicated to indexing the internet.

Also of interest: Search in Real-life

Jeff Carr has written an article (Enterprise Search and Pursuit of the Google Experience.) that examines what happens when a google search is performed. He also writes “rather than posing the question why can’t we? we need to ask ourselves how can we?

(The included video by Google engineer Matt Cutts is also very interesting)

Recommended Reading
[Important Disclosure]

History of the Search Engine

Google+ – Early Research

Captain Kirk is killing Innovation

Understanding the Google Search Results Page

Promise #14 – Beta Testing SLIKK

Haha – Life before Google

Delicious’ tasteful reaction to negative fee...

The Delicious changes…further unrest in the ...

Enterprise Search & Federated Search – what’s the difference?

Posted on 31/05/2010 by markjowen

In this post, I look at the difference between Enterprise Search & Federated Search …

Enterprise Search

In Enterprise Search, content is indexed locally.

That is, the content is made available to the search engine, and the metadata, and if possible, the content itself, is indexed and stored in a database.

Federated Search

Federated Search utilises the search results that are provided by an “external” system. (“External” refers to another document management system or search application.)

Enterprise Search & Federated Search – Different Indexing Methods

There are a few interesting things about the different indexing methods.

In Enterprise Search, the documents are available by the indexer, all the metadata and content can be crawled and indexed.

With a Federated Search, the results are what was returned from the external system. This relies on the external system’s indexing capabilities.

On the other hand, to access, and index documents locally (in an Enterprise Search) usually requires loading the document to a locally accessible location. To do this can chew up a lot of bandwidth. Then there is the corresponding CPU utilization to do the actual indexing. And to keep the index up-to-date, further crawls/indexing need to be performed regularly. If the documents are relatively “close” (within the same subnet) then this should not be too much of a problem.

However, when the documents are located in, or indexed by, remote (outside the firewall) systems, a federated search has certain benefits. All that is being transferred is the query and the results that match that query. The indexing process is being handled by the remote system. And this includes the regular indexing required to keep the index up-to-date.

Should you use Federated Search, or Enterprise Search

So the decision whether to use Federated Search or Enterprise Search, depends on:

the resources available (how much grunt does your indexing server have?),
the availability of the content that needs to be indexed (can the indexer access the content directly)
the bandwidth available
the amount of confidence that the search results returned contain 100% of the content that meets the search criteria. (Are you happy with the results that the remote system provides).