Open Text Content Server and Documentum grew up together during the same time, but in different neighborhoods. Sometimes I wonder how certain architectural design decisions were made, or how lack of funding may have affected the level of integration between the products in their respective software suites. When compared with DCTM, OT is like an old Mustang and DCTM is a newer Toyota with recall issues. This is by no means a comprehensive comparison of the two software suites. It points to some important ECM aspects and tries to expose some of the issues and precularities.
Session Thread Model
OT has an understood session thread limit of 5 per server. Can you imagine this with DCTM? OT will fix this with their 10X release, but customers have suffered for years with this limitation. Session management in DCTM is mature, but has its own issues. So in OT the way to scale for many users is to build out Livelink servers (5 session threads) per server. If you had the potential for 30 concurrent sessions, then you’d have to build out 6 server instances. These OT instances would have to have all of the modules, patches/fixes, on each. This is 6 times the deployment effort. It took OT 10 years to scale concurrent sessions on their base server kernel?
DocBroker vs. Nothing
Here’s a real big issue with OT: failing over one repository to another. OT just can’t unless you want to purchase archive server which is not really part of the LL server and not pertinent to this. OT relies entirely on load balancers for distributing client requests. Yes, the docbroker has its issues too, but at least it can be used to failover one repository to another.
Object Model
Because Open Text doesn’t have the foundation classes that Documentum has it is hard to conceptualize the inheritance model and relationships between the underlying database tables.
dm_sysobject : DCTM’s main table which holds the chronicle and object ids of most of the objects in the repository (dm_type, dm_user, dm_acl are related by not derived from dm_sysobject). Document objects extend from this table in the DFC and are related to separate doc tables per configured doc type. Both architectures have main tables which are related to be most other tables. This has its pros and cons. Let’s take a cursory look at both models and try to compare some key areas.
Dtree: OT’s main table which holds the data id of all objects. If you look at the schema, it’s like a wheel with spokes all leading to the dtree hub.
Version Trees
If you ask an experienced OT administrator if there is a parent id to a document id, chances are he would not know the answer or he might even ask why is this important? Version in OT is not an option. In DCTM at least there’s a way to control versioning during the work in progress states.
dm_sysobject: The parent id of a version is the chronicle_id which holds all of the object_ids. The chronicle and object_id are in the dm_sysobject table.
version tree: dm_sysobject chronicle_id and object_id
dtree: The parent id of a version is the docid which is in the dversdata table and the version ids are in that table as well. The key between the dtree and dversdata table is the dataid which is the docid
version tree: dtree dataid = dversdata docid then versioned
Given this simple example of versions, you can see that OT’s table join for version look ups of basic system level content attributes may not scale as well as DCTM’s.
Permissions and ACL Inheritance
In DCTM there are separate tables and objects which manage permissions of folders and content, as well as system objects themselves. In OT, there is no such concept: permissions are inherited by default from folders only. In DCTM, ACLs can be inherited by object_type, user, or folder.
OT: folder only
DCTM: object type, User, Folder
If you think about the advantages that DCTM’s model has over OT’s look at how limiting it is for workflows which may rely on changing permissions to an attachment as it goes through the review and approval lifecycle states. In DCTM you set the ACL and you’re done. In OT you set the permissions for each user and group at every state. What a change management nightmare!
Object Types vs. Categories
When I first worked with OT’s categories and understood how they related to content and served as metadata tables, I liked them (kind of a cross between custom object types and aspects in DCTM). Then I learned that if you add an additional value to a dropdown selection, not only do you add it to the category, but the system has to update all of the content metadata as well. Each document is coupled with the UI’s potential values in a dropdown selection box. This is mind boggling. OT’s solution to this is the turn off the modification trigger during the category “upgrade”. This makes me worship DCTM’s value assistance.
DCTM’s metadata inheritance model: the custom object type table inherits attributes from dm_sysobject. This makes the doc type, plus an ACL is associated to each object. UI metadata and document metadata are decoupled.
OT’s categories: all content is dtree content. A custom category is an “object type”. The category metadata and the content metadata are coupled.
As you can imagine this does not scale. One attribute value change in the category has to “upgrade” potentially millions of documents without actually modifying any of the content’s metadata.
Development/IDE
I never thought I’d say this but compared to LiveBuilder, Composer (with all of its bugs) is hands down a superior development environment and deployment tool.
DCTM: Eclipse/Composer
OT: LiveBuilder
UI customizations: WDK/TBO vs. Modules
MVC development in OT is more streamlined than DCTM but it’s more manual and awkward. Deployment of OT’s UI customizations straight forward, like DCTM it requires a web server restart. A bonus of OT is that you don’t have to shag after caches between deployment environments. Despite OT’s cryptic Oscript, I bet the learning curve to be productive in developing it is faster than the WDK.
As far as extending core methods in OT, you’re out of luck. As far as I can tell, TBO/SBO extension customization concepts were never introduced into the OT environment.
DCTM TBO, SBO, WDK: JSP/Configuration/Java Behavior class
OT Modules: Oscript/HTML
Webservices
DCTM wrote the iECM spec for service interoperability. Like DCTM, OT plans to expand and eventually only use webservices for all MVC requests and responses. CMIS adoption and use will slowly rise as large companies sunset their old repositories and bean count the new services into their road maps.
Users/Groups:
OT’s users and groups are keyed by a Number, in DCTM the key is the user/group name or String. Using a number allows OT to manage the changes in User names easier, however there is no such concept as a federation of repositories. OT is designed around a central repository user concept. Users created in one repository will have a different id than the same users in another repository, however the synchronization of AD between environments mitigates this issue.
OT KUAF: Number
DCTM User: String
Potential for Home Grown Mess
The maturity of a repository is directly related to how much resources and attention to ECM standards were governed during the repository’s expansion. If the users were in control of the folders, permissions and content, then chances are you have a mess of projects, permissions that do not scale, and outside URLs that point to the repository’s contents from portals and embedded in documents.
Somehow companies with DCTM seem to be more adept at realizing the limitations of performance and scale when it comes to the difference between consumers and contributors. Maybe it was Webpublisher’s adoption success over OT’s lame attempt at the same.
The concept of decoupling the consumer interface from the contributor’s is what web 2.0 is all about. But both camps have an uphill battle to convert repositories in flexible content architectures.
Storage Management
What can I say EMC owns Documentum and it was a beautiful purchase in terms of storage management. I leave it at that though. OT’s archiver is an after thought compared to the power of taking BCV snaps of servers. Of course only large companies can afford EMC storage solutions…
Developer Community
DCTM developer resources cannot be touched by OT’s. I’m glad I learned DCTM’s solution before learning OT’s. If you are like me and learn the most by examples, DCTM is heaven. Part of the issue is the OT didn’t seem to know that Oscript was a very limiting factor in terms of adoption of OT as a whole. They didn’t get that in-house OT administrators need ways to develop their skills beyond following installation and admin guides. Learning Oscript meant you were locked into OT’s vision and world, but DCTM, Oracle, IBM, etc were out there as well.
Each section above could be a chapter in a book, but this a blog and I only have so much time to elucidate some of the points of comparison. It's hard to compare a teenage to an adult, but it's my opinion that OT hasn't been able to mature as fast as DCTM. This puts it at a disadvantage in terms of competing with Sharepoint and 2.0 technical advances and User's expectations in of UI functionality. So, the ability to be nimble and move with the technical changes in the world will prove which repository is more ubiquitous in 5 to 10 years. Also, our friends the bean counters will help slow adoption of new technology and especially new ways to thinking and expressing ourselves within the corporation.
No comments:
Post a Comment