So, I have two topics that are burning for another post, but I had something fresh, and wanted to post on this topic while I still had my thoughts in a semi-coherent collection. Recently, I have run into more designs utilizing Virtual Documents than I had, quite possibly, ever. Your first thought may be that I have been working on similar projects. Wrong! Of these systems, I have seen one where Virtual Documents was called for, and the rest where I just wanted to shoot the designer. Well, once I just laughed because I couldn’t believe my eyes and didn’t have to fix it.

Now, I don’t know if maybe I happen to be in the wake of a rogue Documentum “Architect”. I use that term loosely because that is a term being bandied about more and more frequently. There are very few that I consider Documentum Architects, fewer that are ECM Architects, and none of them, including myself, are Enterprise Architects. However, that is a post for another day.

Regardless of the cause of my problems, I want to take a moment to clarify something that I learned back in Technical Fundamentals years ago, and that hasn’t changed. Virtual documents are a way to combine documents whose contents have a variety of formats into one document. That is a quote from the 5.3 Content Server Fundamentals. What does this mean? Here is a simple example. Say I am working for a Government Agency. When I produce the massive volumes of documentation for any project, I invariably have the same project overview and set of appendices in most of my documents. Some subsets of the documentation may share more content. A Virtual Document allows me to link all of the documents together, assemble them, and publish them as one document. So when I publish all of my documentation, I can be sure that my common resources match. When I update one, I update all.

Now there are several XML processing applications of Virtual Documents as well. However, Virtual Documents are not for grouping a set of files together, just to group them. Something I have seen (modified to protect the innocent) is using Virtual Documents for Case Management. In a case, you have source documents, reference documents, and output documents. That is an oversimplification, but it’ll serve here. What I have been seeing is making those all part of the same Virtual Document! DON’T DO THAT!!! If documents are related, you have at LEAST three easy choices:

1. Put everything into a folder. Hmmmm. I kept the original files in a folder on a desk, why not a folder in my ECM system? I can even store Case information on the folder.
2. Tag all the documents with a piece of metadata, like, oh I don’t know, a Case Number. Then you use a quick search to retrieve every related piece of Case content with a simple search. In D6, Documentum is taking this further in their Taskspace interface and not showing folders at all, but using “Smart Folders”. Smart Folders are just simple, saved searches based on some indexed value.
3. Define a relationship within Documentum. Documentum already uses relationships for several functions including Annotations. You could define a custom relationship and implement it. This requires a little more work than the other two options, but there are times that it would prove more efficient.

There is more than one way to skin a cat and there is more than one way to design most systems. However, Virtual Documents are not to be used lightly. There are a lot of complications that can arise in everyday use of Virtual Documents. For instance adding or removing content from a Virtual Document requires checking the parent document in and the out. There are times where they are called for, but they should be clearly thought out before implementing.