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.

Ready to start the new year

My long end-of-year break has come to a close. I’m looking forward to a strong start on 2006. My ECM practice at Navigator continues to gain momentum with some recent internal transfers into my group and a decent approach for external hiring and on-boarding in the first part of the new year.

Over the break we had fun spending time with family. We even managed to slip in a spur-of-the-moment road trip up to Nebraska to surprise Christy’s sister and her family.

I’ve finally started my project to connect my entertainment center with my network. Step one–upgrade the wireless network–is done. I’m loving my Belkin Pre-N MIMO router and PC card. No more slow, spotty wireless for me.

The new Dell XPS box arrives later this week. It’s got a dual tuner TV card in it so we’ll finally be able to join the time-shifter ranks.

The final step is a media extender box so I can stream my videos, pics, and music from the office to the family room. My original plan was to use an XBox 360 but if Microsoft doesn’t get their supply act together I might have to settle for the Linksys. Of course with the Dell’s 20-inch widescreen display I might just forego the family room altogether!

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.