Documentum vs. OnBase part 1: Intro

Anyone who knows how to read a software feature matrix can compare line by line the details of functionality between two ECM systems. What I’d like to do is hone in on aspects of these comparisons which are fantastic or frustrating, and in some cases, mindboggling.

First, we’ll look at configuration, then we’ll look at using the tools.

Config: Document Types

In both OnBase and DCTM software packages, doc types run the UI show, that is, they function as the core of metadata, permissions, interoperability, functionality, forms, etc. When you do anything with content, you start with doc types. The underlying database and application designs for each app shows itself in the doc type configuration differences. Besides scaling and performance considerations, I’m guessing some copyright patents mess with the best ways to design certain functionality as well. I will show you some of these later.

In OnBase, there is a doc type group and a doc type, that’s it. You cannot create a hierarchy of types like in DCTM. This has many ramifications good and bad. This limits the potential for complexity, which plagues some DCTM object type designs. However, you can’t use doc types as an organizing factor for more than two levels of categorization in OnBase, which is annoying in medical records when you have hundreds of doc types and one doc type group called, “medical records”. Picture constantly having to scroll through hundreds of doc types for each search, retrieval, scan queue, etc. It’s not productive.

Change Management: A huge plus of OnBase is that you can version a doctype. This allows you to add/delete/change metadata and move on with the modified doc type definition, leaving the previous version with the old content. This is huge when you consider records and auditing. In DCTM, you would have to modify the existing doc type which would change all the previous content, or create a new doc type and migrate the old content. A real hassle if you've ever done it.

Config: Metadata

OnBase’s label for metadata is “keyword” which is confusing to most ECM folks as it can be associated to the Dublin Core metadata standard name of “keywords” which means any related term to the content being described. So, OnBase’s “keyword” really means metadata (attributes, or properties) of the document. In both, we have system level metadata like file path, size, format, name, etc.

Change management: Onbase has cool feature which allows you to set multidoc keyword changes on a keyword. This allows for changing values of a metadata across all docs. Of course, you can do this in DQL. DQL still remains a powerful tool for the right person, and a dangerous one for others.

Part 2 looks at relations in Document and Onbase and compares some of them.