SharePoint and Documentum

More than a few blogs have been written comparing and contrasting the pros and cons of these two products, which -- ostensibly -- look like they might do many of the same things.

Well, yes and no.

It's my prediction that most larger customers will see a compelling case to use both products.

Here's why ...

The Standard Disclaimer

I am not an expert on ECM (enterprise content management), nor am I an expert on collaboration tools, or Documentum, or SharePoint, or much of an expert on anything else.

I do believe we're in the midst of a transition to becoming a society of knowledge workers, and the stuff we will all use will be rich, unstructured information complemented by collaborative workflows, rather than the transactional information that we cared about in the last decade.

And, marketing materials aside, most organizations are starting to realize that they have a major challenge on their hands -- how will IT support the emerging generation of knowledge workers?

And we're not just talking about mobile apps and workgroup collaboration, folks.

ECM -- From Tactical To Strategic

When EMC acquired Documentum, most of their business was what I understood to be "content applications".  Maybe it was insurance claim processing, or managing web content, or dealing with invoices, or something where the fundamental data type wasn't a transactional record.

But over the last few years, I've seen more and more customers come to the conclusion that ECM will be the underpinning for more and more of the value-added business processes they'll need in the future. 

One of my core beliefs is that it's pretty much inevitable that ECM will be thought of as corporate infrastructure, and not just an application.

That's where most of the high-value information will be.  And that's where most of the high-value business processes will be built around.

And Then Came SharePoint

For many years, people interacted with Documentum in a variety of ways, including eRoom. 

Nice set of apps, but I think it's fair to say that it was a different user experience than, say, a native Microsoft experience.

And, of course, we saw a few large-scale Documentum deployments that faced user adoption challenges simply because it was something new to learn. 

Heck, I had to learn eRoom.  Not a bad app, but -- well -- it wasn't what I was used to.

Human nature, you know.

As we started to work with Microsoft in 2005 and 2006, it was clear that Microsoft was going to do something big with Sharepoint as part of Office 2007. 

And it was pretty clear to many of us that this would solve one of the fundamental challenges facing newer ECM applications -- no one had to learn anything new.  Users could work in their native Microsoft environment, and get the back-end power that Documentum brought to the table.

Avoiding The Sprawl

Not to digress, but prior to coming to EMC I was involved in a Notes deployment. 

Our first challenge was to get everyone to use Notes.

Our second challenge was avoiding what came to be termed Notes Sprawl.

Everyone and their brother had their own set of Notes application. 

Didn't like someone's app?  Build your own!

We ended up with tons of inconsistent information spread everywhere and none of it lined up.  There'd be a copy of a file in a file share, and another in email, and many more in everyone's invididual Notes databases. 

And when it came time to actually make everyone work together in coordinated business processes, well, we couldn't do that too easily.  But we had some great ad-hoc collaboration tools.

What we lacked at the time was the back-end of Notes for the IT guys.  Even if the tools existed at the time, we certainly didn't have the foresight to think about things that way.

Things like a common repository and some sense of master data management.  The ability to freely integrate with Notes and non-Notes entities.  The ability to orchestrate workflow inside and outside of Notes.  The ability to handle rich content as effectively as structured content.  The ability to manage information and control processes centrally. 

And so on.

Would History Repeat Itself?

Many of us thought so.  SharePoint was going to be such a powerful tool that everyone would want to use it.  There was the problem, and there was the opportunity.

So EMC wisely invested in a robust set of hi-def interfaces between Documentum and SharePoint/MOSS. 

We wanted to make sure that customers could SharePoint for what it did will (e.g. excellent user experience) and use Documentum for what it did well (e.g. most everything else).

We tested the idea with a few large customers, and -- not surprisingly -- they agreed with our hybridized view.  They wanted to give their users the ability to use Sharepoint and its applications -- yet still meet a whole list of corporate IT needs that weren't available in SharePoint

Moreover, they saw the perils (and the potential) associated with putting these powerful tools in everyone's hands.  And they wanted a back-end strategy.

