Preparing for the Documentum Software Audit Part II: Understanding Audit Query Results

Published March 8, 2010 Documentum , Tech Tip Leave a Comment
Tags:

As mentioned in a previous post, many clients are struggling with software audits from Documentum and are revisiting how they are using Documentum within their company.

Understanding what happens in the software audit

The following are the types of questions that Documentum is trying to answer during a software audit:

  • Is there any anonymous access to the docbase?
  • Do all users/machines creating content have the appropriate Documentum license?
  • Is one machine being used to front-end a group of users that really should be licensed?

To answer these and other questions, Documentum will send a list of queries to the customer to execute in their environment.  To help users understand the audit, we’ve included a few sample queries below.  We recommend users execute these types of queries in their environment in order to verify their own usage, even as a part of regular system maintenance. 

Where is content being created from?

The following is one query that a client of mine executed and had concerns about after seeing the query results in their environment:

SELECT set_client, count(*) FROM dmr_content GROUP BY set_client ORDER BY 2 desc

According to the document provided by Documentum, this query will show what machines are being used to access the docbase. However, this query actually shows the machines from which content has been created in the docbase, not just from where the docbase has been accessed. 

The results of this query will return the names of the application server, the content server box, as well as the transformation server (if DTS has been installed). It may also return some unfamiliar server names or those that don’t seem like they should appear here. There’s a good explanation for these additional server names. If any other machine was ever used to execute a setfile or setcontent API command, maybe through Samson, or other API tool, that machine would appear in this list as well.  For example, your IT department might have needed to execute a setfile command to fix an issue with a document, and they could have done that from their own machine.

This particular client also had a row in their results that contained a blank server name as the set_client value, with a fairly large number as the total count. This obviously caused some concern for them, but after some investigation, we assured them that this was a perfectly legitimate value to have. It seems that the blank server name actually represents the content server, but it represents those times when the content server itself must have encountered a situation that caused the host name value to be lost or not accessible when setting the set_client property. 

In order to see what objects actually fall into this blank set_client category, run the following query:

SELECT r_object_id, object_name FROM dm_sysobject WHERE r_object_id IN (SELECT parent_id FROM dmr_content can WHERE set_client = ‘ ‘)

Most of the objects that are returned from this query are internal Documentum files, and drilling down even further shows that most of them are just job reports. It looks like the set_client property is blank for reports created by jobs that are set to ‘Run as Server’. It might be that the sessions are handled differently within these types of jobs, in a way that does not keep track of the client host name.

Who is modifying and creating content?

The two other queries that my client raised questions about were the ones that pull back how many objects have been modified by each user:

SELECT r_modifier, count(*) FROM dm_sysobject GROUP BY r_modifier ORDER BY 2 desc

And how many objects have been created by each user:                                  

SELECT r_creator_name, count(*) FROM dm_sysobject GROUP BY r_creator_name ORDER BY 2 desc

If the results of either of these queries show that dmadmin and the docbase owner have created or modified a lot of objects, there’s no need to be alarmed right away. When talking about creating objects, dmadmin will be the creator on all job reports and certain instances of workflow activities, so that will account for a large portion, which is perfectly normal. Dmadmin or the docbase owner will also be the creator on all out-of-the-box Documentum files or objects, so that takes up a big portion as well.

In terms of objects that are modified, dmadmin or the docbase owner can come into play in various ways. If there are any automatic workflow activities that are set to run as the docbase owner and the workflow method attached to that activity executes a save on the object at any point in its logic, then the modifier of that object will be set to the docbase owner. Dmadmin could be set as the modifier if any lifecycle actions are being executed on an object and the docbase has the a_bpaction_run_as attribute set to ’superuser’. If the value is set to ’superuser’, that means all promotes, demotes, etc. will be executed as dmadmin and therefore will cause the modifier on the object to be set to dmadmin. If there are any jobs set to ‘Run as Server’ and the logic in the job updates any documents, that will cause the modifier on those documents to be set to dmadmin as well.  Also, all job reports will have the modifier set to dmadmin.

Overall, as mentioned in a previous post, the Documentum software audit is something that clients can plan and prepare for as part of their regular system license maintenance.  In the case of my client, after working through the results with Documentum, the audit revealed no license shortfalls.

Please feel free to contact us if you have any additional questions about Documentum software audits.

Documentum and SharePoint – Key differences for document control applications

Published March 3, 2010 Document Control , Documentum , HPI , OpenContent , OpenMigrate , Search , SharePoint 2 Comments

