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.

Sharepoint vs. Documentum: Analyst Perspective

It depends on who's perspective you want to take when you compare Sharepoint with Documentum. Every person has a unique take on the Web 2.0, its marketing and hype, but the bottom line is that it is cheaper than proprietary software and can be an open source application that eclipses both MS and EMC. When I think of Sharepoint, I think of projects and ease of use. When I think of Documentum, I think of content lifecycle management.

Resource Delivery Director: wants one solution, centralized with easy configuration. This person is usually religious on a programming language so depending which one .net or Java, this will be part of the decision. This person has pressure to deliver applications balancing this against resource expense.

Architect: wants scale, performance, and integration, plus local developers. This could be a problem for Sharepoint as good developers work for partners, they are not mature enough to contract on their own. Also, good luck out sourcing to India for Sharepoint folks. That will happen, but not yet. Integration and CMIS are also considerations. What apps are integrated, ease of webservice integration, identity management, workflow, etc.

Chief Bean Counter: wants a good ROI story. If a CIO has a preferred technology, she will find/procure a research study which is a proponent of it.

Users: want something that looks different than what they have, but they want everything they had. Do you put a new skin on an old application, or do you buy a whole new app?

Elephant in the Room: Open Source is coming, so EMC and MS are really on the same side here. Alfresco is not going away, neither are the other players. Google might trump everyone once it can’t grow everywhere else, why not tackle the source?

I have witnessed the demo difference between the two platforms and Sharepoint wins hands down. Partners selling these two products are the front line in this discussion. Partners who sell both are selling one short and hedging their bets. Find a partner who sells either EMC or MS and get their pitches, then write the matrix and gap analysis. Also, throw a third party in there for balance.

The main issues you have to matrix are business requirements and the key stake holders. Also, who’s a member of the steering committee.