But It's Not So Easy

From a customer perspective, this sort of approach makes total sense: provide options and value-added integration that makes for a 1+1=3 equation. 

And, when you look at what SharePoint does at the front-end, and what Documentum does at the back-end, well -- it's not too hard to see the win-win.

To both EMC's and Microsoft's credit, at a corporate level we both recognized that many customers would need both, and that -- working together -- we could achieve things that neither company could achieve by itself.

The products were integrated, and launched, and then ... well, that pesky human nature thing started to kick in again.

You see, many people have built very successful careers around one product or the other, but usually not both.  And, inevitably, people starting choosing sides.

And although there's a place in the world for product-by-product feature comparisons, I think we're being held back by saying that one is better or worse than the other. 

I would offer that doing a feature comparison of a wrench vs. a screwdriver isn't too helpful, and misses the key point -- you're probably going to need both to solve your problem.

Ordinarily, this sort of stuff doesn't bother me, but I think this is one important area where I think product religion might be holding customers back.  And that's not good.

I repeatedly see the case -- over and over again -- where both products are needed to solve the business problem.  But, unfortunately, folks on both sides of the discussion may sometimes paint a picture that it's a moral choice. 

It's not.

As an example, most customers today that I know use both Windows and Linux -- there's room for both, and they're not direct replacements for each other, despite what some would lead you to believe.  And we'd all like them to work better together, wouldn't we?

Customers Will Decide -- They Always Do

For the last year or so, I've seen more than a few customers get the synergy between Documentum and SharePoint.  They understand (and seem to agree with) many of the themes I've shared here.

But, I think there will be a much larger audience that do the SharePoint thing, and end up with a nasty case of SharePoint proliferation. 

They won't have the back-end tools (or methodologies) to take this powerful Microsoft tool and to exploit it to transform how work gets done in the modern enterprise.

Or they'll stick with Documentum-based apps, and turn away from all the rich end-user functionality found in SharePoint.

We'll see how this one plays out.

Comments

[Jonathan Williams]

Hi,
I have no disagreement with you but it would help if you site one or more busines sceanrios where using both makes sense.

[shiningarts]

I have read this blog twice now. As Documentum offers a SharePoint connector, it is quite interesting that we are comparing SharePoint with Documentum. SharePoint is not a true ECM at all. It is a social software with Microsoft’s intrinsic proprietary architecture, and a few ECM characteristics like Microsoft’s file system. The primary thing SharePoint has going for it is the familiarity we all share with the Windows environment. It appears that we somehow know how to use it because it is based on our familiarity with the system we use day in and day out.

Some shops choosing SharePoint over Documentum may never feel the need to venture beyond SharePoint because it can provide some basic characteristics of ECM. They don’t need anything other than what SharePoint can provide for them. I believe it is somewhat unrealistic to try to convince them to buy Documentum because they don’t need the advanced capabilities that Documentum offers. On the other hand, those companies that have a more specific and essential business need for ECM will choose Documentum over SharePoint because SharePoint will not satisfy their need.

It sounds great that SharePoint and Documentum can work together. But, I for one, don’t have the extra resources to acquire fairly weighty applications without having a practical business case to do so. The relationship between SharePoint and Documentum working together is like IBM trying working together with EMC. Theoritically, maybe. Practically, maybe not…

[Brandon Hornibrook]

Sometimes it makes sense to use the best of both worlds and integrate Documentum and SharePoint.

Using this approach you can leverage the powerful and robust document management features of Documentum but provide SharePoint’s better interface to users.

Unbounded Solutions has developed a solution to integrate Documentum into SharePoint using a suite of web parts.

This solution allows users from SharePoint to work with documents in Documentum and perform actions such as: edit and upload documents, participate in workflows, lifecycle management, work with virtual documents, request and view renditions, subscribe and view their inbox items.

More information is available at:

http://www.theunbounded.com/products/documentum-sharepoint-integration/documentum-sharepoint-integration.asp