Month: January 2006

Robertson’s call to arms: Let’s get practical

I’ve been thinking about James Robertson’s post. In it, James says that instead of undertaking enterprise-wide, strategic Knowledge Management initiatives (my grouping for his list of example “enterprise projects) organizations should be focused on smaller, more tactical point solutions that deliver real improvements to productivity.

He’s not advocating that every business unit just “do their own thing”.

This is not to say that the bigger picture is forgotten, quite the opposite. While individual activities are always focused on immediate needs, consideration is given to longer-term objectives. This influences the selection of the projects, the technology used, and the points of integration into other systems.

While I agree with James’ overall sentiment, I’m not quite clear on what he thinks is the best way for the business units to leverage economies of scale around best practices and infrastructure.

For example, several of our clients use a “shared services” or “center-of-excellence” approach. In this model, a centralized supporting infrastructure is put in place (includes physical infrastructure as well as human resources) that business units can leverage.

The trick is making sure that:

– The IT organization is not a bottleneck. The whole goal is to empower others to use the infrastructure.

– The process of selecting and implementing the infrastructure doesn’t turn into a multi-year project that delivers no value until the very end. By that time, the business units will have already done their own thing, often without regard to the shared economies of scale or “the big picture”.

It seems that this model lends itself to empowering business units without too much overhead yet still provides enough direction and coordination to avoid a big mess down the road.

Optaros summarizes 15 open source content management projects

Seth Gottlieb has published an excellent whitepaper summarizing 15 different open source projects. He also includes a summary of how to go about evaluating open source offerings.

Seth offers a short list of offerings for each of the following usage scenarios:

    Brochure Site
    Online Periodical
    Collaborative Workspace
    Wiki as Collaborative Workspace
    Online Community

The format is similar to the presentation he gave at KM World but the format obviously lets him go into much greater detail.

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.

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!