• Its tendency to lag behind in release dates compared to the rest of the product stack, evident with the late release of the 6.5 version
• The general difficulty clients have had in upgrading between major releases.

This post will discuss some of the things to look for when considering the upgrade to 6.5.

Complexity of the DCM 6.5 Upgrade

The complexity of any DCM 6.5 upgrade varies dramatically based on the current version.  The upgrade is simpler for those who already went through a major upgrade to get to DCM 5.2.5 or 5.3.  For those who are still on a pre-5.x version of the product (e.g., based on Desktop Client or WorkSpace) the upgrade can be very complex.  Users moving from pre-5.x versions will need to perform some re-architecting to move into the new framework and while the scope of that re-work is beyond this blog post, most who have undertaken it already would likely say it is not insignificant.

For users currently on the DCM 5.3 release, the overall upgrade should be much less painful.  The core 5.3 framework items (Business Applications, Document Classes, Lifecycle Extensions, etc.) remain the same in DCM 6.5 and there are only a few changes that will require a closer look:

1. Watermarks – PDF Aqua is no longer included with DCM 6.5 and watermark functionality is now delivered through Documentum PDF Stamping Services (PSS).  This means the PDF Aqua templates and policies for applying watermarks have to be implemented from scratch in PSS.  Documentum does not provide a migration tool for moving from Aqua to PSS at the current time.
2. Controlled Printing – This is the ability to restrict printing of documents (e.g., only to certain printers or by certain people).  Not everyone implemented this in the past, but it used to be supplied by Aqua but is now a module of PSS in 6.5.  If Controlled Printing is in use, the configuration would have to be rebuilt with PSS.
3. Electronic Signatures – Similar to watermarks, there is a new mode for creating the PDF signature page in 6.5.  This means any signature page templates need to be re-worked into the new model.
4. Application Customizations – There are minimal new DCM specific UI items so the majority of interface changes are inherited from Webtop 6.5.  What this means is if the implementation has a lot of WDK-based configuration or customization of the 5.3 interface (e.g., removing buttons from screens, etc.) then these updates would need to be evaluated to make sure those WDK components still exist in 6.5, have the same configuration options, etc.

What this typically means is the DCM 5.3 to 6.5 upgrade looks like a lot of other Documentum upgrades regarding application (WDK) customization, with the addition of items around reconfiguring watermarking, electronic signatures and controlled printing.  How much additional complexity that introduces will be driven by how much this functionality was used – for example moving 5 watermark policies from Aqua to PSS will take less time than moving 50 watermark policies.

Are There Other Concerns?

The primary additional concern from clients has resulted from EMC announcing the following at EMC World this year:

• They are not investing in Documentum WDK applications
• DCM features will eventually be part of the core product

Many clients are wondering if they should upgrade to 6.5 at all.  As we have mentioned in other posts, some clients have remained on the 5.3 release either paying for additional support or not paying for support.  For DCM clients with a stable application, reasons to consider delaying the upgrade include:

• Cost of the Upgrade (effort, PSS configuration)
• Risk of errors with a new system (stability, training)
• Similar Functionality between 5.3 and 6.5

Clients should evaluate their current installation and consider if adding better functionality to their current infrastructure would provide more benefit.  Innovative clients have added consumer portals and PDF Aqua Replacments to their current installation both in preparation for an eventual upgrade as well as to provide immediate business benefits for their existing client base.

Conclusion

When examined from a technical standpoint, upgrading to DCM 6.5 should be a manageable process on par with other Documentum upgrades provided the upgrade is from the DCM 5.x product.  Prepare for more work, potentially a lot more, if it is from a pre-DCM 5.x release.  Regardless of the technical feasibility, in light of the uncertainty over the future of DCM, it will also be useful for clients to consider the ultimate costs of upgrading against other options available depending on how much DCM functionality they currently utilize and needs for delivering additional functionality to their customers.

If you have any questions, concerns or thoughts about your DCM upgrade, please attach a comment.

This post was developed based on recent work for a major pharmaceutical client.  The client, on Documentum 5.3, was developing a consumer interface application leveraging Lucene.  As we mentioned in a previous post, the client chose Lucene over FAST based on benchmarking results for over 150,000 documents.

Background

