eRoom

CenterStage, the Latest ex-Collaboration Tool from EMC

Posted in CenterStage, Documentum, EMC World 2010, SharePoint, SharePoint Repository Services, eRoom, emc on May 14th, 2010 by Pie – Comments Off

I had a mission at Momentum this year that I had to perform for some of my eRoom clients. I had to determine the viability of CenterStage as a replacement for eRoom. Two facts answered my question:

CenterStage 1.1 is scheduled for GA in Q4. Calendars are a year away.

Really? Where have I heard that before?

That’s All Folks!

After I learned the above facts, I made the following announcement on Twitter:

Everyone take a moment to mourn the passing of #eRoom & #Documentum as a collaboration tool provider.

Needless to say, it turned some heads. There is one good spin…the release date for 1.1 hasn’t shifted, it is still Q4. Just don’t ask which Q4. It is like the developer that keeps telling the PM that they will be done in 2 weeks.

There is no way I can look my eRoom clients in the eye and tell them that they should wait for CenterStage if they want to launch a new initiative. Even if I believe in the roadmap, why should they believe in it? Given the focus on Case Management, how can we even be sure that the CenterStage will continue to receive the proper funds and staffing to meet all the goals.

Two years ago, CenterStage was awesome and was heralded as the replacement for eRoom. Here we are, two years later, and we don’t have data tables and calendars yet. We are still on version 1.0, though we did get a service pack in there.

Why did this happen? They were probably a little aggressive two years ago, but still, there had to be some continuing issues with implementing the features in the Documentum repositories object model in a manner that was efficient.

I bet all those architectural problems could have been solved with xDB. Just a guess.

So what to do now? While CenterStage is separated from the platform, as it should, the product isn’t being innovated like it should be as part of a more focused development team.

As far as I am concerned, EMC is currently not a provider of collaboration solutions.

Repository Services for SharePoint, EMC’s One Play

Meanwhile, did anyone notice a little announcement from Redmond on May 12? Apparently there is an earth-shattering, world-saving, product out from Microsoft. You may have heard of it, SharePoint 2010.

Last I checked, EMC has some decent products that work with SharePoint. One has been out for over a year and already works with SharePoint 2010, the poorly named “EMC Documentum Repository Services for Microsoft SharePoint”. For the rest of this post, we are going to call it Dave.

Dave is pretty good. It allows you to put the power of Documentum behind SharePoint. Dave has a few functional weaknesses, but it is ahead of all the other competitors in regards to capabilities and the larger ones are being addressed.

Seems to me that SharePoint may be a good collaboration tool to use with Documentum.

Of course there are the headaches of managing two infrastructures and all of that storage. Now if only Dave could work by talking to a Documentum instance in the public cloud. Man, that would make my life easy and make Dave an easy sell to customers.

On the Plus Side…

Well, there are two good things to come from all of this:

I don’t have to worry about writing a complete CenterStage-SharePoint analysis anytime soon.
At least EMC can use all of that CenterStage code to replace Webtop.

Webtop is on a perpetual lifetime contract with EMC, but I can see CenterStage in place to replace it and become their default cloud interface.

I figure given the current focus, CenterStage should be mature around the same time the Content Server is ready for the cloud.

The only question is if I’ll have retired by then.

CenterStage or SharePoint? An Early Look

Posted in CenterStage, Documentum, ECM, SharePoint, SharePoint 2010, eRoom on March 23rd, 2010 by Pie – Comments Off

I recently dissected a “comparison” between Documentum and SharePoint. Karma was paying attention and I found myself performing a comparison of CenterStage and SharePoint for one of my long-time eRoom customers last week.

Setting the Stage

A little background. This client has had eRoom Enterprise since 2004. There has been some isolated success in some pockets of the organization, but not everywhere. The initial champions left during the deployment and there was no real concerted push to use the system afterwards. It had grown slowly over time, but hadn’t become a must-use system for many.

