We took a little break from blogging after EMC World. The big announcement during Rick Devenuti’s keynote was the introduction of EMA – Enterprise Migration Appliance from Documentum Consulting. We had surmised that, given a change in object model, D2 would require a migration but were corrected by EMC as you can see in the comments here. This post will present our thoughts on the D2 object model and migration.
Why EMA if not needed?
We might have been initially throw by the announcement of EMA in Rick’s Keynote. Why make a big announcement about a new migration tool if you don’t need always need it? As we pointed out in our post on EMA, whether it is upgrading or just evolving your Documentum repository, a migration tool is a big part of the infrastructure for lots of different things. For Documentum Consulting to have an migration tool is a good way to extend a service offering. Whether it is always required versus recommended is another point.
D2 Versus Solution
One point we wanted to clear up initially was separating the software product, D2, from the Life Sciences solutions or upcoming Asset Management solution for energy clients from Documentum Consulting. As these solutions have been said to come with their own object model, it is our assumption that the solutions will require a migration from whatever customers are using to the new object model incorporated in the solution. We do understand that, since the solution is from Consulting, there might exist ways to leverage existing Dcumentum object models but we would think the recommended approach would involve a migration.
D2 in the Cloud?
Similar to our first point, we would assume that any migration to a solution in the EMC OnDemand Cloud would also require a migration. As mentioned during EMC World, the demonstrated client took a clone of the docbase to begin the migration by EMA. If I remember correctly, the migration was to the EMC OnDemand Cloud.
D2 and Migration – Understanding the D2 Object Model
To better understand D2 and whether a migration was required for a “Product” purchase from Documentum (and not a solution), we had one of our technical architects deep dive into the product to better understand the object model.
D2, when installed, requires certain objects in Documentum that can be manipulated via configuration. These objects begin with the D2 prefix and some examples include:
- D2_create_config – Parent config – What templates and document types – version rule
- D2_workflow_config – Workflow Configurations
- D2_ACL_config – Configures security
- D2_lifecycle_config – Lifecycle to attach to a document
- …..
The object types are created as part of the D2 install. As an administrator, a client would set up my SOP repository. While defining that configuration, instances of those types would be created defining the rules for what can be created an how within the D2 Workspace.
From our quick review, D2 Administrator can be leveraged to point to existing objects in the docbase. For DCM type clients, these objects might have existing templates, lifecycles, PDF Overlays and Annotations that would have to be addressed with D2. In regards to migrations, D2 would require
- PDF Overlays – D2 does not use PDF Aqua or PDF Stamping Services and would require some migration or redoing of the overlay configuration.
- Annotations – Client would have to verify that their annotation tool would work with D2 and the formats. If a client was using a proprietary format (ex: Brava) clients would need to leverage those tools or execute some type of migration.
- LifeCycles – Given that workflow is changing, clients would have to make sure they address the change in lifecycle with the D2 workflow. This would not be a migration but a reconfiguration.
From our review, D2 will require separate document types for different kinds of documents. In DCM, one document type could be configured as a “document class” that allowed the document type to have different characteristics and behaviors. For example, a document type could be an SOP or a Policy but both were defined by separate classes. DCM is created a sysobject (relationship object) that defines a document instance by its class.
Summary
Given the discussion above, we think it would be extremely difficult and unproductive to configure D2 to leverage the relationship object of DCM and would recommend that clients execute a migration to a new, defined for D2, object model. We look forward to hearing more feedback from EMC but are fairly confident that DCM users should be evaluating updating their object model rather than attempting to leverage the DCM model. For non-DCM users, the configuration of the D2 administration might be an option depending on their object model.
Leave a Reply