Category: Content Management

Enterprise Content Management (ECM), Web Content Management (WCM), Document Management (DM). Whatever you call it this category covers market happenings and lessons learned.

Migration tools are marketing, not technical, tools

CMSWatch says that although Trends: Microsoft has released free migration tools for Notes/Domino, it is the custom Notes/Domino code that makes it hard to switch.

I’ve architected Notes/Domino applications as well as solutions on other document management and collaboration platforms and I’ve ported applications from one platform to another. Platform migration tools are usually good at moving apps with little or no customization. The “problem” is, Notes/Domino is often used to develop complex, highly-customized applications. For those, there’s probably no getting around a complete re-development effort if they are to be moved at all.

If you accept that you are essentially starting over for all but the simplest applications, your next problem could be with end-user expectations. A lot of the functionality vendors are just now getting around to incorporating into their offerings has been present in Notes/Domino for some time. If the goal is to port the highly-customized application with a 0% loss in end-user functionality, prepare yourself for a substantial development effort and, potentially, the acquisition and integration of best-of-breed components to keep the app as functional as it was before.

This is probably true for any platform migration project. Although you’d like to think that the end-user requirements are de-coupled from the underlying technology choice, platform-specific features or strengths always seem to find their way from the platform feature spec sheet to the list of features end-users can’t live without. Sometimes, that’s because the platform might have been originally selected because of those strengths (i.e., platform X has strong collaborative features or platform Y has great Office integration, for example). Other times, it is because developers are inherently lazy–features that rely on functionality that comes “for free” or is built-in to the platform are often at the top of the priority list.

I think platform migration utilities are most efficiently used as a marketing tool rather than a technical tool–they give the sales folks an answer to the “what about our existing applications on platform X?” objection. Use them to migrate your simple stuff, then start the real work of planning the migration of your customized apps.

Documentum: Open up the WDK!

The Documentum Web Development Kit (WDK) is a rich component library developers can use to build Documentum-centric web applications. All of Documentum’s web clients–Documentum Administrator, Documentum Webtop, Documentum Web Publisher, Documentum Digital Asset Manager, etc.–are all built on the WDK.

The WDK is similar to JavaServer Faces(JSF) but it is not JSF. Although EMC Documentum was a contributor to the JSR-127 JavaServer Faces specification which went to “Final Release” on March 11, 2004, the WDK continues to be a proprietary framework.

Why do I care? In my personal opinion, there are two main reasons why Documentum should open up the WDK. First, although the WDK makes it easy to make simple changes (often requiring nothing more than editing an XML file), more complex extensions are often hampered because, ironically, some pieces of the library just weren’t built to be extended. If you are an engineer at EMC, this isn’t a hurdle for you–you have the source code. But for third-party developers, determining exactly what’s going on behind-the-scenes can be a time-consuming and frustrating task.

Second, experienced WDK developers are hard to find. This resource scarcity results in increased development and maintenance costs. (A related problem is that companies invest time and money in developing WDK talent and end up with resources that are not perfectly transferrable across other, non-WDK projects).

My first choice to solve this problem would be to migrate the WDK to JavaServer Faces. EMC Documentum would then supply any Documentum-specific JSF components that are needed, along with the source. This would address both of my issues. Everyone would have access to all of the source. And it opens up the resource pool to the larger population of developers familiar with open, standards-based component frameworks.

Here’s an idea. If Documentum doesn’t do it, maybe the open source community could be rallied to do so. I know companies are already building Documentum web applications using JSF–why not build those apps on some open building blocks the entire community can leverage?

In the short-term, I would settle for some tweaks to the existing WDK and the distribution of the source code for every single WDK class. Progress has been made in this area with the release of 5.3 sp1. Some of the previously private and protected methods have been made public. I haven’t compared the 5.3 release to 5.2.5 to see if any additional source code has been provided.

