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!

Comments

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 3: Use SharePoint as a Portal Container

Read more about the seven reference architectures.

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 2: Loosely Coupled Solution.

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...

[Virginia Backaitis]

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/

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 1: Keep Systems Separate, Restrict Usage.

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....

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 2: Loosely Coupled Solution.

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...

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 3: Use SharePoint as a Portal Container

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...

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 4: Passive Unification in Web Part

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...

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 4: Passive Unification in Web Part

Read more about the eight reference architectures. I represent the previous three architectures as being

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 4: Passive Unification in Web Part

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...

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 5: Active Unification

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

[Compliance - Never Talk When You Can Nod]

SharePoint-ECM Reference Architecture 5: Active Unification

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...

[Compliance - Never Talk When You Can Nod]

Reference Architecture 6: Passive Back-end Aggregation

Read more about the eight reference architectures. Let me preface this entry by saying that this reference architecture is similar to reference architecture #1 insomuch as it is not something that I recommend or endorse but it is something that I see in use fairly frequently today; in fact many of the solutions recommended by Microsoft fall in to this category. Best case, feel free to use this approach while you wait for more appropriate solutions to come along. In the previous architectures we were trying to create a unified model so that an end user ...

[Compliance - Never Talk When You Can Nod]

Reference Architecture 7: Active Back-end Aggregation

Read more about the eight reference architectures. So unlike little old RefArch 6, this guy is the real deal. In this architecture we aggregate the actual content from a multitude of SharePoint sites. The content is transparently taken from SharePoint's control then stored and managed in a truly aggregated single location. In theory, there are a number of different ways of doing this: You can replace the entire SQL Server layer with an ECM solution that emulates the entire SQL stack. This gives you control over the content, metadata, lists, calendar items, Blogs, etc... in ...

[Brad Stuart]

A client of mine is an active reader of your blog and would like to speak to you. I wanted to discuss a consulting project with you directly. Please email me so we can connect. I look forward to chatting with you.Regards,Brad

[Compliance - Never Talk When You Can Nod]

SharePoint Archiving - RBS vs. EBS vs. Content Transfer vs. Shortcuts

If you only read one of my series of posts this lifetime you might want to make it this one. It is certainly not my most coherent or interesting series but it is the one that is likely to save you the most grief over the next few years, (assuming you have something to do with SharePoint deployments). This was going to be a single post but I got a bit carried away so I've split it up in to the following posts: This one - An Overview of the Issues ...

[Compliance - Never Talk When You Can Nod]

SharePoint Archiving - RBS vs. EBS vs. Content Transfer vs. Shortcuts

Imagine a world where content created in SharePoint was automatically routed to the most appropriate location depending on factors such as values in the object's attributes, where the object is in its lifecycle and/or who created it. Imagine that this was done without in any way affecting the SharePoint end user experience or any applications built on top of SharePoint. Imagine if doing this didn't just reduce risk and costs but it also made your SharePoint deployments more scalable and robust...

[Compliance - Never Talk When You Can Nod]

SharePoint Archiving - RBS vs. EBS vs. Content Transfer vs. Shortcuts

Imagine a world where content created in SharePoint was automatically routed to the most appropriate location depending on factors such as values in the object's attributes, where the object is in its lifecycle and/or who created it. Imagine that this was done without in any way affecting the SharePoint end user experience or any applications built on top of SharePoint. Imagine if doing this didn't just reduce risk and costs but it also made your SharePoint deployments more scalable and robust...