We have recently begun working with a couple of clients on potential migration efforts from Documentum to SharePoint for their document control applications.  In preparing for these efforts, we are in the process of upgrading OpenContent, OpenMigrate and even parts of HPI to run on either SharePoint or Documentum.  For this post, we thought it might benefit those familiar with Documentum to understand the differences for a typical control application.

Search

Documentum users tend to be pretty proficient at using the Documentum search for finding the right information.  In a document control application, a typical search might be “show me all SOPs for any plant that include this equipment number”.  In Documentum, this would be a search on both attributes (SOP doctype, plant) and full text (equipment number) and could either be accomplished with Webtop Search, HPI or another search interface.  For SharePoint, the search is somewhat more difficult for a couple of reasons:

  • SharePoint is divided around “sites” with each site having a library.  In an instance where there are multiple plants, the administrator would have to decide whether to set up an “SOP” site with one library to enable this search (would leave the folder navigation very crowded) or a site per plant with libraries that contain more than just SOPs.  (would force separate searches on each site).
  • SharePoint doesn’t easily provide for cross-library searches with attributes.  Basic search is limited to full text but, like Doucmentum simple search, is just a Google-like full text search with search results.
  • SharePoint advanced search is available and is similar to Webtop search.  Users have to build a query; however, users don’t get pre-populated pick lists like in Webtop.   Also, SharePoint doesn’t natively support the idea of a “contains” search and defaults to an equals or does not equal search, forcing the user to have to type and spell the whole value correctly.  For advanced cross-library searches, all attributes (called properties in SharePoint) from any library are in one giant property pick list and not shared across libraries (doc type for one library would have to be named something different for another library or it would show up twice).
  • SharePoint search results only provide a “Google-like” result list – not the tabular, sortable format that Documentum and HPI users expect.   For example, being able to sort on an attribute column or download search results to Excel is not available in SharePoint.
  • SharePoint does not provide for saved searches like Documentum or HPI.

We are enhancing HPI Search with access to SharePoint via the SOAP APIs.  Like Documentum users, the ability to have a robust, configured search is a common enhancement for document control applications.

Document Retrieval – Support for PDF

As we pointed out in a previous post, Documentum users are used to storing a variety of document formats and doing retrievals, overlays, annotations and other functions on a rendered PDF.  SharePoint “out of the box” doesn’t really support the automatic generation/storage of a PDF rendition or the ability to add overlays for document header/footer/signature page like Documentum users are used to seeing with PDF Aqua or OpenOverlay.  While there is a strong add-on market for SharePoint (we are adding to it as well for this), those evaluating should understand that any rendition would be stored as a separate object in SharePoint and would require some type of training/customization to make sure the PDF rendition was viewed/manipulated for retrieval.

Document Storage and Navigation

Most Documentum users are used to a cabinet/folder metaphor .  For SharePoint, the concept of Site/Library might be somewhat similar.  As already highlighted above, deciding to create and SOP site or a Plant site will be a major decision with impacts through the design of the application.  The difficult part of SharePoint is that within a library, the applications forces “common” property views.  To take advantage of the interface, users need to set up views per document type.  Some other key SharePoint differences:

  • Security – Security can be managed on a document level but, out of the box, the security is  not tied to document status as is typically setup with a Documentum lifecycle and ACL.  For example, with a Documentum lifecycle, you can set up that users cannot update when pending approval, can not edit when approved/effective, but can edit in Draft.  In SharePoint, out of the box users can edit no matter what the document status value.
  • Renditions – as mentioned above, documents appear in their native format without the concept of a PDF rendition.
  • Office Integration – SharePoint has superior Microsoft Office integration to Documentum alternatives.

Workflow Review

Because SharePoint does not support document renditions, SharePoint workflow is more of a check-in/check-out process with track changes on whereas Documentum approvers typically review a PDF rendition and annotate/provide comments.  One concern about using native word tools is that reviewers can be too likely to be word-smithing  throughout  rather than reviewing content.  Also, the check-out lock limits parallel review.   Lastly, the lack of PDF support requires similar functions to insert header/footer into the word document giving the appearance that it might be editable.  We couldn’t get document name, version and status per our testing into the header.

Workflow Approval

The out of the box approval workflow still has check-out enabled.  Users should configure/customize SharePoint to remove that ability.  If users update approved document content after other approvers have finished, the integrity of the approval is lessened.  Editing during the workflow works for document review, but not a true approval process.