For the application, the client was leveraging OpenMigrate with DFC 6.5 to retrieve content and metadata for nearly 1,000,000 documents from their 5.3 docbase to be indexed in Lucene.  Per the product release notes, using DFC 6.5 to access a 5.3 repository is a supported configuration.  An issue was identified when around 5,000 documents failed to migrate.  In reviewing the error logs from OpenMigrate, the DFC call IDfSession.getObject() to retrieve documents from the repository resulted in errors.  After reviewing the stack trace, it was apparent that the error was being thrown from within the DFC code.  The team was surprised by the error since the documents were able to be retrieved without a problem using client applications working with a 5.3 DFC, such as Webtop and Samson.  The DFC error messages that were encountered are shown below:

[DFC_OBJPROTO_BAD_NUMBER_FORMAT] Invalid number format for string length in serialized object

[DFC_OBJPROTO_BAD_STRING_FORMAT] Unknown string format in serialized object

After some further investigation, the team noticed some similarities in many of the documents that were failing to migrate.  All of the documents contained metadata with special characters.  After duplicating the error in a development environment, the team removed the special characters from the metadata, retried the migration, and the documents were retrieved successfully with DFC 6.5.

DFC 6.5 and Character Encoding

Upon review with Documentum support, it was noted that DFC 6.5 enforces character encoding more strictly than DFC 5.3.  This explained why the documents could be retrieved successfully with 5.3 client applications but not with DFC 6.5.  The team wondered how these documents were ever stored in the repository with invalid character encoding.  Our best guess was:

• The documents were moved into the repository as part of a migration effort that took place a long time ago.  Most likely the loose enforcement of character encoding by legacy versions of the DFC was the culprit.
• Users may have set metadata values on documents by copying and pasting from other applications, such as Microsoft Word, that may have used a different character encoding.

Since the client wasn’t upgrading, only indexing the content in Lucene, the client decided to swap out the DFC 6.5 that OpenMigrate was using for DFC 5.3 in order to complete the migration.  Unfortunately using DFC 5.3 requires a more invasive installation process that the client was trying to avoid.  When the client upgrades to 6.5, the issues with the 5,000+ documents will be addressed.

Character Encoding and Affect on Upgrade

This particular client was fortunate enough to be able to “test drive” DFC 6.5 with their process that indexed to Lucene.  This migration uncovered an issue that would have been significantly more serious had the client upgraded their entire Documentum system to 6.5.  Had the upgrade been completed, users would not have been able to access these documents with the upgraded Documentum client tools such as Webtop, or any other custom applications utilizing the DFC.  Since the number of documents with the character encoding problem is relatively small in relation to the total number of documents in the system, they might have gone unnoticed during testing.  Because of the migration, the client is now able to come up with a proactive plan to rectify the issue prior to their full Documentum 6.5 upgrade.

Possible Resolutions

To identify the errors issues with existing data such as the character encoding problem described above prior to an upgrade, TSG would recommend several alternatives:

1. Consider leveraging OpenMigrate or a similar application to “scan” your data with DFC 6.5 to determine if any encoding errors exist prior to the upgrade.
2. During the upgrade, use OpenMigrate to migrate data into a clean repository instead of performing a typical in-place upgrade or dump and load.  Migrations are a great opportunity to “scrub” and validate existing data.  Because every document is touched during a migration, corrupt data can be more easily identified.
3. Utilize database tools to help identify potential problems.  Oracle has a Character Set Scanner Utility that can scan an entire database to verify that all data stored in the database use the correct character encoding.

Check out TSG’s free Documentum upgrade planning guide for additional upgrade tips.

Documentum Health Check Components

• Documentum Licensing – Many clients have us collect data regarding user counts and licensed software in use as the data may be necessary data to preparation for an EMC Software Audit.  Typical findings include anonymous access (not allowed) and over deployment (LDAP  creating too many users that aren’t using Documentum).
• Capacity/Performance Review – This activity verifies the current and planned environment will meet current and future needs.  Typically we find clients buy excess capacity on the initial purchase but quickly consume those resources as the system is deployed and extended over time.
• Backup and Recovery – Evaluate backup and recovery plan and execution.  Typical findings include:
  • Content and Database backup not in sync making point restore difficult
  • Restore Process has not been tested recently
