Momentum_Vienna.jpgEMC’s Information Intelligence Group (IIG) (formerly known as Documentum) promises to make “the largest product launch in IIG’s History” at its Momentum Europe Conference on Tuesday. Content Management enthusiasts, CM industry analysts, and the Documentum Community at large, are all waiting, eyes and ears open, to see and hear what it (they) will be.

I am here in Vienna, Austria, covering the Momentum Europe conference live. I’ll also be sitting down with EMC IIG executives to learn about the company’s vision and roadmap.

While I don’t yet know the particulars of the announcement, I thought it might be worthwhile to talk with John Kominetz, a consultant and one of Documentum’s earliest solution developers, to find out firsthand why the technology was so disruptive in the early to mid 1990’s.

(Please note that at that time the concept of “electronic document management” was brand new and “CM,” the management of digital content, was but a seed. To put this in perspective, AOL was yet to become a household name, the “world wide web” was not yet widely used, and Google didn’t even incorporate until 1998.)

Here are the highlights from my conversation with John:

Virginia Backaitis: What was so revolutionary about Documentum when it hit the market?

John Kominetz: It was founded on three great ideas.

VB: Like? What was the first one?

JK: The Model. Unlike an RDBMS (Relational Database Management System), Documentum came out of the box with a transparent and extensive schema for describing documents and their relationships. You could see what Documentum thought documents were by looking at how they described them in their model, and they had some pretty good ideas right at the start.

VB: What was the second good idea?

JK: The DMCL (DocuMentum Client Libraries). The original API, with hundreds of methods, was designed to be pasted into programming languages by including five simple functions. In the early years, it was easy to integrate Documentum into your favorite tools, not be tied down to one or two languages/frameworks. The downside was no massive GUI IDE to auto-complete everything for you; you actually had to know the API.

VB: Was having to know the API a bad thing or a good thing?

JK: It was intended to be helpful, but having seen so much cut-and-paste crap code in DFC (Documentum Foundation Classes), maybe having to know the API is a good thing.

VB: You said that Documentum had three good ideas. What was the third one?