Electronic signatures are not supported out of the box.  If you want to capture a user’s signature, you have to insert a signature object into the Word document.  SharePoint does audit and provide adequate reporting status tools.

Final Thoughts

Overall, most Documentum users will see SharePoint as a “light” ECM tool and, from what we have experienced, will be frustrated with certain functionality and how best to incorporate their process for managing controlled documents.  Please add a comment or contact us with any thoughts or questions you may have.

Documentum Upgrade – Understanding all the Pieces

Published March 2, 2010 D6 , D6.5 , Documentum , OpenOverlay , Upgrades Leave a Comment

As mentioned in previous posts, many clients are struggling with the upgrade to Documentum 6.5.  Typically, the upgrade of the Documentum components are only one piece of what can be a difficult puzzle.  Upgrading servers, operating systems, databases, and document manipulation services all add a level of complexity and coordination.  This post will highlight typical components/functions and TSG’s thoughts and recommendations.  Thanks to the clients (you know who you are) that contributed so much of the content to this post.

Database/Docbase/Operating System

Most clients determine to upgrade all other server components during the upgrade.  Some general guidelines:

  • Consult the Product Information System on Powerlink.
  • Don’t look to the absolute latest version of your database (Oracle, SQL Server) as Documentum support is typically added later.
  • Avoid the “small boat” or limited user base.  Examples include AIX and HP-UX Operating System, and Sybase or DB2 Databases.  Our clients have struggled with support or other issues that are unique to these platforms.  When in doubt, we recommend Linux, Sun Solaris, or Windows for server operating system, Oracle or SQL Server for Database and Tomcat or potentially WebLogic for the application server.   Some results from a quick production environment poll Documentum conducted for 460 customers who had acquired D6 or D6.5
    • 54% use Oracle, 32% SQL Server, 14%, Other (DB2 or Sybase)
    • 50% use Tomcat, 23% Weblogic, 14% Websphere, 13% Other (Oracle or Sun)

Server Hardware

In the old days, the cost of the servers (we saw a lot of Sun) was a huge component of the infrastructure.  With clients moving to Linux/Windows more and more, it is easier and less costly to upgrade the server hardware.  As mentioned in a previous post, upgrading to new servers simplifies the upgrade process as it provides more flexibility in regards to fall-back and timing.  From a cost perspective, we have been recommending Linux both for internal as well as cloud options.  One caveat in regards to Linux and HP-UX Itanium, make sure the content server supports eSignature manifestation if that is one of your requirements.  As of this post, Documentum, leveraging PDF Fusion, does not support eSignatures on these platforms.  We are working with a client to substitute OpenOverlay for their environment.

High Availability

Closely tied to server architecture is high availability.  Many clients are looking at clustering given the price of new servers/OS (particularly in the Linux world), as well as just better practices, particularly virtual machines.  Clustering, Load Balancing, Oracle RAC and other options should be thought through during the upgrade process.   Work with your infrastructure teams to build HA into your architecture as you build the new system.

Webtop 6.5

Moving from Webtop 5.2.5 or 5.3 to Webtop 6.5 typically has the most impact of the architecture components.  Issues with the Webtop upgrade include:

  • Upgrading Customizations – depending on level of customization, this can be a major undertaking.
  • Upgrading Add-on components – as mentioned later in this post, 3rd party Webtop components such as annotation tools, PDF Overlay and other WDK add-ons will mostly likely need to be upgraded to support the target Webtop version.

We typically recommend clients move to the latest Service Pack 1 version or above (ex:  Webtop 6.5 SP1, SP2 or beyond) as the initial releases can be tricky as we learned with 5.3.

Annotation

For many clients, this can be a complicated decision.  Factors include:

  1. Existing Annotations – if the migration/upgrade requires access to existing annotations, the new system will have to be able to read them.  Some annotation tools store the annotation format in their own proprietary format and can’t be read by other tools.
  2. Documentum PDF Annotation Services – as part of the upgrade, many clients would like to move to annotation services from Documentum.
  3. Other Tools – Clients disappointed with current tools can look at PDF Annotation  services or a variety of other tools (Snowbound, Brava) however be sure to check Webtop version support as not all annotation tools support the latest version of Webtop and service packs.
  4. Cost – Tools aren’t cheap and typically require a license per user.
  5. Support – Many tools require a client side add-on which can be difficult to deploy and maintain across a diverse client base (and potentially different browsers).

We have worked with clients to upgrade annotation tools as well as release a free viewer/annotation tool with OpenAnnotate (coming soon) to give clients additional flexibility.

