One of the more common requirements we see from our manufacturing and operation clients is tight control around document versioning. In some cases, for example Pharmaceuticals, these systems are tightly regulated (and possibly audited) by a government agency such as the FDA. As we see more and more clients choosing Alfresco over Documentum, this post will share our thoughts on compliance requirements as well as how each product handles requirements around versioning and security.
Versioning, Security, and Relationships – Differences between Alfresco and Documentum
To illustrate the differences, consider a common document scenario:
- A Standard Operating Procedure (SOP) document exists in the system called ACME-1234. This document describes the bottling process for a product manufactured at a plant. The document is version 1.0 and Effective in the system.
- Pam, a Quality Assurance lead, learns that 1 out of every 10,000 bottles have a leaky cap. Jim and his team identify a fix that will reduce the chances of caps leaking. As part of this process, the ACME-1234 SOP must be updated.
- Jim, a Document Editor on Pam’s team, edits ACME-1234 and checks in a new copy, version 1.1 in the Draft state.
- Mike, a plant supervisor, executes a search for SOPs in the system related to his area of the plant. When ACME-1234 is returned in the search results, only version 1.0 is listed. The 1.1 Draft version must NOT appear in the search results since it is not yet approved.
- When Jim or Pam run a search for ACME-1234, both version 1.0 and 1.1 are visible.
- Jim and Pam work together to edit ACME-1234 and eventually have a version 1.3 Draft. Satisfied with the changes, Pam routes the document for approval to the appropriate document approvers.
- During the review and approval process, Dwight adds Annotations to version 1.3 and rejects the updates. Pam receives a notification, reviews Dwight’s comments, makes the necessary updates, and versions the document to 1.4. Pam re-starts the approval process on version 1.4. The annotations added to 1.3 are still visible, though they are tied to the 1.3 version and not carried forward to 1.4.
- Throughout this process, when Mike runs his searches, he continues to see ACME-1234 version 1.0 in the results. Mike does not see the in process versions.
- Once all document approvers approve the change, version 2.0, Approved is created and has an effective date of two weeks from the approval date.
- When Mike runs his search, he now sees both version 1.0, Effective and 2.0, Approved. Mike and his team have two weeks to train on the new SOP.
- After two weeks are up, ACME-1234 version 2.0 is promoted to Effective. Version 1.0 is Superseded.
- When Mike runs his search, he now only sees version 2.0, Effective. When Pam runs the same search, she sees both version 2.0, Effective and 1.0 Superseded.
Given the above scenario, let’s look at how we can satisfy the requirements relating to versions, security, and relationships with both Documentum and Alfresco.
Versioning and Security
In Documentum, each version of an object is a first class citizen. It has it’s own ID and the ability to have it’s own independent ACL security set. So in the above scenario, SOP-1234 version 1.0, Effective can have the Effective Document ACL, and version 1.1, Draft can have the Draft Document ACL. Depending on the security configurations, only certain users will see Draft and in process documents. The above scenario can be handled out of the box with Documentum versioning and security.
In Alfresco, when a document is versioned, a new ID is not assigned to the new version. Instead, the new version has the same ID and the old version exists as a “snapshot” in the version store. It is impossible in Alfresco to have different security sets applied across two versions of the same document. Additionally, it is impossible to run a search that returns both the latest version of a document as well as previous versions. To accommodate the scenario above, extensive behaviors must be coded in Java. Essentially, the code must create a new repository object when version 1.0 is versioned to 1.1. This allows the Draft version 1.1 to have a different security set than the Effective 1.0. A “supersedes” association should also be created to track the relationship between the objects. The user interface must be aware of this relationship so the document can be presented as one continuous list of versions to the end user rather than two separate document objects.
Versioning and Associations
Let’s take a deeper look at the steps in the scenario above where a reviewer adds annotations to a document and then the document is versioned. In this scenario, the annotations should only be contained on the version the user annotated. When the document is versioned, the annotations should “stick” to the prior version.
In Documentum, a relationship is tied to from document version to document version. Therefore, we can easily tie the annotations to version 1.3 of ACME-1234. when version 1.4 is created, the annotations “stick” to version 1.3 and are not carried forward to version 1.4.
In Alfresco, relationships are from document to document, not version to version. This means that when annotations are added to 1.3, if no custom code is added, the annotations will still exist on the 1.4 version after the document is versioned.
The above difference in how associations are handled with Documentum vs. Alfresco has other implications as well. For example, typically a Change Request form is associated to the document as it goes through the change process. The requirements typically state that the form is attached to the minor version, in our case it is 1.4 and the association sticks onto the latest minor version until the document reaches 2.0. Once the document reaches 2.0, the form association is “frozen”, meaning the 2.1 version should not have a Change Request association. This scenario is not possible with Alfresco out of the box.
As with the versioning and security discussion above, TSG’s HPI, Active Wizard, OpenAnnotate, and OpenContent work together to give Alfresco the functionality to satisfy these requirements. For additional information, see our compliance solution for Documentum, Alfresco or Hadoop.
Let us know your thoughts below: