Documentum Talent Revisited

I recently searched google for documentum talent and came across an article from a fellow ECM blog entitled, “Documentum Talent”. The issue I have with this article is that although it is informative, it only scratches the surface in terms of understanding what takes to create true Documentum Architect talent. Java: yes; OO design: absolutely; ECM experience at any level: priceless.

First of all, the tone of the article is conceited and has one of those boss man attitudes which says, “Technically, I know it all, so don’t question what I’m saying. You are kind of a smart guy, but you are all minions to my brilliance, mere duck tape to my superior abilities…” Some architects are arrogant, but most are mere mortals, stuck between a rock and a hard place, trying to please the users and the bean counters.

Ok, whatever the tone, let’s focus on what is missing:

Business Requirements
I’m sorry, but Java and OO design as core to Documentum developers is obvious. If you can’t find this core in a developer, don’t hire them period. What is much harder to find (and more core) is a developer with business requirements gathering experience. Hello, what does the User want? This is why User’s are flocking to Sharepoint, “Talent” as defined here have been too technical and not business savvy enough. They thrive on xml payloads and not enough UI, search, and ease-of-use. Not mentioning “business” or “User” anywhere in his article on Documentum Talent explains the disconnect that has been going on for years between implementation and design. Talent is not knowing webservices only, it is knowing the “why” behind integration needs? Why CMIS has taken so long to emerge. The reasons behind needing to integrate applications are just as enlightening as the technical solutions that make it happen. Business units fund these applications, IT builds them, architects integrate them, but what decisions were made in the past that required two document management apps, for example, or why was Sharepoint introduced?

Knowledge of Competition
Sharepoint didn’t just appear this year to scoop up ECM. It has been around for years, honing its functionality. Taskspace was a joke, it was buying time for Center Stage which was a few years late. Now we have Sharepoint and Alfresco taking business away in circumstances where the EMC licensing contracts are up and the entrenched Documentum Users are fed up. Technology focused architects have helped create this mess. Just make it faster and improve the SLA, the users will be happy…

Long-term, Goal Oriented
Beyond the politics within an organization, how projects are funded, who is technocrat of what services delivery group, lays the long-term vision of the solution at hand. What role does the solution have to the ECM vision in three years? In five years? What are the overarching goals of IT? Knowing how to work with these, question them, and design to them is very hard to find in our technically “superior” architects. Knowing how the historical impact of ECM has influenced the current design and plans for the future. Who is promoting collaboration and why? These are key to talent. In politics, bringing in Sharepoint is the equivalent of promising jobs to your constituents who have been suffering from EMC’s lack of attention to your needs.

Change Management
I’ve seen many Documentum installations that are OOTB with shortsighted object models, security, folder structure, workflows, integrations, etc. These are the result of profit hungry partners smirking as they write their SOWs. Some partners purposely put their blinders on when it comes to scoping their projects. They know full well that as soon as the current project is over the client will be begging for improvements. These partners purposely take shortcuts because they rely on their client signing on for more work. Technically, the project could be architected well, but the human interaction issues with the software may not have been fully addressed, leaving the user scrambling to duck tape their processes to a UI that is too constrained. Knowing when to give the users something for free is a key sign of good talent.