Lastly, TSG recommends looking at how annotations are used.  Many times the requirements don’t call for annotations but more general rejection comments.  We typically do not recommend that clients leverage annotation tools for an editorial (grammar and wording) review.  A better approach is to use Word “Track Changes” within a review cycle that doesn’t require annotations but more of a check-in/check-out of the Word document.

PDF Overlays

In a controlled document system, metadata from Documentum (document number, release date, document title…) must appear correctly on the header/footer of released documents.  Clients that have committed to PDFaqua are going to face the conversion to PDF Stamping Services in Webtop 6.5 due to our understanding (as of the date of this post) that PDFaqua will not be supported in Webtop 6.5.

Similar to annotations, TSG does offer a free overlay tool, OpenOverlay, that has been very successful in replacing PDFaqua leveraging iText.

Full-Text Search

While Full-Text search comes free with Documentum, clients need to remember that server (potentially new servers) infrastructure is required with FAST or the upcoming Documentum Search Services.    We typically recommend proof of concept activities to determine how to manage the index server when it comes to typical index maintenance (index rebuild) as it will affect the upgrade process.

WDK or DFC Applications

As we pointed out in a previous post, WDK applications will need to be migrated/rewritten depending on the level of customization and complexity.  Applications written on the DFC have proven to be easily upgradable.  Be sure to verify how many external systems are pulling or pushing content from your content server.  Are they using DFC to communicate?

Check your Licenses

As most users are aware, Documentum’s price list is pretty large and can be somewhat confusing.  Software licensed under an old model (user, named user, CPU) is not currently supported by Documentum and can leave you vunerable to an software audit. Use an upgrade as a chance to review your license structure and usage.  If you move to virtual/cluster/etc, does your licensing allow for this type of support?

Browser and Java Support

Double check the release notes in regards to client, browser and Java support.  For most of our clients, Documentum has supported the major browsers and recent Java versions.  One issue some clients have in regards to external users (extranet) is that the client browser doesn’t always meet Documentum specifications.  We’ve had some clients’ plan their 6.5 upgrade but forget to upgrade their JRE to 1.5 or 1.6, causing problems.

Rendering

