Quickr and ECM integration
In one of my last post about Quickr (Quickr and ECM relationship), I was mentioning how an Enterprise could include Quickr in its own Document Management (ECM) strategy, and how both tools could be used together. It's important because companies have to leverage their existing ECM solution (like Documentum, FileNet, LiveLink, Alfresco, etc), and also to provide tools to improve collaboration between peoples.
My point of view was that Quickr should be used as a "front end solutions" (to manage "draft" documents or working copy), compare to the existing ECM which could play the role of a more reliable back-end for storing or archiving "Corporate documents".
On the Quickr wiki, there is now an example of how to use the Quickr Document Services to publish content between Quickr and Documentum: Quickr and Documentum
The solution has been implemented by Infosys. This movie briefly describes how the solution works from a functional point of view: see
This integration approach between Quickr and Documentum clearly illustrates what could be the role of each tool: the Collaboration tool is made to initialize the "draft" (or version V0) of a more official document that has to finally be
approved by the boss. The first version of the document is created in Quickr, where a team of colleagues collaborate on the first n versions of the document. Once the document is finalized, it is simply "moved" in Documentum, where the boss can validate it.
As described in this article: "The integration of collaboration platforms such as IBM® Lotus® QuickrTM with any ECM solution, faces numerous challenges. These include leveraging the existing centralized ECM system and driving the collaboration via Lotus Quickr, presenting a unified user interface for Lotus Quickr and the ECM system, having seamless content management processes across both systems and managing documents between the two."
The example that is presented on the Quickr wiki seems to describe a very basic approach: the document is simply moved from Quickr to Documentum. Then Quickr probably only keeps a "link" to the document (only the main META-DATA and a reference link to the ECM repository) in its own database.
After the move operation, the document reference is still available from Quickr, but it is physically stored in Documentum.
So in this example, the Quickr repository is clearly separated from the ECM repository. The document is first stored in the Quickr storage (JCR 170 database, for WPS implementation) and an explicit user action is required to move it to the ECM database.
The problem is that people will probably not do the effort of moving documents from one repository to another...So documents will remains in the Collaborative tool database...forever.
Moreover, end-users will probably not understand what is the difference between the Collaborative and the ECM repository, and why and when they have to use each solution separately.
A better approach (both for IT team and end-users) would be to have the ability to replace the Quickr Document repository to plug it directly on their own ECM solution database. But this is probably a bigger challenge...
I will try to investiguate to see if it is really feasible, or if a more pragmatic approach must be used...but this will be the purpose of a next post.
My point of view was that Quickr should be used as a "front end solutions" (to manage "draft" documents or working copy), compare to the existing ECM which could play the role of a more reliable back-end for storing or archiving "Corporate documents".
On the Quickr wiki, there is now an example of how to use the Quickr Document Services to publish content between Quickr and Documentum: Quickr and Documentum
The solution has been implemented by Infosys. This movie briefly describes how the solution works from a functional point of view: see
This integration approach between Quickr and Documentum clearly illustrates what could be the role of each tool: the Collaboration tool is made to initialize the "draft" (or version V0) of a more official document that has to finally be
approved by the boss. The first version of the document is created in Quickr, where a team of colleagues collaborate on the first n versions of the document. Once the document is finalized, it is simply "moved" in Documentum, where the boss can validate it.
As described in this article: "The integration of collaboration platforms such as IBM® Lotus® QuickrTM with any ECM solution, faces numerous challenges. These include leveraging the existing centralized ECM system and driving the collaboration via Lotus Quickr, presenting a unified user interface for Lotus Quickr and the ECM system, having seamless content management processes across both systems and managing documents between the two."
The example that is presented on the Quickr wiki seems to describe a very basic approach: the document is simply moved from Quickr to Documentum. Then Quickr probably only keeps a "link" to the document (only the main META-DATA and a reference link to the ECM repository) in its own database.
After the move operation, the document reference is still available from Quickr, but it is physically stored in Documentum.
So in this example, the Quickr repository is clearly separated from the ECM repository. The document is first stored in the Quickr storage (JCR 170 database, for WPS implementation) and an explicit user action is required to move it to the ECM database.
The problem is that people will probably not do the effort of moving documents from one repository to another...So documents will remains in the Collaborative tool database...forever.
Moreover, end-users will probably not understand what is the difference between the Collaborative and the ECM repository, and why and when they have to use each solution separately.
A better approach (both for IT team and end-users) would be to have the ability to replace the Quickr Document repository to plug it directly on their own ECM solution database. But this is probably a bigger challenge...
I will try to investiguate to see if it is really feasible, or if a more pragmatic approach must be used...but this will be the purpose of a next post.
posted by Enguerrand SPINDLER at
12:09 PM
2 Comments:
You can use a Content ETL solution in order to move content between your content repositories... or Content Federation to bind front end UI with back end CMS.
By
Anonymous, at March 17, 2008
Using ETL is not an option in our case, because we don't want to manage 2 distinct documents repositories, and to deal with synhcronization issues....So what we would like is more like you mentioned a "binding" approach between Quickr front-end layer and our own company document repositories. But linking Quickr with another persistency JCR storage is probably not so easy, and it will probably involved a "major" development effort to enable this binding....
By
Enguerrand SPINDLER, at March 21, 2008
Post a Comment
<< Home