At the Documentum Developer Conference this past Fall I spoke to Howard Shao, Documentum’s CTO, about opening the source. He responded positively, saying that he wished it had been done already. So, I’m hopeful. But, I’m also realistic. I realize a tremendous investment has been made in the WDK and I know it would take a lot of work on behalf of EMC and their customers to move to an open framework. Compounding the problem is that the business users may not see the bigger picture benefits of an open framework. As EMC and its customers continue to invest in the WDK, the cost of switching only goes up. Why not move now?

Alfresco announces PHP support

Matt Asay, while commenting on Alfresco’s PHP support, says all systems should be architected in a language chosen by the development team but remain extensible in any other language by third parties.

I think giving clients and other developers the choice about how to extend the core product is a good thing. Hopefully it won’t get too out-of-hand, though. It seems like there might be some loss of efficiency in the community as the number of different implementation choices increase.

For example, if someone finds a great extension they’d like to use but it is only available in [pick your language], they’ll have to port it.

If the number of choices stays reasonable, and if each one develops a decent mass, it’s a win-win for both the customer and Alfresco.

Documentum Web Publisher Portlet Builder

EMC Documentum announced today the release of their new product, Web Publisher Portlet Builder. The goal of the product is to allow non-technical users to define and deploy new portlets to a portal by filling out forms in a wizard-style interface.

In the product announcement, EMC called portal “the new web master bottleneck”. I think this can certainly be true. When a company makes an investment in web content management, the management of the content itself is streamlined, obviously, but when that content is being served up through the portal, you end up with a new layer of process, administration, and management inefficiencies.

For example, suppose we have a portal in which each portlet is serving up a specific static URL. A press release portlet might contain a list of press releases, and the list of press releases would change over time, but that portlet would always contain press releases. The WCM system makes sure that non-technical owners of press releases can contribute the content, route it for approval, transform it into the desired formats, etc. But what if the portlet needs to start serving up press releases from a company subsidiary or maybe an entirely new type of content altogether? Often, the portal administrators have to be involved at that point.

As another example, suppose an entirely new portlet is being added. In some implementations, adding a new portlet can require a fairly involved build process. The portlet might be built in a development environment, get migrated to the test environment, and then finally rolled out to production as part of a scheduled maintenance release. This process certainly results in a quality end-product, but is not very responsive to change.

Because portlet configuration is usually XML-based, it lends itself to a more automated, forms-based approach, like the product Documentum has announced. In fact, I know of others who have done this on their own using home-grown approaches or by leveraging XML-based templating engines built-in to their web content management system.

I haven’t played with Documentum’s new offering yet so I cannot say how robust it is. I do wish it supported more than just BEA WebLogic Portal. I imagine they’ll offer more support for other vendors (probably IBM WebSphere Portal and Oracle) over time.

The bigger issue is that portal vendors need to do more to beef up and simplify portlet deployment. And content management vendors need to do more to allow their repository to be integrated with the portal more seamlessly so that dynamic content can be delivered to the portal without requiring costly integration, duplication of back-end stores, or performance hits.

Alfresco and Plone comparison

Seth Gottlieb has posted a good Alfresco overview with a brief comparison to Plone. Seth concludes,

I would use Alfresco for a targeted document management solution that would fit into a larger enterprise content management architecture…I would use Plone to build an all-in-one intranet or extranet where I wanted to mix article, page, and file content and opportunistically deploy new features to improve collaboration and retention.

I agree with Seth’s conclusion and the point he makes in the article that the lack of LDAP integration in the community edition of Alfresco limits it to departmental use. I’m sure they’ll move that feature down at some point–when they do it should boost adoption.

Tried out Alfresco 1.1

I tried out the new release of Alfresco (1.1). They got the security stuff fixed–you can now secure spaces to specific users. I had to shake my head and chuckle a bit when I saw “Contributor” and “Coordinator” as user types. Those are also used for “capability” settings in Documentum.

I’m anxious to dig deeper but I’m too busy with end-of-year projects.