In the next few weeks, a number of Documentum Architects will be gathering in Pleasanton, CA to define a Documentum Architect’s job description. I use the term Architect loosely because I imagine that for every true Architect that has been invited, at least one Documentum Developer has been invited as well. I could be wrong, but I know from experience that a lot of Architects out there are just senior developers.

However, that isn’t the point of my post. Due to conflicts that are preventing me from traveling to the West Coast for anything outside of a family emergency, I am was unable to accept my invitation to attend the Job Task Analysis (JTA) Workshop. The JTA workshop is the first step to building the certification exam that is due out by the end of the year. So I am writing an open letter to the actual attendees on the subject.

Documentum Technical Architect?

Now, I am not going to get to hear all the instructions and insight that has already been collected, so I have to anticipate. So forgive me if I go down a tangent that becomes invalid. The only definition that I am privy to prior to this workshop is that they are defining a Technical Architect, not a Solution Architect. This apparently means that they are focusing on the servers and storage and not software components.

This direction worries me a little. I am already trying to figure out how they are going to come up with 60+ questions down the road. When I am looking for a Documentum Architect, I am looking for someone that can look at a problem and pull in the proper solution components. I do want them to design the hardware that it all will sit on once deployed, but nobody I knows sizes that stuff from memory.

EMC provides a sizing spreadsheet, available on the Developer Network, that allows for a fairly accurate estimate on the sizes of the various server components. You need details on the amount of content, format, business processes, and user behavior. There are other details to collect, but they point here is that the sizing is calculated for you. So there isn’t much left. I would hope that all of the formulas behind that spreadsheet aren’t considered testable.

That brings us to Storage. It is pretty simple. This is a Documentum Architecture track. If I want to determine if someone knows all the storage product lines offered by EMC, I’ll look for someone with a Storage Certification.

However, all of these fears could be unfounded. I hope that the attendees remove them completely.

A Documentum Architect

What is a Documentum Architect? A Documentum Architect can do more than look at an ECM problem and design a solution. They have to be able to:

• Understand the different solution components, how they interact, and how they are optimally deployed.
• Designing and implementing customized components, including Lifecycles, Workflows, TBOs, SBOs, and Web interfaces.
• Take an existing Object Model and extend/modify it to support multiple ECM solutions without redundancy.
• Understand the pros and cons of UNIX/Linux/Windows and SQL Server/Oracle for different customer scenarios and platform standards.
• Integrate Documentum with other third-party products.
• Leverage SOA and how understand how it makes the previous point easier.
• Design optimal solutions, or create alternate approaches to fit within licensing restrictions. This includes sizing servers and storage.
• Intelligently discuss and challenge Johnny on his Do’s and Don’t’s of Design presentation. This doesn’t mean saying that he is wrong. It means taking several points and get Johnny to the point where he says, “It depends what you are comfortable with.” Johnny is a Documentum Architect. Anyone that can get him to say that several times on that selection of topics may be one as well.

To sum up, a Documentum Architect can design a Documentum platform for an Enterprise and all of the solutions that sit upon it. They can work with Enterprise Architects to make ECM a seamless part of the infrastructure. This is a lot, and it should be a lot. The above list is not complete. It is just a minimum.

Specialist versus Expert

The EMC Proven Professional program has three levels, Associate, Specialist, and Expert. I’m not sure if this session is the time, but please differentiate between the two when it is time. Everyone wins here. EMC can charge for two exams and we can identify beginning Architects and those that just breathe the stuff.

Another way to tell the difference…Johnny and I should be able to pass, barely, the Specialist exam without studying. We should have to hit the books to pass the Expert exam. There shouldn’t be anyone out there that could pass the Expert exam without preparing for it outside of EMC’s top Documentum Architects.