• Documentum Upgrade Strategy Review – Review the plan for upgrading servers (new environment or existing), approach (in-place, clone or migration) as well as timing.  Typical findings include proper identification of downtime or need to test the process thoroughly.
• Documentum Administration Health Check – Verify active Documentum jobs and results.  Typical findings include:
  • Unnecessary jobs (ex:  dm_ContentReplication if not using distributed filestores)
  • Infrequent review of jobs success/failure/error logs
• Database Performance – Typical findings include need for addition/removal of indexes.
• Managing File Stores – Typical findings include full file stores (additional space is best for storing versions and renditions close to original content).  File Stores should be managed to have some excess space.
• Managing ACLs – Many clients have evolved their ACL strategy over time.  Typical findings include overuse of ACLs and difficulty maintaining security rules as they evolve.
• Audit Improvements – Documentum allows for certain events to be Audited.  Typically this is either disabled (and could be set on limited) or overused.
• Object Model Review – Typical findings include an evolved object model that might benefit from restructure if a migration upgrade is planned.
• Lifecycle and Workflow Review – Many clients want outside parties to review their use of Lifecycle, Versioning, Object Model and Workflow for usability, maintenance and performance.  Typical finds are that all components have evolved over time and might benefit from a fresh start.
• Content Management Best Practices – we will typically share other best practice approaches with clients when appropriate.  Best practices include:
  • Simplified Search and Retrieval
  • Configurable Systems development
  • Caching of approved content for non-Documentum users
  • Web Based Scanning Alternatives
  • Workflow Simplification
  • Web Services
  • Additional Admin Tools

Challenge One:  A Very, Very Old AIX Server

First we found that the FileNet server they were using was a very old AIX machine, and that the latest version of Java supported on that version of AIX was Java 1.1.  OpenMigrate (OM), on the other hand, had only been run on Java 1.4 and Java 1.5.  It would have been a stretch, but we could have tried updating OM to work with Java 1.3, but anything lower than that would probably not have worked since OM is built on the Spring framework.  What we decided to do instead was take OpenMigrate’s FileNet logic and execute the steps manually.

The first step was to execute queries against the database to extract out all the metadata for each doc class into Excel spreadsheets (or we could have used a database) for the client.   Here are a few things we encountered that are good to remember when querying records in FileNet:

• The F_DOCNUMBER column is populated by FileNet in sequential order, so a higher doc number signifies a record that was created later in time.

• FileNet date fields, like F_ENTRYDATE, are integer Julian-type dates, the number of days since 1970. So, in our case, we had to convert the entry dates to a readable date format to figure out how many documents were in a given year in order to assist with capacity planning.  All we did was add the value of F_ENTRYDATE to the date 1/1/1970, in days, to figure out what date it represented. For example, the date 1/1/2010 would be represented in the F_ENTRYDATE column as 14610.

• Some FileNet servers store multi-page documents as one document and some store them as multiple documents, one per page. In our case, by looking at some sample data, we found that FileNet stored the documents as multiple documents, one per page, and merged them together when serving it up to the user for viewing. The number of pages in the document is recorded in the F_PAGES column. The one exception is that if a document only has one page, FileNet does not store a 1 in that column as you would expect.  Instead it will store a NULL value in that column for any document that only has 1 page.

After all metadata had been retrieved, we generated Korn shell scripts to run on the FileNet server and download the FileNet content from the database to the filesystem. The scripts leveraged the FileNet system tools to store each page of the document as a separate TIFF file in a folder specific to each document.  If we had been able to use OM, it would have taken care of creating these scripts, running them, and deleting them once they were completed.

Challenge Two: Annotations

Now that we had all the metadata and content extracted, we had one more hurdle to face: annotations. The last requirement was to extract out all the annotations that were on each of the documents so that they could be maintained when moving into the new system, in their case, OpenText. We had hoped that the annotation information, such as the text, width, height, angle, color, etc, would just be stored in different columns within the same Oracle database table as the records of the documents. However, we soon found they were stored separately from the documents table, and were actually stored in their own annotations table, in the FileNet MKF proprietary database. This was a step back for us since it meant we couldn’t just update our original queries to pull this annotation information.  Instead, we had to launch the MKF tool in order to query for the annotations.