Recent leadership has emerged that has said that they need a system to function as the go-to collaborative platform. After some quick thinking, they narrowed it down to SharePoint and CenterStage Pro.

CenterStage was an option because their eRoom licenses would convert cleanly, leaving them money for other items. EMC has promised to provide a migration tool which would diminish the migration costs. With their Content Server already at 6.5, they even have most of the platform setup and ready to go.

SharePoint is under consideration because, well, its SharePoint. People have used it and liked it. There would be a lot more up-front costs, but if it can deliver a better solution, it might be worth it.

The Demo

I was asked to come into the office to present a demo of CenterStage to their executives. While I did hold a slim hope for providing services down the road, regardless of their decision, I really did it because the system owner and I had been through a lot over the past six years. As I changed companies over the years, he always called me for assistance. I was more than willing to do this favor for him.

After setting up CenterStage on my laptop, no Internet connection at the demo location, I launched right into the demo. I flew through the features fairly quickly.

Then the fun began.

Where are the databases/lists? Next version this summer. Calendars? Soon. Polls? Eventually. Will it still synch with my Outlook calendar? EMC has promised functional equivalency between eRoom and CenterStage, but I couldn’t say for sure if it was in the next release.

They asked if it remembered what I was doing. I went to a page, opened a different browser and it took me to that same page. They asked if it worked in Firefox and Chrome. I quickly pointed out that I had done the demos in both of those browsers.

Is it 508 Compliant? Did I mention that this is a government client? It is not a small issue. I know other clients that would move now if the answer was Yes.

At the end of it, they all agreed that CenterStage would work once databases were moved over. They all agreed that they could at least wait to see what the next release held.

Next Steps for EMC

They need to release a solid update this summer. I figure they have only a few months after SharePoint 2010′s release before all of that eRoom maintenance revenue starts to file out of the coffers.

I was chatting with a few people last year talking about CenterStage. They said that it was too late, but I disagreed. There was still time. If the goal was to provide a solid interface and not directly compete with SharePoint, there was still time.

Well, that time is almost gone. Everyday that goes by, eRoom customers leave. SharePoint 2010 is coming out during EMC World. Probably a coincidence because I can’t imagine they view EMC as a competitor to worry about.

Only a few minutes left on the clock. Will EMC get it out the door? Will it actually work or will they have to rush it to finish it in time? That would actually be worse.

Stay tuned…

Documentum Renewal: Identity Management

Posted in Content Services for SharePoint, Documentum, ECM, Identity Management, LDAP, RSA, SharePoint, eRoom, emc, kerberos on December 29th, 2009 by Pie – Comments Off

Continuing my Christmas present to EMC. I’ve talked about Application Separation and the need to Focus on the Core. Now it is time to revisit a critical piece of the puzzle, Identity Management.

This is not a new topic for me. One of my most popular posts this year is the Single Sign-On, SAML, and Authentication in Documentum post that I wrote back in 2007. I’ve talked to EMC engineers and product managers about this issue repeatedly over the years. It was one of those things that James McGovern always pinged EMC on when he was a regular blogger.

This is the reason that I feel eRoom died. This is what will stop application developers from using just any ECM platform.

What is Pie Rambling About?

Some background on the topic. Identity Management consists of two simple parts. There is Authentication, proving who you are, and Authorization, what do you have rights to do now that we know who you are.

Documentum has several means of Authentication:

User synched with LDAP: While this is a pain at times, this creates an user object in Documentum that is kept in synch with the user in the LDAP directory. Authentication credentials are passed through to the LDAP server to authenticate the users. Groups can also be synchronized, including membership in those groups.
Network authentication: An user account is created and told to authenticate against a “domain”. This could be a local server account or on an LDAP directory.
Internal user with encrypted password: Useful for test accounts and users external to your network.

In all cases, an user object is created within Documentum. This is done in order to facilitate authorization.

