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.

Handy use for VMWare #2: Instant training setup

My practice has put together a “Documentum Boot Camp” which is an intensive course aimed at taking folks with Java development experience and turning them into Documentum developers in much less time than if you were to take formal training on each topic. We cover everything from Administration, Security, and Workflow to writing custom Documentum WDK-based applications.

Keeping a pristine training environment set up, or better yet, providing each student with their own training environment wouldn’t be practical if it weren’t for VMWare. With VMWare we’re able to create a standard “client” and “server” image, each pre-configured with everything the student will need to get through the Boot Camp exercises. So, when it is time for someone to go through the Boot Camp, we give them a CD with the courseware, lab book, and instructions, and two DVDs with the VMWare images. They use the VMWare Player to run their images. If they trash their environment it’s no problem–they simply re-copy the image from the DVD.

I’ve seen training providers handle this with ghost images in the past. The nice thing about the VMWare approach is that the images run on the student’s machine on top of the OS they already have installed. This is the first time I’ve seen a training class where you can actually take the training “machine” with you when the class is over. The next time you pay for training, instead of asking, “Is this course material going to be available for download?” you should ask, “Is my training machine available over BitTorrent?”

Red Hat acquires jBoss

Red Hat has signed a deal to acquire jBoss.

How will this affect the world of ECM? jBoss has portal and workflow offerings. Although I’ve never seen it in real life, and I’m unsure of its origins, Red Hat does have a portal solution. I have no basis for this opinion but I’d wager that the jBoss portal is more complete than Red Hat’s.

Red Hat tried their hand at content management. Their offering was based on the now-defunct ArsDigita Community System (ACS). If Red Hat wants in to the ECM game they’d have a decent start with jBoss’ portal and workflow. All they’d need is a repository. How ’bout Alfresco?

Workflows can be flexible, but are not infinitely so

In his latest response in our ongoing discussion about the problems with workflow, James Robertson makes two excellent points:

  1. People often abuse “exception” or “fast track” workflows; and
  2. Flexibility in who performs a workflow step is often a key consideration in creating adaptable workflows

Regarding the abuse of exception workflows, this is sort of a damned-if-you-do-damned-if-you-don’t situation. At some clients content authors/content managers have considerable power with regard to how and when their content is published. When you automate the process, depending on the publishing scheme you’ve implemented (e.g., batch versus real-time), some of that power could be diminished. If you don’t implement exception-handling workflows you’ve decreased the service level and increased frustration.

One answer is to implement a “fast track” workflow that bypasses normal approval processes and goes straight to the public site. As James points out, this has the potential for abuse. I would like to think that abuse could be easily identified and dealt with.

This type of exception handling wouldn’t be appropriate in all situations. The higher the potential for abuse or exposure to risk due to the wrong thing getting fast tracked, the less you’d want to take this approach.

The second point James makes is that, often times, there are an exceedingly large number of factors that play into who should be involved in a particular workflow step. There are a couple of things you can do here. The workflow technology being used has got to allow for the programmatic determination of the workflow step performer (one or more specific individuals, groups, roles, etc). In my opinion, that’s table stakes for a usable workflow solution. Assuming that is the case and assuming the business rules are reasonable, you can programmatically determine the performer.

If the factors are so numerous or complex or subjective that the performer cannot easily be programmatically determined, the person who starts the workflow can be empowered to manually choose the performer. (Again, assuming the underlying workflow solution allows this, but this seems like a fundamental feature). I know there are business cases where letting someone pick who performs a task are simply out of the question, but it is something to consider.

If you can’t code it and you can’t trust the initiator to pick the performer then it certainly will be difficult to create a practical number of workflows to handle the process.

Throw out workflow? Not so fast…

James Robertson at StepTwo says “workflow doesn’t work” for WCM and thinks maybe a task metaphor would work better (See original post and Is Workflow the Wrong Metaphor?).

I agree that when processes are not highly-formalized it can be tough or impractical to implement a workflow that deals with all possible scenarios. I agree that formalized workflows are probably not appropriate for the content authoring stage which is usually highly collaborative. And exceptions will always exist–it helps, for example, if you can put an emergency or “fasttrack” workflow in place to handle some of those situations where there isn’t time to go through the normal process.

I disagree, though, that a completely new metaphor is needed to implement something like task management. What is a task? It’s really just a step in a process. James is looking for a way to have the number and type of tasks be more ad hoc. For that why not implement one single-task workflow for each type of task with the performer being selected by the person who initiates the workflow?

For example, James gives “review”, “update”, and “add additional detail” as three examples for types of tasks. If someone wants one or more folks to review a piece of content, start a “review this content” workflow. If content needs an update, start an “update this content” workflow. Don’t think you can name all of the types of tasks you might need? Implement a generic “action needed” workflow that the initiator could further define in workflow comments or instructions.

It just seems like it’d be easier for everyone (vendors, customers, developers) if we could stick to the well-known workflow metaphor.