EMC’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?
JK: The Frontier Mentality. Document Management as a software practice was a relatively new endeavor. That frontier mentality made for exciting times as we used a new, open tool with an interesting model to solve document management problems that hadn't been possible to solve before — because of the tool itself and supporting technologies like storage and intranetworking maturing. People still wondered what was possible and kicked off big sky projects. Documentum provided a framework to solve those problems, but it didn't force you to solve it in one and only one way (think SAP for ERP).
VB: And was it because of these three “good ideas” that Documentum won market share in Life Sciences, Aerospace, Oil and Gas, Banking, Insurance and Engineering fairly quickly?
JK: While they’re probably not the only reasons, these three things made for an exciting first decade with Documentum. The tool and times have changed considerably since then. It's not unlike the space program; exciting while it's new and experimental and boring after it became routine even though it was still difficult and dangerous. You can compare it to how many people watched Apollo 11 versus Apollo 13 before things went awry.
Document Management can still be interesting and challenging, but people don't always see it that way and therefore only spend for what they know, rarely asking what's possible.
VB: And I take it that you’re more interested in figuring out what’s possible?
JK: The most interesting part of software development for me is solving the problem — either a new one for the first time or an old one in a totally new way. With Documentum, that creative process pay-out came in part from the scale of the projects; soup-to-nuts document management for a new drug, living documentation for putting together and maintaining B-52s. My first project was a real Hoover Dam; my last was more like a bathroom renovation. It's hard not to miss that era of big ideas and big solutions.
- The Problem With Yammer? People Don't Use It
- Did Forrester Get Its Digital Experience Wave Right?
- Want Engaged Employees? Show Them the Big Picture
- Forrester Wave: No Leaders in Digital Experience Delivery
- A Man, a Blouse and an Awesome Customer Experience
- Reinventing Digital Asset Management
- Master Customer Experience in the New Age of Retail