We went ahead with using this tool, but found that most of the relevant information we needed in order to reproduce the annotation in the new system, was stored as a hex string that could be up to 800 characters long. It was definitely not an easy task, but after much trial and error, we were able to crack the hex code enough to at least get the text of the annotation out of the hex string, which after talking to the business, seemed to be enough. There wasn’t much of a need to replicate annotations such as arrows and highlights in the new system.  Here’s an example of what one of the hex values in the annotation table looked like:

1f00104119f15c8f01d011a87a00a0246922a504000200010100040190023a0b0004014c00130d000101100006ff000000ffff2400010
123000700020002ff0000250006417269616c002600050c0100000003002b6e65656473207375627061636b657220666f722065787065
6469746520656c6220313033303031202000002b00020000

From here, we found that this long hex string could be decoded into key/length/value combinations. The first 4 characters signify the key, or field identifier, the next 2 characters, once converted to decimal, represent the length of the value, and the next number of hex digits that match this length, once converted to ASCII, is the value of the field.

Our analysis did not take us deep enough to find out what all the fields in the hex string represent, but we did find that 0300 is the field identifier for the annotation’s text.  The other field that we know for sure is in the hex string is the name of the font that is used for the text. It seems that the font name and the annotation text are the only variable length fields in the hex string. I would imagine the rest of the hex string somehow contains the positioning of the annotation, colors, etc, but it would require some further analysis to really confirm that.

In the end, we delivered the content and metadata, plus annotations, which the business needed to get out of the stone age and into a more modern CMS.  While we didn’t actually run OpenMigrate, we were able to leverage its “knowledge” to get the job done.

For this post, we will discuss why leveraging r_object_id for system connectivity is not a best practice.

Background

r_object_id is the unique attribute given to each sysobject in Documentum.  The r_object_id is generated as a unique index per object/docbase and provides a quick method for retrieving content.  Typically, in Documentum Webtop or any of TSG’s custom applications, we will use r_object_id as the link to retrieve the content or other attribute data.  For example, the query to retrieve objects would look like

SELECT r_object_id, object_name from ……

The query results would be built with the object_name imbedded in the link

<a href=…?id=(r_object_id)>Object_Name</a>

It is important to understand that the r_object_id is only used in the context of the query and not saved anywhere in the system.  For some organizations, it can be tempting to imbed the link above in any system that can store links (ex: SAP).  It is important to understand that, if stored in another system, the r_object_id is not generated dynamically but is static.  If the r_object_id changes as the result of a change of object type/migration, this link will be broken.

Open Migrate

OpenMigrate provides the ability to map any attributes during the migration from one object to a new object in the same or different docbase with the exception of r_object_id.  This includes r_create_date and r_modify_date (via underlying tables or the super-user-id).  OpenMigrate does not allow the updating of r_object_id for the following reasons:

• We have not discovered a reliable way of updating Documentum with the old r_object_id without going to the underlying database tables.  We recommend mapping r_object_id to another  custom field (ex: old_r_object_id) if necessary.
• r_object_id is a unique value assigned by Documentum.  Assigning r_object_id within the application can cause unsupported and unexpected results from Documentum including the potential of duplicates and lost data.
• While r_object_id is the most efficient way to retrieve content, other indexed attributes perform almost comparably as the bulk of performance is typically content delivery – not content access.

Best Practice

• TSG recommends clients assign their own internal id for inter-system connectivity rather than leverage r_object_id as it limits the migration and upgrade options. 
• Database Trigger is a great way to develop an independent unique identifier that can persist across migrations.  (rather than custom development).

• Documentum Migration to Alfresco – in our first post, we discussed the reasons why clients are choosing to move.  Detailed points included price, upgrade, software audit, open source, extranet, development environment, web content management and available tools.
• Pricing – This post identified differences in the Documentum and Alfresco pricing model. 
• User Interface Overview – This post compared interfaces from Documentum and Alfresco.
• Development Environment – This post discussed the different development environments components including development framework, API Interface, Web Service Interface, Query Interface, Repository Configuration and Development Community.
• Object Model – This post discussed underlying object model and differences between the two platforms.
• Document Creation – This post discussed how documents are created and imported into either tool.
• InputAccel – This post discussed how to use InputAccel with either Documentum or Alfresco.
• Support – This post discussed support differences and approaches.
• Document Control – This post went into detail on different components required for Document Control and how to leverage Alfresco.
• Documentum Webpublisher and Alfresco – With the announcement that Web Publisher is going away, this post addressed how to leverage Alfresco for an Open Source alternative.

 If you liked the series or have other ideas for additional posts, please attach a comment.

