Want to start this blog with an important caveat. The first reference architecture that we will look at is not something that I would advocate normally. It is something that I would refer to as Hobson's choice, (for those of you who don't know what that is click here), however I have included it for completeness as it is an architecture that we see being used readily inside companies today. As I mentioned earlier, it is used primarily because there are no viable alternatives. So what is it...?
In this architecture, an end user moves a piece content from SharePoint into the traditional ECM system by manually exporting the object from SharePoint on to their desktop and then importing that object back in to the Enterprise Content Management system as a net new object. Equally, if a user needs to get content between two SharePoint sites they will follow the same procedure, i.e. they will export the content from one SharePoint site out onto the desktop and then import it into a new SharePoint site.
Depending on how this architectural used is used it can either be viewed as being extremely effective or very unruly, expensive and potentially dangerous. That said, it is cheap, easy to deploy and flexible enough for almost all of your user’s needs! Also, you're using SharePoint to manage content that is work in progress and your ECM system to store your copy of record - from that perspective the architecture looks good...from all the perspectives it sucks IMHO.
In this reference architecture you will have a multitude of SharePoint instances implemented in your organization as well as separate instances of your various traditional ECM systems. There is no technological link between the systems, each runs independently. Let me be very clear about one thing, this is not unification, it is not aggregation and it is not integration.
So, could you legitimately use this architecture and expect it to stand up to the rigors of modern-day usage? I suppose you could, you'd have to put some very strict processes in place and ensure that they were being followed. However even if you could ensure the content was being moved between systems at the right time by the right people you'd still has some significant issues. Consider the following:
The document in the ECM system is simply a copy of the final document that came out of the SharePoint system. You lose all of the rich history, metadata and audit information from the original document. You have no idea about the versions the preceded the final document, the comments made in it or the discussion threads created to support its creation. You also lose the connection back to the source document; if you make a copy of the “final” document and load it in to the ECM system you sever any ties back to the source document. If someone finds a mistake in the source document they have no way of knowing which ECM systems might contain copies of that “official” document.
Most importantly, you will not have controls in place to allow for the decommissioning of the plethora of SharePoint instances after the collaboration is compete. You have no way of knowing if critical content has actually been archived to the system of record and hence you cannot safely archive or destroy the library or site. Being able to archive or delete obsolete SharePoint instances is critical to prevent you from being left with thousands of SharePoint instances full of uncontrolled content lying around the organization acting as compliance and disk-usage nightmare.
So, architecture number one is not an architecture that we would like to see used widely by companies today however we should recognize that it is an architecture that we do see being used by companies all to frequently. The next six architectures that will look at represent much more robust, long-term and effective approach to aggregating or unifying SharePoint with a traditional enterprise content management system.