Don't google "dead horse" for images.

My response to Pie’s Quality of Documentum Over the Years bears repeating, even if I am beating a dead dmHorse:

I started with version 2, back when I was just a newly-minted UNIX geek. One thing you missed with the transition to 4i was the introduction of the DFC. DMCL had a very UNIX feel; a simple, open API designed to be glued into any programming language. DFC was just Java then, with a COM layer growing over it later. That was also the point where EMC became more marketing-driven and started chasing the Internet bubble at the expense of their existing clients.

Both were attempts to capitalize on hot topics of the time, Java and the Web. I never bought that the DFC would make a whole pool of talent available; Documentum’s about the model, not the means. However, the marketroids successfully reframed it. Hiring managers now believe they can take Java people and mold them into Documentum people, and I hear gasps of disbelief when I say Java or Visual Studio aren’t requirements to do Documentum–a good Java programmer is not necessarily a good Documentum developer.

This Java mentality did increase the number of people with Documentum on their resumes, but the talent didn’t increase as much as the volume. It just diluted (maybe also tainted) the pool. It became harder to find good people in the now-mirky waters.

The lack of focus then is what brings us to the lack of quality now. Innovation at the model and server level is rare, and frankly I don’t give Documentum much geek cred anymore because of it. Great ideas like BOF and Aspects are stapled into an API rather than made an inherent part of the product. Too much work up the stack (and on vertical solutions) has made the product top-heavy and tottery. EMC continues to chase markets (i.e., case management) rather than concentrate on making a solid core product.

Composer looks competently-enough done to be a welcome replacement to the persnickety Documentum Application Builder (DAB). The look and feel (and clutter) is pure Eclipse–no sexy Apple minimalist influence here. The win here is one-stop shopping: Developers won’t split their attention (nor workstations their resources) across two programs. That’s definitely a Good Thing.

Aspects in theory are great. They allow per-instance extension of both state and behavior, so objects get what they need when they need it. The reduction in type bloat alone is worth it. There’s no need for all those “optional attributes” just in case a particular instance becomes a document of record or gets included in a submission. Fabulous. In happy wonderful fantasy land, I’d scrap dm_document completely for a true lightweight object, then staple on versioning, lifecycles, web content, retention, and whatever as needed.

Aspects bring some real architectural benefits, too. Adding an aspect at runtime doesn’t require ALTER TYPE activity which can crap out the database on some really big (or really underpowered) docbases. Older docbases will also benefit from this easy way to add and remove new functionality without the potential dangers of hacking around the existing type hierarchy. Documentum architects now have a built-in way to do composition, a technique that is largely replacing inheritance in OOP design theory because it keeps the design open and adaptable.

Aspects in practice aren’t so great. My fear that aspects would use the DBOF model of requiring Java code client-side has been confirmed, although they made an effort to minimally support DQL since attributes are involved. (No word on DQL limitations imposed by aspects yet.) Turning the docbase into a JAR pusher has improved the deployment situation, but it’s still pushing functionality too far up the stack for my liking. More moving parts mean more things can fail, get out of sync, or confound.

This design flaw will persist for as long as EMC is swinging their Java hammer, even on screws like scripting. Perhaps EMC catching onto jython a few months back means they’re reaching back into the toolbox. Funny how they had to make a simple script look so big with all the extraneous print statements–very Java of them. If only there were another way to pass messages from a client to Documentum without the DFC. Hmmm.

Here’s what I’m thinking: All custom client applications and integrations should use DFS going forwrd–assuming it doesn’t have its own issues. DFC programming should be restricted to the uber-server, that big box drawn around the real docbase servers, webtop servers, DFC servers, full-text indexing servers, site caching servers, etcetera. Only push DARs–yes, they had to go there–to Documentum application servers. What goes on in the uber-server stays in the uber-server–including every single line of DFC code.

Aspects are too useful to discount for a few architectural missteps–as long as you’re careful where you walk.

Tech Deep Dive: Exploring Documentum Architecture — Leveraging Composer and Aspects
Available soon on EMC Events On Demand (developer access may be required)