As a company, there were two aspects that we felt were critical to preserve in order to not only weather the recession, but to come out of it ahead.

• Our People
  • No Layoffs or Salary Reductions – TSG experienced layoffs after 9/11 and we were very concerned about the cultural impacts.  Going into the recent downturn, we had been “saving for a rainy day” and forecasted that, while we might run a loss in some months, we had enough funds to avoid the sacrifice of our people, their salary compensation, and impact on our culture.  In getting creative in the short-term, we asked employees to take furlough days off to reduce our costs while giving the employees something they valued, additional time off.
  • Build our Staff – In 2008, we made commitments to our college recruits that they would have jobs in 2009. We not only felt strongly about honoring our commitment, but by bringing in our 2009 start class, we were also able to provide career growth to our existing staff as they took on more responsibility (supervision, analysis, etc.).
  • Recruit for 2010 – We were confident in our product and services and that things would pick up again in 2010, so didn’t want to miss the opportunity to find qualified college students looking for jobs in 2009.
  • Maintain TSG Culture – We didn’t want to cancel social traditions that help make TSG the company it is. With a few cost saving changes, we are happy to say we were still able to have our Colorado ski-trip, celebrate our 14^th anniversary, move into better and more cost effective offices and host a rooftop Cubs event. To us, preserving these types of activities shows a long-term investment in our people
• Our Work
  • Keep our Focus – We felt strongly that it was important for us not to get desperate and take any job that came our way.   Our strength and focus has always been to deliver quality content management solutions to our clients.  This type of work not only provides for interesting projects but also keeps us challenged and happy with our job. Taking on jobs outside of this focus (e.g., staff aug), would only jeopardize the type of firm we have spent the last 14 years building.
  • Help our Clients – Understanding that our clients were struggling as well, we looked for ways to bring value and help them deliver solutions cost-effectively.  Given layoffs in client’s IT departments, TSG looked for smaller jobs as well as part-time opportunities for us to help our clients adjust to budget pressures as well as resource constraints.  Also, given budget constraints, we continue to look for Open Source offerings to help our clients with their IT spend for software.

While we fully anticipated that our revenues wouldn’t meet our costs month to month during the initial stages of the downturn, Management as a team came up with creative ways to save money that we believe helped get us through the downturn and set us up for success coming out of it.

• Reduce Costs – We did look for ways to reduce our spending.  As mentioned above, one that was very successful was the entire company furloughed a half of a day on Friday. Since Chicago is a great city (especially in the summer), we actually didn’t receive any complaints. To protect our new hires start date in September, we had them start on our committed date but work only four days instead of five. Since the whole company pitched in, we were able to cut payroll costs 15% each month while giving something back (time off) to our employees.
• Long-term Vision –While we kept a close eye on our finances – we didn’t allow ourselves to get overly anxious about small losses. While we had down months, we didn’t react with drastic measures like layoffs or pay cuts.
• Low Overhead – This is a lesson we learned from the 2001 recession. Since then, we have very little overhead.  With the exception of one employee, all of TSG employees do project work as well as share the responsibility for non-billable tasks such as sales, marketing and recruiting. Not only does this help us keep our costs low, it keeps our consultants challenged as we are exposed to more than just our client work.
• Take advantage of the market – With our lease expiring at the end of 2009, it set us up in a great position to negotiate for a new space that is significantly better and is more cost effective than our old space.
• Open Source – With IT spending down and software costs rising, having proven open source products along with our consulting services was an advantage to us and our clients. We also were able to leverage any downtime we did have last year to add to our offerings. For example, we took feedback from one client and developed OpenScan.

Clearing up the “small company is more risky” myth

As we start our 2011 college recruiting season this fall, we couldn’t end this article without addressing the concern that some college hires have in regards to small companies being more risky than large companies.  Myths about small versus large companies include:

