Apologies for the brief Blog hiatus but I've been busy working on something that I think will be of great interest to many of you; how to allow you to yield the benefits of integrating SharePoint and your traditional ECM systems. In fact, I am now heading up a new group at EMC which is tasked with creating the SharePoint integration strategy and developing the necessary products to support it. I’ll also be working closely with partners who are developing SharePoint-based solutions for EMC – if you fit in to this category then feel free to contact me with details of your specific offerings.
Many customers ask how we can help make their SharePoint and Documentum systems cooperate. Not surprisingly, their users love the ease of use of SharePoint; the intuitive UI, the integrations in to the Office products and the collaborative tools. Their IT and Governance teams however may have real concerns about the pervasive nature of SharePoint.
In order to address the needs of our customers we need to be able to provide an environment where the SharePoint and their traditional ECM systems are unified, integrated or aggregated. I have come up with seven different concepts to address unifying or aggregating SharePoint with traditional ECM systems. Over the next couple of months I will address each of the architectures in detail including the pros and cons, example operations & cost/impact analysis details. At the end I’ll include a set of postings that talk about the real value – how to combine these reference architectures in to real-life solutions to your potential integration and content management challenges.
I am hoping that coinciding with the final postings I will have completed a new book that goes in to greater detail behind each of the architectures as well as many more use-cases, some issue analysis and general background information.
Let’s open with a brief overview of the seven reference architectures plus some of the general premises. Please note that over the next 2 months some of the subtleties behind each approach will change as the concepts mature.
Unification vs. Aggregation vs. Integration
I think that it helps to differentiate between how I use integration, unification and aggregation. Unification is the process of bringing together a set of disparate systems – getting SharePoint to work seamlessly with your traditional ECM systems is unification. Aggregation is the process of bringing together all of the content from one system in to logically sensible blocks, e.g. creating an environment where the content from your 12,000 SharePoint sites is stored in a single subsystem. I use integration as a term to general mean "making the systems work together".
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.
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!
Got comments or questions? Disgusted or in complete agreement? Let me know...