Eight Reference Architecture Organizer
Someone asked me if it was possible to have a single page with links to just the "Integrating SharePoint with Traditional ECM Systems - Eight reference architectures" articles. I think that they were politely saying that they had no interest in my other articles...so this is it, alternatively, you can click here to filter by the relevant category. I'll try to make it "stick" to the top of the Blog.
Reference Architecture 1: Keep Systems Separate, Restrict Usage.
In this architecture the publishing of content between SharePoint and the Enterprise Content Management system is performed manually by the end user. This is not an approach that I’d advocate but it is included for completeness and because it is a method frequently used today simply out of necessity.
Reference Architecture 2: Loosely Coupled Solution
This is probably the key architecture behind any real unification solution today. In this architecture, content is moved between systems depending on its value to the organization. For example, work in progress might live in SharePoint and formal records might live in your ECM system. The move between systems is performed by a process and can be invoked manually or triggered by a specific event.
Reference Architecture 3: Use SharePoint as a Portal Container
In this commonly seen architecture, SharePoint hosts Web Parts that point at your SharePoint repository or at your Enterprise Content Management system. For example, one part of the screen’s real estate is displaying content from SharePoint while another part is displaying your ECM system’s Inbox. This is stretching the definition of “unification” IMHO but for reasons that will become clear later I think that this approach is often essential to make up a complete solution.
Reference Architecture 4: Passive Unification in Web Part
In reference architecture 3 the unification occurs within the SharePoint portal container. In this architecture the unification occurs within a specific Web Part; a single Web Part displaying content from a variety of disparate systems. We will look at this unification model from a passive perspective – only allowing the user to view or export the content.
Reference Architecture 5: Active Unification in Web Part
Building on reference architecture 4, we will see what happens if you attempt to add more complex operations to the affray; supporting operations like checkout, managing versions, connecting objects to a workflow, etc. The addition of these more complex operations increases the complexity exponentially.
Reference Architecture 6: Passive Back-end Aggregation
The first five architectures are all focused on unification. This penultimate example creates a passive aggregation model where we use tools to create a virtual aggregation across the SharePoint and traditional ECM environments. We can then monitor the aggregated environment and take actions as required. For example, we might compare the access rights on a piece of content that lives in 10 different document libraries and report on access inconsistencies.
Reference Architecture 7: Active Back-end Aggregation
The Holy Grail or Pandora’s Box? Real aggregation of the SharePoint and traditional ECM silos allows us to perform many operations that would be very difficult or even impossible otherwise. Having all objects from all environments addressable within a single space and supporting operations on those objects allows us to really address some of the current limitations in a scalable & secure way – think “single instance storage” for example.
Reference Architecture 8: Synchronized, Intelligent, 2-way Shortcutting
In this model the ECM system stores the only copy of the actual payload of an object, (the document, spreadsheet, image, etc.). A shortcut/stub/proxy/pointer is created in SharePoint; this points to the object in the ECM system and mirrors all of the appropriate object metadata. Actions applied to the pointer object are redirected to the ECM copy when appropriate. Both the SharePoint object and the ECM object are protected by event triggers so that changes to the properties, location, etc. can be synchronized and when either is deleted the other will also be disposed of.
Note that this RefArch works for content that already exists in the ECM system, is being created by a 3rd party process or is "published" from SharePoint.
Unification at the Middleware Layer
You may have noticed that the integrations above all manifest themselves in the client or server layer however the majority of SharePoint’s strength lies in the “middleware” layer. I am not ready to discuss middleware-level integrations yet but I expect to be able to add some more meat in to that layer of the sandwich by the time the book is ready to go to press…you may have to part with some cash to learn those bits!
Trackbacks
-
2/18/2008 10:34 AM
Compliance - Never Talk When You Can Nod wrote:
Read more about the seven reference architectures. -
2/24/2008 9:40 PM
Compliance - Never Talk When You Can Nod wrote:
aka Hobson's choice. 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.... -
2/24/2008 9:46 PM
Compliance - Never Talk When You Can Nod wrote:
In the second of the seven 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... -
2/27/2008 8:56 AM
Compliance - Never Talk When You Can Nod wrote:
In the previous two examples we focused on moving content from the SharePoint document library in to the traditional ECM’s repository behind the scenes. That “publish to ECM” paradigm may work for you but you must consider that once the content has moved in to your traditional ECM system’s repository you will lose sight of it from within SharePoint... -
2/27/2008 1:00 PM
Compliance - Never Talk When You Can Nod wrote:
Read more about the eight reference architectures. I represent the previous three architectures as being -
2/27/2008 1:06 PM
Compliance - Never Talk When You Can Nod wrote:
The objective of this fourth architecture is to create an environment where the end user is not aware of where an object actually resides. If the end user needs to see three documents in order for her to do her job then she should see all three documents in a single Web Part... -
2/27/2008 1:13 PM
Compliance - Never Talk When You Can Nod wrote:
The objective of this fourth architecture is to create an environment where the end user is not aware of where an object actually resides. If the end user needs to see three documents in order for her to do her job then she should see all three documents in a single Web Part... -
3/14/2008 4:14 PM
Compliance - Never Talk When You Can Nod wrote:
Read more about the eight reference architectures. In the previous reference architecture we unified SharePoint and the ECM system at the Web Part layer and provided a limited subset of functionality, specifically passive operations. There's no doubt that this -
3/14/2008 4:21 PM
Compliance - Never Talk When You Can Nod wrote:
In the previous reference architecture we unified SharePoint and the ECM system at the Web Part layer and provided a limited subset of functionality, specifically passive operations. There's no doubt that this "passive connectivity" provides a huge amount of value, uses a nice, familiar paradigm and can constitute a complete solution in some cases. However, there are many times when you need to be able to act more fully upon the content in the disparate systems rather than just browsing and viewing the documents... -
2/18/2008 10:30 AM
Compliance - Never Talk When You Can Nod wrote:
In the second of the seven 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...
Andrew,
For Documentum users who are thinking about how they will integrate SharePoint into their existing environments, the “Seven Reference Architecture Organizer”, once it’s done, should be required reading.
The first three choices, as far as I can see, wouldn’t be attractive to existing Documentum users in environments where minimizing risk is more important than cost and ease-of-use. Case and point? eCTD creation.
The vendors in this space for whom I’ve recently completed searches, and who have close relationships with the FDA, have said things like, “SharePoint has a long way to go when in comes to getting through review and validation.” Will the Documentum/SharePoint integrations described in Reference Architectures 4-7 make these vulnerabilities go away? If so, does this mean that Documentum will have more users/client and sell more user licenses?
Another question that I think needs to be addressed is whether a product like FCG’s FirstPoint can achieve the same time-to-market and compliance wins for a SharePoint customer as a SharePoint/Documentum integration can?
In any case, I’m looking forward to learning more. EMC certainly gets their worth when they pay you.
Virginia
http://www.brilliantleap.com/blog/
Reply to this