• Large companies are more stable – All companies involve risk.  As seen throughout the downturn, big companies often take big risks or can be too reliant on large contracts.  Small companies have flexibility given their size and focus to quickly adapt to changing economic conditions.
• Large company employment is more stable – Large companies have shareholder pressure to meet income targets.  One way to quickly cut costs as well as show the market that a company is “getting tough” are layoffs.  Small companies, like TSG, are typically employee owned and don’t have the same pressure to meet shareholder or market perception and can pursue long-term employment rather than short-term cuts.
• Better opportunities in large companies – Large companies generally have more overhead and layers of bureaucracy. Small companies tend to operate on less and have a more lean structure. This type of structure fosters rapid career growth and gives employees exposure to a wide variety of responsibilities.

While we realize the recession is not over yet, we are encouraged with how we’ve seen things pick up for TSG in 2010. We’d love to hear your thoughts on ways your company weathered the last two years.

“Given that Documentum has announced that they are not investing in WDK based solutions like Webtop and DCM, should I continue paying maintenance on these products as I know there will not be new functionality in the future?”

While we (TSG) are very convinced that Webtop will not be going away soon, the question as to what the maintenance buys in the future is in doubt.

Support/Maintenance Background

To properly answer the question of continuing maintenance/support, clients need to understand what maintenance/support does.

1. Standard Support provides assistance with installation and operation of Documentum products and assistance with behavior with product specifications.
2. Maintenance provides customers with updates and upgrades to Documentum products they license.

Support and Maintenance cost 18-19% of the purchase price and are billed annually.  If clients don’t pay maintenance on a product, the client will not have the ability to upgrade to the newest releases.  In some cases clients will have to either rebuy the software or pay all back-maintenance costs.  Support is slightly different discussion as the client will not be able to access Documentum support for questions and assistance with that product.

Traditionally, Documentum has allowed line items to be dropped from the maintenance contract.  Other vendors, Oracle for one, will sometimes not allow line items to be dropped.

Why is WDK a different decision this year?

Typically TSG’s response to the maintenance discussion is:

1)      Stop paying maintenance for products you don’t use.  Often additional products like iTeam (anyone remember that?), BPM, CIS, Documentum Client for Outlook or other products are added to a large purchase as extras  to allow the client to experiment with those products.  We typically tell clients that haven’t deployed these solutions after a couple of years to remove those products from the maintenance agreement as the likelihood of deployment is remote.

2)      Pay for maintenance for products you use regularly to provide access to support and future upgrades.

The current concern with WDK applications is that, while clients use them regularly and might need support, there will be no future upgrade based on Documentum’s decision not to invest in these solutions in the future.  Some significant points include:

• most of our clients leverage support from Documentum for content server related issues and rarely need support for client products. 
• some clients that have stabilized in the 5.3 environments and are not planning on upgrading to 6.5 clients, they are either not getting support from Documentum or paying for extended support.

Strategies going forward

TSG would recommend the following strategies going forward for Documentum clients with WDK applications.

1)      Talk to your Sales Representative – To date, we have not heard consistently where the upgrade path for Webtop clients leads in regards to xCP or CenterStage.  Your sales representative can communicate (in writing) what your future upgrade purchases involve.

2)      Keep paying server maintenance – Support and upgrades are very much required for any production Documentum server component.

3)      Consider dropping support for Webtop/DCM clients if you are not planning to upgrade.

4)      Consider switching your maintenance from Webtop to Custom Client or other tools if allowed by your sales rep.

If your Documentum purchase pre-dates 2003 and you purchased “Foundation Seats” – keep paying maintenance on the Foundation seats.  Foundation seats include the client, server, Webtop any Custom Client for that particular (named) user.  While Documentum doesn’t sell Foundation seats any more, the ability to maintain all three of these components plus the custom client is, as one ex-Sales rep mentioned to me, “gold”.

Background

A web content management system (WCM) is a software system which provides website authoring and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage the site’s content with relative ease.

Most WCM platforms scan be split into two functional components – Content Production and the Content Delivery.  Content Production includes the generation, previewing, and approval of all content intended for deployment of a website or web application.  The Content Delivery component is limited to the mechanism that delivers the content from the core repository to its final destination, whether that is on a static website or a dynamic portal.  Both Web Publisher and Alfresco WCM accomplish these tasks, but there are some differences worth noting.  Let’s take a closer look at some of these features:

