There is currently, and has been for a while, a shortage of good Documentum resources out there. Over the years, I have learned that a majority of non-referred candidates cannot perform at a higher level than that of a simple developer. This is because they do not have a core understanding of what is required to design a complex Documentum system.
So, the question remains, if I can’t hire enough good Documentum resources, what do I do? It is simple and painful. You have to grow them yourself. If you are lucky, you can find some that can quickly transition into mid-level roles. The upper-level Documentum Architect role requires experience, and there is no way to get around that requirement.
The core things to look for in someone to develop is:
- Java: This is key. If they don’t have Java experience, there is typically too much to teach. If they meet some of the other requirements, or have solid skills and experience with two or more languages (not counting HTML, XML, or any simple scripting languages), you can put them on a project part-time so they can acquire the knowledge. Most developers today, however, have this skill if they have the other features.
- Object-Oriented Design: This is useful. They should understand the concepts, or at least when exposed to the concepts in a conversation, be able to quickly comprehend and expand on the topic. Documentum is composed completely of Objects, even if it resides in a relational database. With the advent of D6, the concept of aspects was introduced. The more that the candidate understands this topic, the higher they will be able to climb on the Documentum technical ladder.
- Database Design: This isn’t a direct skill. I have found through experience that those with database design skills typically do better at designing ECM solutions as a whole.
So now you have your candidate identified. How do you get them started? Well, you need to send them to training first. Documentum’s Technical Fundamentals course is a MUST! I cannot stress that enough. If they are going to be a technical resource on any level, they need to have taken this course at some point in their career.
Any further training depends on budget and the desired technical path you need them to start down. Once they are trained, there are several resources that each person should have to facilitate their mastery of the technical side of Documentum:
- Project Team: Make sure that they are on a team with at least one experienced and capable Documentum resource. This person doesn’t have to know everything, just know how to find the answers among the many resources.
- EMC Developer Network: This site has code samples, articles, blogs, and discussions around best practices. They can ask questions and contribute to the community. When trying to craft a solution, either high-level or some custom functionality, this is the spot to start looking.
- Powerlink: While I have not enjoyed Documentum’s support site under the EMC banner, it is getting better. The forums are a great resource for trying to discover why some piddling piece of code is not working. Make sure that they have an account to access this resource and know how to navigate it.
- dm_cram: This is a site focused on helping people gain the new Documentum certifications as part of the EMC Proven Professional program. Right now they have information on the Content Management Fundamentals exam, with more to follow on the other exams. Once they have support for the other exams, this site and its resources could become quite useful and well known.
- EMC World: This annual conference, held in Boston in 2010 and coming to Las Vegas in 2011, is composed of three separate conferences. Momentum (the Documentum User Conference) and the Software Developer Conference. Attending this on an annual basis can provide a majority of the subsequent Documentum training needed by most diligent technical, and non-technical, resources.
The last key to growing Documentum resources, KEEP THEM! For every quality Documentum resource you develop, there are several companies that will want to hire them. You need to keep them happy and make them feel appreciated. This isn’t just about salary, but don’t underpay them either. Understand what it costs to replace them and where they want to go in their careers.
Well, that is what I try and do to build a resource. Any experience you have with training Documentum resources would be useful to share. If everyone starts to effectively train resources, the large amount of resource sniping may actually decline to a reasonable level.
More Posts
Adding links here to other posts as I add them to my blog that are related.
- Documentum and ECM…A Career or a Job?, 2008-07-15
- A Career or A Job…Redux, 2008-08-11
- Throwing Documentum Developers into the Fire, 2009-10-07
Word of Pie 
Great read! I too agree with the approach to building documentum talent. The good talent that already exists is hard to find and even harder to entice. We find it very hard to find good, quality candidates so we too have turned to using sr. java developers. This takes a big commitment on both ends. I’m sure a lot of companies out there struggle with wondering if it’s worth training your employees…you either train them and then leave or don’t train them and they leave.
LikeLike
This is nice article to guide new entrants in Dctm world. But from when would you consider or market would consider you a Documentum Architect. You have mentioned Java, Object Oriented Programming and RDBMS concepts are essential. But these days, any Documentum Architect would be required to possess knowledge of J2EE and Java Frameworks like Struts, Hibernate, Spring etc….. and application servers like Weblogic or IBM Websphere… Oracle, SQL …. all documentum products…
Few questions- how can somebody gain experience in all other technologies who started career straightway in Documentum ?? Documentum itself has so many array of products/components to learn. Not everybody gets required exposure of different technologies in different projects….So don’t you think so much expectation is a bit too much unless given opportunities. I know somebody can learn many of these things outside but how much time would somebody get apart from his full time Documentum Job ?
I don’t think SAP consultants are asked for exposure in all other technologies even. They are always in SAP world all the time. Then why Documentum jobs required ALL POSSIBLE technologies experience required for Architect’ job ?
LikeLike
There are indeed different levels of Documentum development. You need to understand the underlying components of the technology. IMHO it is database design and SQL, object oriented programming, Java, XML, Javascript and Web Services. Good OS chops are also required that is a given these days. I find that there are different skills sets too and each one adds to the balance of a development team. For example you need the ninja coder on the team that can reverse engineer black box components in a pinch and keep the code design on track to be re-usable and scalable, you need a methodical competent programmer, hopefully with solid RDBMS background, that can step through and systematically debug complex code, a good UI designer and coder is also required to focus on the user experience and of course the big picture person, not necessarily a hands on coder, but one that understands coding and design to design solutions and meet with the client and act as a point person for the team.
I agree that you need to keep them around. I have seen so many teams struggle to ramp up new hires after letting a good developer go because of funding or project timing. The good one will gravitate to where they are treated well and respected. It takes a long time, perhaps 1 to 2 years to train a developer how to react to an urgent demand in a best practice approach, as opposed to leaning on their previous experience and “hacking” the platform. And for the Sharepoint guys smirking out there (I know you are out there 😉 it is the same for any ECM system. If you think it is OK to hack SharePoint it means you have not been trained properly… seriously.., those APIs and business rules are there for a reason… OK I get off my soapbox now…
There has been, over the years, some bad press about Documentum web apps. Some of which was earned and much of which is the result of utilizing under trained and inexperienced developers and solution designers. They end up under scoping projects, low balling quotes, going cheap on resources and paying the consequences. For any CIOs of especially CFOs out there, pay a reasonable price to keep a competent development team, farming out only after careful analysis and in a well managed project. Don’t just outsource it and hope for the best…
The end result is the inexperienced people needing to blame the tools. Oddly if the tools are tossed it will just happen over again with the new tools until you find the underlying issues and correct them. ECM is by definition complex and difficult to learn and implement.
Trust me, the past few years for me have been called in to correct off track projects and most, but not all, were caused by this very issue.
LikeLike