So, I’ve now taken two of the exams offered in this space by EMC. I wanted to post some thoughts on the program as it has been applied to Documentum. I’ve been through more than one IT certification program in the past (including a Microsoft one that expired years ago), so I’m not new to this process. First, an overview of the EMC Proven Professional program.
Information
This is the work part. Posts here relate to the craft of my career and profession.
What is in a Title? My Journey to EMCApD
So I decided that as head of my ECM Practice, I should set the example and get my EMC Proven Professional certification for Content Management. I took the first exam a couple of months ago, Content Management Foundations Exam (E20-120), and blew it away. This is good and what one would expect from any experienced Documentum “expert”.
Now came my dilemma. I’m an ECM Architect. I still develop, and have done so quite extensively in the past. I’ve known for quite a while that the first “Architect” exam isn’t due out for at least until the end of Q4. The problem was that I wanted to move beyond the Associate tag and grab the Specialist tag. To do this, I would have to take one of the two Application Development Specialist exams. That meant either the Server Programming Specialist Exam (E20-405) or the Web Application Programming Specialist Exam (E20-455). I had done a LOT more work with the Documentum Foundations Classes over the Web Development Kit course of the years, so I thought I would try that.
My First Book Report in Decades
Normally, I don’t read too many work related books. I spend my time on public transportation reading either an entertaining Baseball Book or some good History. I normally expand my knowledgebase with experience, seminars/conferences, and research on the web. However, with the advent of D6 as an “SOA platform”, and the ever-enlarging reach of my projects, I decided I needed to accelerate the normal learning curve and do some extra outside reading. To help other Enterprise Content Management experts expand their knowledge, I decided to offer brief reviews of the books I read that apply to that world.
I am having to make Documentum part of the larger Enterprise more and more on each successive project (the challenges around that are best left for discussion another day). I have decided that I needed to at least become more familiar with the concepts around Enterprise Architecture. If my systems are going to be part of a properly architected Enterprise, I want to make sure I understand the high-level concepts and goals. I hadn’t run into any issues or misunderstandings yet, but I figure why wait?
After asking around, several people recommended the book, Building Enterprise Information Architectures, by Melissa A. Cook, to serve as an introduction into the concepts of Enterprise Architecture. So I borrowed it from a colleague and started reading. Only being 180 pages, it didn’t take long.
SharePoint vs eRoom, or Microsoft vs the World?
I’ve been discussing this topic of late. I haven’t been able to dive into SharePoint since my last post, but I have had some rather interesting things come up on this topic and wanted to share.
Josh Maher came up with quite an interesting view in his blog. SharePoint is for Microsoft people, and eRoom is for everyone else. His arguments seem sound until one detail comes forward, eRoom only works on Microsoft platforms. I don’t want to address the future here, just the present. eRoom requires:
- A database. SQL Server 2000, SQL Server 2005, or an embedded SQL database that installs onto windows.
- Windows Server 2000 or 2003 with Internet Information Services (IIS) installed.
Doesn’t sound very anti-Microsoft to me. The difference here, as Josh points out, is that SharePoint works closely with all the latest Microsoft products. However, the latest SharePoint server also needs those newer products to fully garner all of the benefits. Microsoft wants you to upgrade your Office suite. That is more money in their pocket. When eRoom makes a release, they don’t typically require you to have the latest version of all the integrated products.
Tips: Invasion of the Virtual Documents
So, I have two topics that are burning for another post, but I had something fresh, and wanted to post on this topic while I still had my thoughts in a semi-coherent collection. Recently, I have run into more designs utilizing Virtual Documents than I had, quite possibly, ever. Your first thought may be that I have been working on similar projects. Wrong! Of these systems, I have seen one where Virtual Documents was called for, and the rest where I just wanted to shoot the designer. Well, once I just laughed because I couldn’t believe my eyes and didn’t have to fix it.
Now, I don’t know if maybe I happen to be in the wake of a rogue Documentum “Architect”. I use that term loosely because that is a term being bandied about more and more frequently. There are very few that I consider Documentum Architects, fewer that are ECM Architects, and none of them, including myself, are Enterprise Architects. However, that is a post for another day.
Regardless of the cause of my problems, I want to take a moment to clarify something that I learned back in Technical Fundamentals years ago, and that hasn’t changed. Virtual documents are a way to combine documents whose contents have a variety of formats into one document. That is a quote from the 5.3 Content Server Fundamentals. What does this mean? Here is a simple example. Say I am working for a Government Agency. When I produce the massive volumes of documentation for any project, I invariably have the same project overview and set of appendices in most of my documents. Some subsets of the documentation may share more content. A Virtual Document allows me to link all of the documents together, assemble them, and publish them as one document. So when I publish all of my documentation, I can be sure that my common resources match. When I update one, I update all.
Now there are several XML processing applications of Virtual Documents as well. However, Virtual Documents are not for grouping a set of files together, just to group them. Something I have seen (modified to protect the innocent) is using Virtual Documents for Case Management. In a case, you have source documents, reference documents, and output documents. That is an oversimplification, but it’ll serve here. What I have been seeing is making those all part of the same Virtual Document! DON’T DO THAT!!! If documents are related, you have at LEAST three easy choices:
- Put everything into a folder. Hmmmm. I kept the original files in a folder on a desk, why not a folder in my ECM system? I can even store Case information on the folder.
- Tag all the documents with a piece of metadata, like, oh I don’t know, a Case Number. Then you use a quick search to retrieve every related piece of Case content with a simple search. In D6, Documentum is taking this further in their Taskspace interface and not showing folders at all, but using “Smart Folders”. Smart Folders are just simple, saved searches based on some indexed value.
- Define a relationship within Documentum. Documentum already uses relationships for several functions including Annotations. You could define a custom relationship and implement it. This requires a little more work than the other two options, but there are times that it would prove more efficient.
There is more than one way to skin a cat and there is more than one way to design most systems. However, Virtual Documents are not to be used lightly. There are a lot of complications that can arise in everyday use of Virtual Documents. For instance adding or removing content from a Virtual Document requires checking the parent document in and the out. There are times where they are called for, but they should be clearly thought out before implementing.
My Deconstruction
Well, it didn’t take long, but my first post on Standards has drawn some attention. James McGovern deconstructs my post doesn’t appear to pull many punches (though he may very well have done so). If you are in the ECM space, read his post. It offers an interesting view on the ECM space from the outside. While I had thought about waiting to respond until I had heard from others, my faith that I will hear from others on this topic is not very high. I would love to be proven incorrect. I welcome the feedback, but I’d like to hear from some ECM people.
I think I will start by saying that I agree with James on most points and he has a lot of valid questions. For some of them I know the answer. For others I don’t but plan to find out. And for a few I’m not sure if I can get the answers. I will be posting more on Standards as I go forward and learn more. I need to learn more first so that I don’t completely cut anyone off at the knees unfairly. Those that deserve it on the other hand….
The point of my post was mostly to mention the little I know about EMC’s efforts and remark on how my view of Standards has changed over time and recently. They are important and we need them, yesterday. Now that I’ve had this realization, I plan on making others care as well.
I will answer one question, what my definition of leaders in the ECM marketplace is. It is a very narrow definition of leading. I was referring to those that lead in the vision of what ECM is. These are the people that developed an ECM platform that can serve all parts of the Enterprise, not necessarily a platform that works as a part of the Enterprise. The type of leader that is needed, that James refers to, may not exist yet. I reserve my final judgment until I can confirm my gut on this issue.
Technology Standards and the Enterprise, Getting Too Much Attention?
I have a bunch of things that I have wanted to talk about on this blog. I am going to be the first to admit, that standards wasn’t really on my radar to write about here. In years past, whenever I got to the standards portions of ECM presentations in years past, I only cared because saying a product met standards meant it might be easier to sell. More recently, I had begun to understand and care, but only enough to pay more attention and think about how it can help my current projects. In the past few weeks, the topic of standards has been showing up all over my radar, and then it hit me. I need to make everyone else care as well.
SharePoint and EMC
One of my favorite Documentum bloggers outside of yours truly, Johnny Gee, has been blogging of late on SharePoint and Documentum. He ran a three part series comparing the two. Yesterday, he posted an entry comparing SharePoint and eRoom. This was even commented upon by an Enterprise Architect blog that I regularly read by James McGovern. I read the entry, and it has drawn an interesting, and very dead-on, observation. The latest post has a very decided pro-eRoom stance. In Johnny’s defense, he was just posting some observations from a reader and not taking credit. One the other hand, it is a very biased view of the world.
First, let me say that I do not have the depth of knowledge to take up SharePoint’s defense in detail. I am also not as inclined to do so being a little pro-EMC. However, I will make two statements about eRoom and SharePoint:
EMC’s Vision of ECM 2.0
I’ve previously posted on how D6 is laying the foundation for ECM 2.0 (E2), as well as some of the key features of that release. Before I start delving into some of those features in detail, I though I would go over what E2 is envisioned to be once it is delivered. Personally, this is a lot of marketing-speak, as is Web 2.0, but it shows a lot about the why in the future of Documentum.
Bonus Post on the CMA
Bonus post? How can there be a bonus post after two days of not posting??? Simple, while I was working on the post that follows this, I wrote this post as part of it. I then decided to break it out. Thus bonus. Since I decided this had to be posted first, the chaos followed.
Here is a quick breakdown of how EMC is now classifying their Content Management and Archiving (CMA) group (the latest name for Documentum product family) into four Content Types:
- Knowledge Worker: Collaborative Content Management, focusing on personal and team productivity and extranet collaboration. This is where all the traditional Document Management and Collaborative solutions go to roost. This includes office documents, discussions, emails, project plans, and so forth. Products and features that are hidden under here include Lifecycles, Enterprise Application Integration such as Content Services for SharePoint and SAP, eRoom, Collaborative Edition (CE), Content Intelligence Services (CIS), and Enterprise Content Integration (ECI) Services.
- Transactional Content Management: This is basically Captiva plus all the fun business process tools to make them compete with IBM, formerly known as FileNet. In addition to the scanning and imaging, they have thrown in Business Process Manager and their Forms tool. The new Taskspace is also under here.
- Interactive Applications: Here is our friendly Web Content Management (WCM) and Digital Asset Management (DAM). They have combined these, in a fairly astute move. Let’s face it. These days everyone’s website, except mine, has lots of rich media. They need to work together closely. Supporting this is the Content Transformation products as well.
- Archival Content: Welcome to Records Management (RM) and all the fun of Archiving. While the other categories cover different types of content, this covers the last stages in a piece of content’s life before it is lost and destroyed forever. This group covers RM, Archive Services for Reports and Email, and all other Archival Services products. I don’t focus on this group much as Records Management isn’t changing quickly and until Documentum completes the creation of their new lightweight sysobject in D6 sp1 (yes, I am already waiting for the first service pack coming next winter), the use of the Documentum Content Server as a platform for massive archiving, read emails, is probably best left in the lab.
How long will these new divisions last? Longer than normal as they seem thought out. The only threat that I see is if the overall platform development is hindered by this division.
Word of Pie 