Content Production in Documentum WebPublisher

Almost all WCM systems provide a method for non technical users to create or modify a page on a site.  WebPublisher uses an XML template in coordination with a XML rules file to create a web form with the ePHox editor.  When content is generated, from the form, the result is a copy of the XML template, but completed with all information entered in the form.  From that point one or many XSL presentations may be applied to transform the raw data to any document type required for publishing.  Recently our clients have become frustrated not with forms or form options, but the performance of the ePHox editor itself.  When more complex forms are created, they can take a long time to load and be quite cumbersome to edit.  Documentum does offer a second option for a content entry interface, Page Builder.  Page Builder, which is packaged with Web Publisher, is an alternate entry interface with more of an in-context feel, more ideal for sites that require minor text updates to pages.

Seasoned Documentum users and administrators are familiar with the concept of a docbase or repository that manages all data and documents in the system.  In this environment all users (with equivalent permissions) can work on the documents in the same environment using a system of versioning and checking in and out to manage document integrity.

Workflow capability can be an essential part of any WCM system.  Non technical users need a process to submit and approve site changes in order to make prior to publishing. WebPublisher has a framework for custom workflows in both a serial (sequential reviewers) and parallel (concurrent reviewers) architecture.

Given the complexity of sites today, users may need much more control over specific sections of a site, instead of using traditional forms. Some clients may leverage EMC’s FTP Services which allows web content such as flash files, images, and CSS to be imported or updated via FTP.

Content Production in Alfresco WCM

Alfresco takes a slightly different approach to form building for content entry.  WebForms are configurable through an XSD file and the XML schema uses an implementation of the industry standard XForms.  The dynamically build forms do not require an applet and load almost immediately.  Unlike Web Publisher, administrators have the ability to choose what renders the XML content generated from forms.  Traditional XSL stylesheets may be used, but renditions can also be created using XSL-FO, Freemarker or any other custom rendering solution.

Recently announced, Alfresco has plans to release an in-context editor allowing for a click to edit option on a preview site, however this will be implemented using a standard Alfresco DM repository and not the WCM/AVM repository.  An initial iteration of this, called Alfresco Web Editor, is already out.

Alfresco WCM uses an innovative approach to repository management with the concept of sandboxes.  Every user has a unique environment to generate, update and preview content.  Changes are promoted to the “Staging” sandbox when they are ready to be previewed and merged with the community’s joint efforts.

Alfresco WCM uses JPBM for workflow to provide a framework similar to WebPublisher which also allows for custom workflows in both a serial (sequential reviewers) and parallel (concurrent reviewers) structure.

Alfresco has FTP, WebDAV and CIFS access to web content as a core feature without any additional service layer or licensing as is required from Documentum  All three of these interfaces provide a easy way to integrate an HTML authoring tools like Dreamweaver, while still taking advantage of the content repository.

Content Delivery in Documentum WebPublisher

In the Documentum world there is really one choice – SCS (Site Caching Services) for a pre 6.5 SP2 environments, which was renamed to IDS (Interactive Deployment Services) post the 6.5 SP2 release.  The primary job of SCS / IDS is to publish content and metadata from the repository to a server and database.  IDS leverages an XML datastore in addition to the relational database that SCS has always provided. Based on the X-Hive product acquired in 2007, this XML datastore provides new options for delivering content to your web properties. Another new feature of IDS is the ability to take user-generated content from your web site (such as ratings or comments) and ingest them back into the Documentum repository. This is done by first writing them into IDS which will then write them into Documentum.

Content Delivery in Alfresco WCM

Alfresco took the concept of content delivery a step further by allowing a choice of static or dynamic delivery environments. The File System Deployment Target is the static option which can be configured to run similar to SCS or IDS.  AVM (Advanced Store Implementation) Deployment Target is a dynamic approach to publishing content by installing the full Alfresco Runtime environment on the target server. This approach is designed to support the version control requirements of managing large websites and web applications.  There is a third option, the DM Deployment Target, which receives a deployment from an Alfresco WCM authoring environment and puts the content into the workspace spaces store where it can be used to support a dynamic web site.  As many of the future roadmap features come to fruition, this type of publishing to a DM repository, not a AVM may become more prevalent.

