Read more about the eight reference architectures.
In the second of the eight architectures I take the general premise from the previous example and extend it. The content still lives natively in SharePoint while you are collaborating on it and is then "migrated" in to the traditional ECM system at a predetermined point in time.
As a matter of interest according to recent research, for most customers this movement of content from SharePoint to an ECM systems occurs because of one of the following reasons. The document:
- Becomes a formal business record.
- Is being collected as part of a legal discovery process.
- Needs to have extra protection applied, the application of digital rights management for example.
- Is being archived for operational reasons, e.g. the document library is no longer operational and can be archived in its entirety.
- Should be made available for re-use and re-purposing; perhaps being included in a formal structured business process.
- Will be published to web site or an external multi-channel device.
In this reference architecture the migration is done using an automated process which “publishes” the content from SharePoint in to the traditional ECM system. Fundamentally, the automated process is simply extracting the content from SharePoint, caching it locally and then uploading it in to your ECM system but the fact that the migration is controlled by a process not a person allows you to more easily perform some auxiliary tasks. For example, when the content is moved across from SharePoint it is possible to bundle up some of the object’s history, metadata and related content and to move that across too. For example,
- The original location of the file in SharePoint.
- The audit trail information about the object.
- The security access settings.
- Some of the metadata, (creation date, original author, version number, project name, signatory information, etc.)
- All versions and/or renditions of the document.
Having this information derived from SharePoint allows you to do the following:
- Identify that the content in the ECM system was originally imported from a specific SharePoint instance.
- Identify that a piece of content in the SharePoint document library has been archived at some point and where it was archived to.
- Retain the entire version or rendition history of an archived item.
- Maintain the security permissions model between systems.
In fact, you can pretty much bring anything across from SharePoint to the ECM system so long as you have a way of extracting it from SharePoint and then storing it in the ECM system. You might even collate information from other sources during the archive process and include that in the archived content.
Unfortunately, the most common approaches to this architecture will typically implement a "once only" and also "a one-way street" model. Content is moved over to the ECM system and the publish process is then finished. The publishing is a one-off process triggered by a change in state of the document or an external event. In some scenarios this is not a problem, for example when publishing to a records/retention archive or for eDiscovery collection when the content published to the archive will not be changed. In order to avoid this limitation you would have to have agents running on both the SharePoint and ECM systems that would monitor changes to the source or target objects and would be able to reconcile changes to either the source document or the archived copies...not a trivial task.
Conclusion
Again, this very loosely coupled model leaves a lot to be desired – the good news is that you end up with content in the most appropriate place at the most appropriate time but it is typically implemented as a one-off process. Even if you have a post-migration synchronization process in place you are really just moving content from SharePoint in to the ECM system...there has to be a better solution...doesn't there? Actually, this architecture comes in to its own when you combine it with some of the architectures that follow. After I've described all seven architectures I will focus on how to start combining them to get real efficiencies...the suspense is killing you - admit it.
One other consideration that you might notice is that you are potentially storing each piece of content multiple times which is a disk space and compliance liability.
Comments