Johnny Gee’s recent post on a Migration Dilema describes a client’s reluctance to create a taxonomy when migrating content into Documentum. The argument from the client being, “if the old system didn’t need it, why does Documentum?” I’ve heard this more than once myself and this kind of question is usually followed by a complaint that if Documentum is so expensive, why can’t it do exactly what I want it to. (usually this translates to “make it behave exactly like the product its replacing”)
Before answering the question, as integrators we have to understand exactly what our role is in the engagement. Are we contractors or consultants. There is a difference. Contractors supply additional labor to fulfill the wants,wishes and desires of the project owner. True consultants however are there to do more than execute on tasks. They are there to guide and educate their clients as well as augment their capacity. By educating the client, the consultant will help them avoid the mistakes they themselves have made.
Every Documentum coder with more than 2 years experience has had to go back and fix this problem for someone. The root cause of the issue is in the very fabric of Documentum and part of its heritage as a pure Document Management System. The short high level answer is that collocating thousands of objects in the same logical folder location creates a performance issue and a navigational constraint to maintenance and support. The technical why’s and wherefores are covered exceptionally well in posts on other sites. If you want to understand what’s behind it ,one of the best is by John Kominetz. It’s a slightly different topic but very educational.
One principal of COTS (Commercial Off The Shelf) package selection is something I call choice bundling and it comes into play here. Almost anyone given enough time and money could code almost anything. When you buy a product like a CMS though, you are not only selecting features but you are buying a set of design and implementation decisions. A bundle of choices. As products evolve, choices in how to implement a tool made along the way affect the character of the system even when the feature set is not unique.
Burning money pursuing questions like “why did they do it that way” and “why can’t they fix that” seldom solves any problems after a product selection has already been made. The time to ask those questions is before you drop a gizillion dollars on an enterprise license agreement. Prolonged analysis like this or worse yet – compensating for native behavior by coding around it with customizations that lack real business value is a curse on our industry.
Sadly – the customer is not always right. If more implementers would act as consultants and challenge these points, Documentum’s reputation as an overly complicated behemoth might not be so prominent. Who am I kidding? – it’s ridiculously complex – but why add your own complexity if you don’t have to. By the way … The best post I’ve ever read on Documentum complexity was also by John Kominetz. Required reading for Documentum newbies. After you read it – remember “There’s no crying in Documentum!”
Time and again – people ask the content server to perform unnatural acts because the client wants the repository to behave like something it isn’t. C/S is not a BI platform, its not a scheduling system, its not a virtual file system, <insert your misuse here> . When it doesn’t perform, we all act surprised, curse the sun and secretly hope it incinerates Pleasanton as it sets. If you know its not a natural act, it is your responsibility to make it known to others.
As coders – we see these oddities as a challenge. As hired guns, they are billable hours. At the end of the day integrity and the hope of repeat work should encourage you do the right thing. You owe it to your PM, the vendor and ultimately the poor soul that has to use the product. Once professional full disclosure, sans the EMC bashing, is complete then you are obliged to follow directions. The owners may still elect to create the problem but you are secure in the knowledge that you tried and every once in a while you might make a user’s day better in the process.
I think one thing that is going unsaid, and ignored, is that this really is the case for all content management systems. We all know the ying-and-yang of content. Organization’s have structured and unstructured data.
It is not unheard of to have large teams of database professionals yet only one or two that manage content management systems and database projects go on for years as well. What we need to do is treat these two as equals. Yet for some reason since a CMS sits on a DBMS the feeling is that this can’t be true. If that’s the case, since a DBMS sits on an OS then it shouldn’t need so many resources within a company. There is nothing new in the concept of platforms. And each level, OS, DBMS, and CMS, is a platform of its own. And as Lee says that’s the job of we consultants to solve for our client’s situations until product companies finally start building CEVAs (Content Enabled Vertical Applications) that solve real business needs.
Remember just as an empty OS offers no value until an application is installed on it or an empty DBMS offers no value until it has been configured to solve a problem neither will an empty CMS.