Unlike Documentum, Alfresco is an open source platform. Both of these publishing modules are left wide open for customization and specific business logic updates.  The Transfer Service is a subsystem with an API that offers a variety of features related to the transfer nodes and targets.  A great example of this is Peter Monks, who with other developers has created a couple of open source projects that extend Alfresco WCM’s deployment mechanism to use CouchDB and MongoDB as endpoints (here and here).

• Documentum Investment – the effort and risk to move away from a multi-year Documentum effort, in regards to business interruption, cost, updating SOPs, training and development efforts is a major obstacle to changing platforms.  Regardless of any animosity because of a Documentum Audit or other pricing, relationship or product issues, the costs of a “big bang” migration can  be burdensome, expensive and difficult to justify in a down economy.
• SharePoint Investment – While Open Source solutions like Alfresco have a certain amount of momentum, SharePoint as a collaborative tool  has been very successful at most companies and, rather than Alfresco, can be easily viewed as a Documentum alternative.  Experienced Documentum users need to see more than just the interface in regards to development environment (Java versus .Net), Server Infrastructure (UNIX/Linus/Windows) as well as the subtle differences in regards to renditions and other common Document Control functions.  See previous post on SharePoint for Document control.
• Open Source Concerns – Understanding Alfresco’s model (Commercial Software that is released as Open Source – only paying for support) is difficult to understand for most companies that think of Open Source as only community developed (Apache) efforts.  We typically spend some time getting Alfresco users to understand that ex-Documentum employees architected and developed the solution but are releasing it under a different sales model.
• Should I be first? – Industries as a whole more on each other’s success or avoiding each other’s failures.  Leading an industry with a different platform can seem risky and something to avoid in an economic downturn. 

Document Control Functions and Alfresco

For the remainder of this post, I will address common Document Control functions in Documentum and the ability of Alfresco or other add-ons to address all of the functions needed for Document Control.  Many of these add-ons are TSG products as we have developed our solutions as Open Source for either Documentum or Alfresco.

• Document Templates – Alfresco can support either Word or XML or other types of templates, very consistent with Documentum.  We typically recommend to clients to leverage templates that leave room for header/footer/signature overlays on the approved/released documents.
• Document Properties – Very consistent with Documentum.  We typically configure/customize this screen for clients based on value assistance, required values, generated document name, cabinet/folder location as well as integration with external systems.
• Document Versioning and Lifecycle – Versioning/Lifecycle is slightly different in Alfresco than Documentum.  While this post won’t get into the specific differences, both solutions can address the Document Control needs for numbering, version labels and automatic promotion via approval.
• Security – making sure that security in regards to Consumers, Approvers and Authors are reading/working with the correct documents can be easily handled in either package.
• Search – Alfresco has robust capabilities for attribute and full-text search.  TSG’s HPI interface can access either repository and is a common add-on with our clients.
• Document Viewing – TSG typically recommends PDF as the default consumer file format.  As mentioned with templates, both solutions can add headers/footers/Overlays.  TSG’s OpenOverlay, based on iText, is an open source option for either package.
• Change Package and Workflow – We typically recommend to clients to group the workflow approval into a change package that contains
  • Include one or more documents for approval
  • Instructions/Documentation on why the change is happening (Description, Reason, Justification…)
  • Allow flexibility in selecting reviewers and approvers
  • Include internal and external supporting documents
  • Capture Electronic Signatures on approved documents

We have leveraged the Active Wizard for our Documentum work in regards to Change Package.  We plan to have the Active Wizard on Alfresco and JBPM by the end of the year.

• Document Redlines – Markups supported within the Document (typically Word) for both solutions.
•  Annotations – TSG’s OpenAnnotate offers support for both Documentum and Alfresco.

Overall Thoughts

 TSG feels strongly that clients to DCM/Document Control on Documentum and looking for alternatives should strongly consider Alfresco as an alternative based on:

• Consistency with server (UNIX/Linux) and development (Java) environments
• Capabilities of platform to perform common Document Control functions with open-source add-ons
• CPU based support with no purchase price

For more information on Document Control best practices, leverage TSG survey presentation from Midwest Documentum User Group meeting.