Access to all content is controlled by Access Control Lists (ACLs). Users and groups are assigned rights. Since this is purely an internal Documentum function, if the user or group doesn’t exist in Documentum, they can’t be granted rights.

Access to perform actions in a specific Documentum application or process is controlled by roles. These are basically groups that cannot be imported from an external source.

And This Killed eRoom How?

If you’ve ever used eRoom “Enterprise”, and I mean really USED it, you know that there is no way to keep the permissions on objects in the Content Server in synch with corresponding link(s) in eRoom. This made non-eRoom interactions with content an issue.

If the security changed in one system, it only changed in that one system, leaving the permissions in the other unchanged. I would take some elaborate coding, which I never saw anyone implement successfully to resolve this issue. I never tried because I thought EMC should solve the problem and I could never get the cost justified. There were too many variables and we could get where we wanted, usually, by controlling the behavior of the users.

Of course, this crippled the potential of having eRoom as a front-end for Documentum. My most frequent advice, just use standard eRoom, skip the Content Server unless you really need it.

The core problem is that both systems have their own users and their own permissions. Users in one system may, or may not, be in the other system.

What you got was two systems that could never really together.

We now see the same thing with SharePoint and Documentum, or any ECM platform and SharePoint. You can use web parts, which are basically simple clients to Documentum, or you can use the Content Services which can store all content in the SharePoint Document Libraries in Documentum. Just don’t restrict the permissions any further.

Two systems, two sets of security. They typically both hit the same Active Directory server, but that means nothing.

Different content application, same problem.

Get ready folks, this problem is only going to get worse….

All This Waiting Around

Did you notice that the LDAP accounts are synchronized? That means that any changes made between the synchronization attempts are recognized by Documentum. If I remove a user from a group that is used to determine access to a piece of content, they will actually still have access until the next synchronization runs.

Anyone see a problem?

Now imagine I have a Federation setup. That means I need to wait for the Federation synch to occur AFTER the LDAP synch has completed before any changes are replicated to the member repositories.

Anyone notice the lawyers getting interested?

The only thing that is instant is the disabling of users. This is because Documentum asks LDAP to authenticate the user when they log into the system. Of course, the user in question has usually been physically removed from system access, so it isn’t as impressive.

Time to Solve This

EMC is improving. Slowly…

Kerberos support is incoming. SAML has been used with DFS. That is a step in the right direction, but that just addresses authentication. Read my old post on the topic for more information on SAML and Documentum.

For authentication, there is a big gapping hole. Something like XACML might be useful. Similar to SAML addressing authentication, it is an open approach to representing authorization. You know the most interesting part about it…

EMC is on the OASIS Technical Committee! They’ve met at the RSA conference! You know RSA, “The Security Division of EMC!” [The exclamation mark is mine, not part of their tag line.]

Maybe RSA and the Documentum architects could meet for lunch one day.

This is important. How are you, Documentum, going to serve as a platform to manage content for a large organization if you can’t manage the security of that content?

And all of you other vendors, don’t feel smug. I pose the same question to you because this is a broad issue.

Look at Lee Smith’s post on Case Management. In the comments, people talk about different systems needing to interact with different content that might be needed by the case management system. What if one system restricts access to a document, does it get accurately reflected everywhere? What if a records policy does something to the document, do the other systems know? How will those conflicts be managed?

This is no small problem. It also cannot be ignored as more and more applications look to access a common repository. Allowing open methods that can work in conjunction with CMIS is a good first step. Maybe Kerberos/SAML with the Access Control Lists from CMIS can do this now, but that doesn’t fix the synchronization delays.

Of course, what happens when I want an external Identity Management system to store my policies and entitlements? Thing get more complicated. [BTW, anyone know what ever happened to the RSA Entitlements Policy Manager product?]

I’d like to see a strategy to address all of these challenges. Something concrete that talks about the technical approach, not just “We plan to fix it.”. Maybe show a little leadership in the field.

Never going to get to the future otherwise.