Users should check on their Document and XML rendering engines – are they yet 6.5 certified? (Our understanding is Liquent is far behind and was recently purchased (again).  Documentum products (ADTS, DTS) are probably not so much an issue.

Eclipse – Don’t leave the developers out

Documentum 6.x uses Eclipse as the foundation for development (rather than DAB).  If you’re not an Eclipse shop, or if you’re not already standardized on it, look to get everyone standardized and trained now, and look into Eclipse plug-ins for your common development tools (source code tools, analyzers, etc).

Performance Analysis

One of the new features with Webtop 6.5 is the ability to leverage web performance analysis tools.   Look into if your architecture group has standards for those tools, and look to leverage them into your implementation plan to performance/load test your new 6.x environment.

Documentum – What’s Next Updated for 2010

Published February 23, 2010 Active Wizard , Adobe , D6 , D6.5 , Documentum , ECM Landscape , Flex , HPI , OpenMigrate , SharePoint , Upgrades 3 Comments

Back in 2007, we started offering a presentation for clients, “What’s Next for Documentum?”  The presentation focused on what mature Documentum clients are doing “next”.  Typically, mature customers:

  • have an existing production install of Documentum
  • have implemented tools “out of the  box” with some or extensive customizations
  • have had some success
  • ….and are looking for “What do I do Next?”

This post will share new, innovative or just different items we see our clients doing or considering for Documentum as well as links to other posts that depict their choices.

Documentum Upgrade – When?

When to upgrade is a difficult decision for many clients.  Many existing Documentum clients are on paid support (version 5.3 or before) this year given reduced budgets, the cost of the upgrade, the effort of the upgrade combined with the difficulty of upgrading their application that either is unsupported or would require re-write to leverage the new Documentum interface.

For an overall upgrade understanding – try our Documentum Upgrade Planning Guide.

Look throughout blog.tsgrp.com for many posts including upgrade alternatives, extends versus modifies in 6.5, understanding the impact of WDK development, migration, clone or in-place upgrade, high volume server, common upgrade questions, and upgrading your application now to make upgrading Documentum easier later

External Users – Extending capabilities beyond the firewall

We have seen a push to add additional third parties or external users to Documentum.  Typically this would be a related party responsible for creating of Documents.  Interfaces are somewhat different in that, while they can create/approve documents, the interface should limit the third party from only seeing documents or completing a limited set of functions.

SharePoint – 2010 increases pressure on Documentum

SharePoint continues to be a major influence at the bulk of our clients.  SharePoint users can be very vocal in their desire to “dump Documentum”.   Clients struggle with wanting to satisfy SharePoint users but understand that a typical SharePoint environment focuses on collaboration with collaboration being very different from the current Documentum installation.  Providing the scale, image and records management and maintaining indexing consistency are all requirements of most ECM systems and something that SharePoint 2007 can’t always accomplish.  As Microsoft releases SharePoint 2010 with more robust ECM features, we would anticipate that this pressure would increase.

Look throughout blog.tsgrp.com for many posts including  SharePoint Myths, SharePoint – Adding ECM Structure and Active Wizard/SharePoint Integration.  Also, look for OpenMigrate to have continued support for a SharePoint source as well as the upcoming release to support an SharePoint target.

Documentum Software Audit – Managing Licenses

While this is not new in 2010, we but have steadily seen an increase in EMC Software Audits since 2005 with a big increase in the 4th quarter of 2009.  Clients are getting better at documenting system usage and working with their sales reps to actively manage their license and maintenance costs.

Article – Preparing for the Documentum Software Audit

Consumer Interface – Continued Focus

Multiple clients are continuing to look to push content out of Documentum for consumers.  Whether tied to fault tolerance, performance, upgrade prep or licensing, many have developed strategies to push released content either with SCS or OpenMigrate to an external DataBase and file store.

WhitePaper available here

Non Webtop Interfaces – Less Training – better Performance

Similar to the consumer interface, we are seeing more “non-Webtop” interfaces begin to proliferate at clients.  Initially this was focused on image, workflow or improving Documentum search within Webtop.  Recently, typical Webtop installations are looking to move certain users, like the consumers mentioned above, off of Documentum Webtop.  This could involve just approvers (both internal and external) or offering a simpler author interface.

TSG’s HPI Solution for this approach

Lucene – FAST/Verity Replacement and DSS

Many clients are tired of “waiting for Documentum Search Services (DSS)” and have begun to deploy Lucene internally for either a cached consumer repository or Documentum itself.

Documentum Search – Lucene, FAST, Verity, Google and upcoming DSS

Look for a post here on one client’s comparison of FAST to Lucene given their content and search scenarios.

CenterStage, Cloud, CMIS, Fatwire – what do these mean?

We have seen clients considering CenterStage, utilizing the cloud (ex: Amazon EC2), the upcoming CMIS specification as well as concern about recent Fatwire alliance.  Most of our clients are taking a “wait and see” approach given the economy and some concern about being early adopters rather than followers.  We’ve seen this same approach with the upgrade decision as well.

Other “what’s next” items include of Adobe Flex to create a better user interface, form and workflow enhancements, browser based annotation services and other items that will be posted here In the coming months .  If you are looking for our 2007 “What’s Next” presentation, a Screencam with sound is still available on our site.

Creating Active Wizard Forms Outside Documentum – AWLite

Published February 23, 2010 Active Wizard , Adobe , Flex , Open Source Leave a Comment

Clients who use the Active Wizard for forms and workflow systems often wonder if third party users or other users outside Documentum can participate in the form creation process.  With our new Active Wizard Lite (AWLite) product, it is now possible for non-Documentum users can easily fill out dynamic Active Wizard forms!

We’ve seen the following scenarios over the past few months:

Anonymous External Users

One of our current Active Wizard clients is now using AWLite for filling out building permit application forms.  Any user with internet access can fill out an Active Wizard form through AWLite on the client’s website.  The potential user base is unknown, so it makes sense to fill out this form outside Documentum.  Since AWLite simply uses a file system and SQL database to store form data, the client does not need to grant anonymous access to Documentum.

Third Party Form Creation

Another Active Wizard client gathers data and supporting documents from an external third party agency to create forms.  Without Active Wizard Lite, communication bounces back and forth in order to gather the necessary data to create the form.  With AWLite, however, the third party users can simply fill out the form outside Documentum.  OpenMigrate is then used to move the data from the AWLite environment to Documentum, where the Active Wizard users can review the form, make any necessary changes and start the workflow:

Overall, TSG is very exited about our new Active Wizard Lite offering.  Benefits of using AWLite include:

  • Small back-end footprint – AWLite does not rely on Documentum. AWLite can simply use a server file system and a SQL-compliant database to store form data.  This back-end architecture is much easier to setup and maintain, and can be achieved using entirely Open Source software.
  • Licensing – in both of the cases above it did not make sense to add Documentum user licenses for the users creating forms.  By using AWLite, the clients avoid needing additional licenses, while also avoiding anonymous access to Documentum.
  • Next-generation interface – AWLite uses our next-generation user interface based on Adobe Flex.  The flex interface is easy to use, interactive, and cross-browser compatible.  Plus, AWLite behaves more like a desktop application – for example, server communication does not involve page refreshes and field validations happen in real time.

To see Active Wizard Lite in action, check out the Active Wizard Lite demo in the TSG Learning Zone!

Update on OpenMigrate Qumas Migration

Published February 22, 2010 Documentum , Open Source , OpenMigrate , Qumas Leave a Comment

I posted an article a few months ago on TSG’s migration to Qumas using OpenMigrate (OpenMigrate Supports Qumas). We have now successfully run the migration through QA and are prepping for the production migration in a few weeks. I’m happy to report that the QA (Test) run executed successfully and smoothly (smooth is sometimes more difficult than successful!). The Qumas software adds hundreds of other Qumas-specific objects & tables that need to be analyzed for impacts when performing the migration. I would like to share a few lessons that we learned. These lessons really apply to any migration:

  •  Don’t underestimate the mapping effort when moving to a new object model. This migration also involved mapping old content into a new model. The assumption going in was that the mapping could all be done programmatically. This was incorrect and tens of thousands of documents needed to be manually mapped. Mapping and the management of the data mapping took a significant amount of effort
  • Do not underestimate the complexity of working with a new object model/database structure. As stated above, Qumas adds hundreds of tables on top of the Documentum structure. On our test runs in a sandbox environment every time we thought we had the dependencies figured out, something unexpected popped up and back we went to the database to understand the inter-dependencies.
  • Perform a full test run whenever possible. Many scenarios are not uncovered when only mapping a subset of the data. I would highly recommend performing a full migration in development. We did follow this advice and I believe this was key to a successful (and smooth) run through QA/Test.
  • Open Migrate is extremely versatile! After the table dependencies and all impacted data fields were figured out, we were able to perform this migration with minimal updates to OpenMigrate. Updates to OpenMigrate included extending the product to support a translator or Rosetta look-up table and support for calling the Qumas auto-number table.  After using OpenMigrate to do migrations to/from FirstDoc and now Qumas I’m convinced it would work well with any ECM solution or add on component.

Happy Migrating!

PDF Annotation Tools That Work Beyond Documentum 5.3

Published February 18, 2010 Adobe , Annotation Tool , D6 , D6.5 , Documentum , HPI , Open Source , Upgrades , Webtop 1 Comment

Over the years, a variety of software tools have become available for integrating PDF annotation functionality into the Documentum client suite.  Some of these tools include Brava!, AnnoDoc, Snowbound, and Documentum PDF Annotation Services.  Each product has its own feature set, but all provide the ability to mark up PDF documents and store the annotations alongside the document in the Documentum repository.  Each product has a client component that integrates with Documentum Webtop to provide the tools for adding markups to documents.  These client integrations utilize proprietary applets, Adobe Acrobat, or Adobe Reader with Extensions to provide this functionality.

Recently a manufacturing client requested help from TSG for replacing a legacy AnnoDoc system with another solution.  The most current release of AnnoDoc works with Documentum Webtop version 5.3, but the product does not support Webtop version 6+.  With Documentum 5.3 reaching end-of-life, the client was looking to upgrade to version 6.5, but an annotation solution needed to be found first.

Ideally, the client needed an annotation tool that could both read and update annotations made using the legacy AnnoDoc system, as well as provide the ability to create and save new annotations.  After some research, it was discovered that AnnoDoc and Documentum PDF Annotation Services use similar methods to store annotation files in the Documentum repository.  Both products store the annotation files as dm_note objects related to the original PDF document using the DM_ANNOTATE relation type.

While similar, there were still some challenges in getting Documentum PDF Annotation Services to open annotation files created with AnnoDoc.  AnnoDoc stores annotations in the Forms Data Format (FDF) while Documentum PDF Annotation Services stores them in the XML Forms Data Format (XFDF).  Although Documentum PDF Annotation Services is able to read FDF files, small changes needed to be made to the FDF files for the system to function properly.  Running a custom developed command line script to update the legacy FDF files proved to be a viable option for migrating the client from AnnoDoc to Documentum PDF Annotation Services.

TSG has recently made efforts to develop an annotation tool that will not require clients to have the full version of Adobe Acrobat to create annotations.  The tool is slated for integration with Documentum Webtop and OpenContent HPI.  Stay tuned to the TSG website for details on TSG’s OpenAnnotate product coming soon!

Documentum Upgrade Alternatives

Published February 17, 2010 Active Wizard , D6.5 , Documentum , HPI , OpenMigrate , Upgrades 1 Comment

I was talking to a client yesterday struggling with decisions on upgrading Documentum.  Currently the client is on Documentum 5.3 SP5 and is paying EMC for additional support since 5.3 SP5 is no longer supported under standard support.  This is not an uncommon situation with many Documentum clients for some of the following reasons:

  • Over the history of the Documentum installation, many customizations have been made to the system that would require rework in order to upgrade to Documentum 6.5.
  • Other components in the upgrade/stack would require upgrade to Documentum 6.5 as well.  This could include annotations, database, server operating system,  PDF Watermarks, full text indexing and other difficult to coordinate components.
  • Reduced IT budgets have made the cost of the upgrade prohibitive.
  • Business users are not sure what benefits they will get for the cost, risk and disruption of the upgrade.

While the answer isn’t easy, I thought I would use this post to highlight some alternative approaches that clients don’t always consider and highlight some of the costs and benefits.

  • Never upgrade without a business justification – One major life-sciences client has taken this approach given the huge amount of investment in their current 5.3 implementation.  While they are paying for additional support from Documentum now, they are not concerned at being out of support given the knowledge within their team as well as having a support agreement with TSG in place.  Another client went from 5.2.5 to 6 (skipping 5.3 entirely) for the same reason.  The client estimated they saved at least $1,000,000 by skipping a release without any lost business functionality.
  • Make the system more easily upgradable – Another 5.3 client is working on application changes on Documentum to make the system easier to upgrade.  This includes removing most of the Custom WDK/Webtop interface components in favor of a consumer driven interface based on HPI and Lucene,  as well as  a new approval interface with the Active Wizard.  The applications work both on the existing Documentum 5.3 instance and Documentum 6.5 and will ease the clients application upgrade effort.  Another post for this client is located here.
  • Upgrade just the backend – Most clients only consider upgrading ALL of Documentum from 5.3 to 6.5.   (Webtop and the Database/Repository).  From reading Documentum Upgrade and Migration guide on Powerlink, Documentum does support Webtop 5.3 with a Documentum 6.5 backend with a few tweaks.  For certain situations, this approach might make sense including:
    • Support – Most of our clients really want Documentum support for the back-end (DB, Repository….) when things go really wrong.  Front-end support of Webtop especially given customizations, is difficult for Documentum and not always needed by clients or supported by Documentum.
    • Performance – Documentum 6.5 does offer performance improvements providing benefit with the back-end upgrade.  Also, clients look to either replace Verity/FAST with Lucene or other performance improvement components associated with the back-end.  
    • Upgrade Gradually – With the back-end upgraded, clients can pursue a case by case or department by department upgrade rather than a big bang.  For our client that had 10 different instances of Webtop, this makes sense as the easier ones can go first and gradually other applications can be upgraded if necessary.
  • Move platforms – Unfortunately, the cost of the Documentum upgrade can also result in pursuing a strategy of changing platforms.  The argument would follow that “if it is going to cost this much to upgrade Documentum, why not just change to another vendor for the same price”.  This can be especially true after a difficult software audit.  While we are big fans of Documentum from a software platform and ECM capabilities perspective, we do understand the cost of support/upgrade that can result in a new platform.  Look for a later blog post for a client that moved 300 gigabytes from Documentum to Alfresco within the Amazon Cloud.

Please comment below your thoughts/experience in regards to any of the above.

Next Midwest EMC-Documentum User Group Meeting – April 9th

Published February 16, 2010 Documentum Leave a Comment

The next Midwest EMC/Documentum User Group (MWDUG) meeting was just scheduled for April 9th in downtown Chicago. We try really hard to plan good, worthwhile meetings for our members.  Below are a few guidelines that we follow to make sure our members find it valuable. If you are interested in becoming a member or receiving detailed meeting information (agenda, registration info, etc) please see my address that is posted on the MWDUG website (www.mwdug.com). Hope you can join us!

  • Presentations by End Users – We require that all presentations are given by end users. If vendors or integrators want to present they must do so with an end user. This results in more case study presentations rather than presentations that are focused on a sales pitch .  At our typical meeting one presentation is given by EMC and the other 4 are given by end users.  As an organizer, it is much more difficult to get end users to present but definitely worth the effort in the end.
  • Mix of Technical & Business Information – Our attendees typically have a mix of business and technical background. So presentations are geared towards users who are interested in the technology as well as the business application of that technology.  We make sure all technical presentations have a business context and all business presentations have some relevant technical information.
  • Scheduled Networking Time – It is nice if networking time is scheduled in the middle of the meeting rather than at the beginning or end of the meeting. If the network time is scheduled at either end of the meeting people tend to show up late or leave early – defeating much of the purpose of a user group meeting.  At our MWDUG meetings we schedule a short networking time (15 minutes) in-between each presentation. We also extend the lunch period so users have a chance to network with others. Some meetings have even scheduled specific break-out topics.  I have seen multiple members of our group use this networking time to figure out industry best practices, solve a very specific problem and find a new job!
  • Strong Regular Attendance – The MWDUG user group meetings consistently have 75-100 attendees – and a vast majority of them are repeat attendees. We believe the high repeat attendance is because people find the meetings valuable – so if you are in the Midwest area, come check out the next user group meeting on April 9th!

Documentum, Alfresco and SharePoint – Dispelling the Microsoft ECM Myths

Published February 15, 2010 Alfresco , D6 , D6.5 , Documentum , ECM Landscape , Open Source , SharePoint 4 Comments

Most of TSG’s Documentum and Alfresco clients are evaluating Sharepoint as a portal to ECM or to satisfy some of their ECM needs.  While TSG has always provided Sharepoint connectivity to ECM with OpenMigrate, ActiveWizard and OpenContent as demonstrated in the links below,

Active Wizard

OpenContent

OpenMigrate Sharepoint Source

many of our clients are asking “Hey, why not just use SharePoint instead?”  One recent client just finished an effort leveraging Sharepoint for ECM.  For this blog entry, I thought I would share some lessons learned as well as dispel some of the Microsoft Myths:

  • Myth #1 – Personal ECM – Much of SharePoint’s success is due to the easy nature of setting up a personal library or group space for collaboration.  As with Documentum’s eRoom product, this is typically a collaborative environment that empowers users to do something “fast” to share documents.  Is this really ECM?  Typical ECM customers have enterprise goals in regards to consistent taxonomy, security and indexing that a “quick and dirty” SharePoint library will not meet.
  • Myth #2 – Microsoft can Scale – For our client, SharePoint broke down and required additional indexing somewhere in the 5,000 to 10,000 document range both for performance and user navigation.  For most of our clients, 5 to 10 thousand documents is typically just a portion of their enterprise repositories.
  • Myth #3 – Market Share is important in the decision process – The logic would follow that large vendors are in a better position to offer a better product and long-term decision as compared to smaller, more niche driven vendors.  Microsoft, as a huge vendor with a dominant client base, would seem to be positioned as the best ECM solution.  Decision makers should keep in mind that much of the success of Microsoft SharePoint has been in the extension of Microsoft Office/Outlook and focused on collaboration, not necessarily in true ECM.  Does the number of installed seats of a product really mean anything if it is not being used for ECM and just for collaboration?
  • Myth #4 – Microsoft is Open – While it is easy to say that other document types can be stored in Microsoft (PDF for one), it should not be confused with the fact that Microsoft tends to lean toward their own products.  For example, many of our clients store Word Documents but have renditions available in PDF.  SharePoint doesn’t support this  “out of the box” as with Documentum.  In regards to futures, we would anticipate that Microsoft would continue to support their products first (Microsoft Mobile versus iPhone/Android) as the platform evolves.
  • Myth #5 – Microsoft back-end is “free” –Many times, initial use of SharePoint is because the client got it “free” with Windows Server.  It is important to understand that SharePoint is dependent and will always be dependent on a Microsoft back-end which will have a cost for true ECM implementations.  In particular, it is important to understand which items Microsoft will never support giving their “franchise” of Windows and Office and the cost implications including:
    • Linux Support (will always be Windows Server)
    • Database Support  (will always be SQL Server)
    • Development Support (will always be .Net and not Java or other technologies)
    • Complete support for non-Microsoft formats (PDF and XML as examples).  Will always have a preference to leverage Microsoft Office products and platforms.

If you have any comments/stories that either support the above or differ, please add a comment below.   Keep in mind that we are not saying SharePoint can’t be used for ECM, just hoping to share our thoughts on how ECM differs between collaboration tools like SharePoint and ECM tools like Documentum and Alfresco. 

Categories