I am the General Manager of the SharePoint Technologies Group and Senior Director of the Compliance Applications Groups for EMC's Content Management and Archiving Business Unit. My role
involves developing SharePoint and compliance strategies and then overseeing the development of applications to meet those needs. I have spent more than ten years developing and deploying content
management systems as a customer, consultant, and software developer.
You might have noticed that I am also the author of a book on implementing compliance systems. This has been described as a rollercoaster ride through the thrilling theme park that is
compliance. In the spirit of full disclosure, I should point out that it was me that described it as that and it is untrue but it caught your attention.
Google Ad
Disclaimer
I have 2 things to disclaim, firstly, that I stole this disclaimer from "the storage anarchist's" blog and secondly, the opinions expressed here are my personal opinions. I am a
blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions
of EMC.
2/26/2008 6:32 PMdouq millar wrote:
A challenge with the continuously changing types of collaboration information such as discussion threads or wikis is determining the event to trigger the migration (or replication) into an ECM store. Wiki pages can undergo very tiny changes creating a vast array of versions in the repository. Threaded discussion may be separate "records" or just a single record that is updated by appending more comments at the end. All these mechanisms proliferate a lot of similar data to clog up the store, not to mention generate a lot of bandwidth feeding it. The typical wiki mechanism (presumably used in SP) of just saving diffs may have to be added when migrating this kind of date, ideally at the source (to reduce incoming bandwidth) but at the backend if that is the only convenient place for this function. Reply to this
2/26/2008 6:22 PM
douq millar wrote:
In several cases, "archiving" refers to a more generic process rather than a specific one. Copying (and possibly removing) content from one store to another can serve: 1) backup, 2) replication (sync'ed across sites), 3) formal records management, 4) decluttering primary store, and, 5) 'true' archiving (migrated to less accessible store). Each of these has different characteristics and unique features (but esp. destinations) starting with a migration event from the primary store. Reply to this
A challenge with the continuously changing types of collaboration information such as discussion threads or wikis is determining the event to trigger the migration (or replication) into an ECM store. Wiki pages can undergo very tiny changes creating a vast array of versions in the repository. Threaded discussion may be separate "records" or just a single record that is updated by appending more comments at the end. All these mechanisms proliferate a lot of similar data to clog up the store, not to mention generate a lot of bandwidth feeding it. The typical wiki mechanism (presumably used in SP) of just saving diffs may have to be added when migrating this kind of date, ideally at the source (to reduce incoming bandwidth) but at the backend if that is the only convenient place for this function.
Reply to this
In several cases, "archiving" refers to a more generic process rather than a specific one. Copying (and possibly removing) content from one store to another can serve: 1) backup, 2) replication (sync'ed across sites), 3) formal records management, 4) decluttering primary store, and, 5) 'true' archiving (migrated to less accessible store). Each of these has different characteristics and unique features (but esp. destinations) starting with a migration event from the primary store.
Reply to this