Several weeks ago, I promised a reader [EDIT: Read the comments here.] to discuss why I would think twice before adding a TaskSpace interface to a solution that already included an eRoom interface. Aside from the obvious that TaskSpace is a brand new interface and could most likely use service pack or two, I am always hesitant to provide too many interfaces into a solution. There are times for it, but it is important not to add them just because you can.
Defining an Documentum Architect, An Open Letter
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.
Consolidating Documentum Tips
I’ve wanted to keep my Documentum Tips easy to find. I started with a category, but I wanted to draw more attention to them. I also tried to keep them elevated in the Words of Choice, but that took more effort than I originally anticipated. Plus, it would implode over time.
So I’ve created a page that will house a link to every tip that I have written. I am including the date they were updated and a quick blurb on each one. Right now there are only three, but I plan to start writing them at a slightly faster rate. Not that I will be learning that much more that much faster. I am just going to be more diligent to write things up as I come across them. Enjoy.
ECM Standards, SAML, and the DFC
Time for some more dialog with James McGovern. I love this kind of discussion because it raises awareness of the issues in the community. James replied to my last post on Standardizing Authentication. There is a problem with written communication sometimes. No matter how clearly you think you write or explain something, someone will always either misread, misunderstand, or misinterpret something. Before I get into that, two things first.
In another post, James says something nice about ECM. Understand that ECM provides value regardless of whether it has standards. Can you feel the love? He does qualify that he isn’t pleased with the vendors, but we now know how he really feels.
Second, I wanted to say that James is dead on with this statement regarding SAML and Documentum. The beautiful thing is that you shouldn’t have to learn how to write this type of thing as this should be out of the box. He is absolutely correct. I shouldn’t even need to think about how I would implement SAML in Documentum. That is EMC’s job. Now on to the rest of James’ response/analysis.
Review: Patterns of Enterprise Application Architecture
 |
Patterns of Enterprise Application Architecture
2003 |
I saw this book on the desk of a colleague. I had already been thinking of picking it up, so I did. I learned two things from this. One, ownership of a book does not equate to an endorsement. Second, take more time when determining if a book is going to meet the desired goals.
Standardizing Authentication
Been a busy week on the ECM standards front. There has been a lot of discussions going around. I’ve been silent on the topic as I’ve been focusing on learning more about SAML and XACML so that I can respond to James’ question. Plus, the dialogs are going great and I haven’t needed to keep them going.
I am not ready to give James an answer on XACML, yet. I feel I am ready to start a dialog on SAML though.
Tips: Windows Installation for Content Server
Going to start categorizing my Tips/Documentum advice into a separate group. I want these things easier to find. Their relevance doesn’t really fade, so hopefully this will help keep them around.
I just helped someone install Content Server. I sometimes don’t even think about many of the details of an installation. I’ve installed it so many times that I just do it by instinct. I decided to put down some tips into this to help those starting the process.
Storing Form Data and Records for the next 100 Years
Recently Mike Herrick asked a question on his blog about what formats should be supported for Form Data and storing Content for archival. James McGovern appears to have misinterpreted the question and asked which of these formats ECM Vendors should support and why they can’t convert between formats out of the box. His question has merit, so I am going to address both.
ECM Standards Flurry
Hadn’t planned on this post today. Saw a post out there by Bex Huff that I wanted to comment upon. Bex basically rants in his post. I’m not being dismissive, he states that he is ranting. I like a good chunk of what he says, but I have two comments.
First, a Correction
In regards to universal connectors created by third parties, Bex states that they were bought up and shut down by Documentum. This is not accurate in the least. There were two major players at the time in the US market and another in the European market. Here is what really happened.
Tips: Render Me This
Time for one of those posts that I originally thought would be more dominant in my blog, using Documentum Technology. After all, it doesn’t matter how well your system interacts with the outside world if it falls on its face when it is used.
It is time to talk about renditions. A heavily used feature that people rarely actually think about. For most, it is just a way to have a PDF version of your favorite Word document for review or publishing. For some, it is a critical piece of a Digital Asset Management solution. However, it can also be an easy way to create a relationship.
Word of Pie 
