CenterStage

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…

Dissecting a Documentum-SharePoint “Comparison”

Posted in CenterStage, Documentum, ECM, EMC World 2010, K2, SharePoint, SharePoint 2010, emc on March 10th, 2010 by Pie – Comments Off

Saw a tweet today that was pretty exciting. It was referencing a “comparison” between SharePoint and Documentum. I was initially excited. I’d love to see CenterStage and SharePoint compared. I compared SharePoint to eRoom a couple of years back and wasn’t planning on a comparison with CenterStage until the database/list functionality was ported over.

My excitement was short-lived.

I instead encountered a piece that resembles propaganda more than a fair and balanced comparison. That may sound harsh, but I will defend the charge.

Subtle Hints

I first got an indication that there may be issues in the opening section. This quote in particular was interesting.

[Documentum] can be viewed as a content aware RDBMS layer above the traditional data layer.

That understates Documentum’s capabilities dramatically. The point being made in this section was that SharePoint was design from the UI to the backend and EMC has traditionally been focused on the backend to the detriment of the interface.

That is true and does help frame the conversation. Then things fell apart.

Comparing Apples to Peas

So things start to become interesting when the next section starts to discuss business logic. I won’t dive into the synchronous/asynchronous aspects of the BOF (it can be both), but the statement

Lately improvements in .Net and Microsoft SharePoint’s best friend K2 has begun to fully exploit the SharePoint vision

Uh, I thought this was a comparison between SharePoint and Documentum. If SharePoint is going to bring friends, like K2 blackpoint, to the show, can’t EMC?

He then begins to belittle the Process Engine. The term newish is patently incorrect. It has been around for years. I’m not saying that it is better than K2, either the blackpoint or full-featured blackpearl product, but we aren’t comparing Documentum and K2, are we? I thought we were comparing SharePoint with Documentum.

Cloud Capability

Microsoft has the lead here. I’ve used Documentum in the cloud, but they don’t have a commercial approach yet. The sentence that catches my eye here was:

Microsoft on the other hand is now releasing Office/SharePoint 2010 expressly to improve (if not completely mature) the cloud model.

Really? We are now comparing an unreleased version of SharePoint with Documentum. Forget that there is an upcoming release and announcements scheduled for May at EMC World.

Funny side note, Microsoft has decided to release SharePoint during EMC World. Coincidence? Unlikely in this industry, but distinctly possible. The Documentum related announcements could be unrelated to the Cloud. I would say that comparing SP2010 to anything should at least wait to see where those products are at the time of the SP2010 release.

EMC keeps its cards closer to the vest than Microsoft, so rushing to any conclusions about where things will be after EMC World is premature.

Besides, I’ve used an Amazon hosted Documentum instance before. It was a year ago for the AIIM CMIS Demo and it worked just fine. It isn’t a technology issue, so anything could happen.

That said, does K2 work with SharePoint in the cloud? Will it work with SharePoint 2010? These are all gaps in the analysis that are left begging for answers.

I do love how he mentions that EMC needs to take virtualization into account. I wonder if he forgot that EMC and VMWare are kinda tight.

Oh, and for the multi-server installation. I can’t definitively tackle that one, but it FEELS misleading and wrong. I just can’t prove it without more research at this time. I don’t want to commit the same errors that I am bring the author to task.

Easy to Choose

It is easy to compare anything on just a couple of characteristics and pick a winner. Nothing is the best at everything.

“DOS is better than any operating system today because it’s memory overhead is incredibly small.” How many DOS deployments have you seen lately? There are reasons for that.

This is an extreme example, but it illustrates the fallacy of the approach taken by the article.

Give me a fair and balanced review. I don’t care who wins, just give it to me. I’ll be doing one of SP2010 to CenterStage this summer. I think that will be the right comparison point.

There are times when SharePoint is the right answer, and times when Documentum is the answer. The article, as written, will not help you figure out which is which.

Disclaimer

I may be a partner of EMC, but I have more revenue coming from SharePoint projects these days than Documentum. Documentum work isn’t slumping as much as SharePoint work is booming.

Documentum Renewal: Architecting Content Applications

Posted in CMIS, CenterStage, Content Services for SharePoint, DFC, DFS, Documentum, TaskSpace, WDK, Web Publisher, Webtop, xCelerated Composition Platform on January 4th, 2010 by Pie – Comments Off

Of all my posts in this series, this is the one that is probably the least needed. I say this because it looks like EMC is some of this now. It does need to be said though, just so EMC know that we still care, and in case I am guessing wrong. The themes for the Architecting of Content Applications is closely related to the Application Separation topic and in many ways, is the complement to the Focus on the Core edition.

I’m going to stay away from some specific feature requests for applications. I would want to do complete run-downs on any app before I did that. I want to be a little more strategic in my advice.

As always, please feel free to add/comment.

Old Reliable

I remember the WDK when it first started. Heck, I presented on integrating into the WDK at the 2003 Documentum Developer conference. It was immensely better than RightSite, leveraged Java which was becoming a core technology for Documentum. It allowed easier management of interface customizations.

It is now old. Not just in tech years, but in dog years. Webtop is still useful if for no other reason than it can test almost any Documentum feature from within an out-of-the-box interface. For “power users”, it gives you lots of functionality. For everyone else, it is a burden.

The problem is that EMC is now in a Catch-22. If they get rid of Webtop, they have lost a great platform for testing all server features. They would also have to replace Documentum Administrator. I already have heard that TaskSpace will be moving away from the WDK in D7, but what about DA and Webtop? Where will the equivalent apps live?

On the other hand, the WDK is old and tired. Like any old race horse, it is time to put it out to pasture. Maybe keeping it as a Content Server test-bed or as a development platform may be worthwhile.

Just remember EMC, if you do kill it, replace it.

Common Architecture

WDK-based apps have to go, so what now? It used to be that if I could find a Java developer, they could use that skillset do to any Documentum customization.

Java isn’t going anywhere as it is a key part of the Business Object Framework and the basis of the entire DFC, which is the basis of DFS. So do we want to start introducing more technologies for the user interfaces?

Here is where we need to take a lesson from CenterStage. The tech is open and heavily based upon JavaScript, specifically ExtJS. While it isn’t Java, it is related. This is also the base platform for the next version of TaskSpace and xCP with D7.

If not already done, make it the core technology for ALL applications. Forget Flash or Flex. We don’t need to be having multiple developers and we can’t all afford to keep developers that are good at several languages.

CenterStage connects to the Content Server using DFS. Make that the template for your business applications, like TaskSpace and Web Publisher. That will help decouple from the Content Server. That puts you one step from making those same applications work against CMIS, which allows you to sell those applications as standalone apps against CMIS repositories.

Which, if I count correctly, is another potential revenue stream.

It also allows me to use EMC applications fully against a Documentum repository and to find and use content on my “legacy” systems. Migrations now become less of an issue when seeking to switch applications.

Play to Your Strengths

This will be short and sweet. Documentum has always been one of the stronger ECM plays with workflow and BPM. The introduction of ad-hoc approvals workflows in D5 was great. I could quickly route a document for review to someone without creating a workflow and it would appear in their inbox with any other tasks.

So WHERE did it go?

Every single Knowledge Worker interface, CenterStage, Content Services for SharePoint, and the My Documentum suite failed to deliver an inbox.

Huh?

Back in 2000, I worked with Plumtree, which later was acquired by BEA and then Oracle, to develop and test four gadgets/portlets. Do you know what the most obvious/important one was?

…the Inbox.

Many Knowledge Workers may not live in the Inbox, but it doesn’t mean that they don’t need to visit. Keep your eyes on the ball people.

Free the Applications!

Break FREE from the release cycle of the Content Server!

SEPARATE yourself from the numerical advancements of other products!

Make your version numbers MEAN something again!

Become ONE with the market and don’t just react, LEAD the market with your application features!

SAVE yourself from the evils bugs that reside in unrelated applications!

Become your OWN product! Be YOURSELF!

Can I get an AMEN!?!

Documentum Renewal: Focus on the Core

Posted in CMIS, CenterStage, DFC, DFS, Documentum, Documentum Composer, Retention Policy Services, XML Repository, emc on December 21st, 2009 by Pie – Comments Off

I just started writing a series on what EMC should do with their Documentum product as part of my Christmas gift to EMC. That part is key…this is a gift from the community because we want Documentum to be better and to stick around.

Why do I say the community? Simple enough…because I hear these things from many users at different installations across multiple verticals. I hear things from clients, partners, competitors, and random people at meetings.

We criticize because we care.

That being said, my first post in this series, on Application Separation, had a great reply from Lee Smith which is worth looking at. Take a moment.

Today we are looking at the Content Server, the engine that makes everything work.

Upgrade the Content Server

Okay guys, this isn’t rocket science. You don’t have to be a genius to see things need to be updated. Several things haven’t been changed in over a decade, like Federations. This is a leading ECM platform, and rightfully so. If EMC wants to remain there, they have several things to fix…

Optimize DQL: Recently I ran into a performance issue. If I ran a query with one condition, it was quick. If I ran it with another condition, it was quick. If I combined the two conditions into one DQL statement, the world ended. It was because one condition was hitting a single-valued attribute and the other was hitting a repeating-valued attribute. I fixed it by creating a Union query of the two quick responsive queries. Why can’t EMC do that in the code when translating from DQL to SQL? Why not spend some time with table indexes so people can look at the audit logs even when there are hundreds of millions of entries? Right now in many systems, that is a kiss of death. Run some database analysis on what happens when people click on those History tabs. Oh, and consider differences for Oracle and Microsoft.
Security: Going to only address the functional aspect here. The proper management of security will be addressed in its own post. Did you know that the key used by Documentum to assign users to groups and Access Control Lists (ACLs) is the User Name, which is essentially the display name. If that changes, all the related tables have to be updated. Expand to 10,000 users and that becomes a large update. Now factor in the pulling of users from multiple sources where there is no way to guarantee uniqueness. The entire model falls apart. Documentum needs to use the built-in Object Id for users and groups for all of this. There is no excuse for this. As user populations grow, the existing model becomes more and more unworkable.
64 bit: Why isn’t there a 64-bit version of the Content Server? It creates a limit of 1024 connections and a limit of 2GB of memory usage for the Content Server. In the 10 years of working with Documentum, those limits have not moved. Give us a 64-bit version and let us take advantage of the average server that we would like to buy for production.
Federations: This sucks. Documentum exports a file of users from one system and then imports it into another. If this gets out of synch, say because you deal with LDAP issues from having a few thousand users, this falls apart. I’m not sure if it is better to manage two LDAP configurations and the issues that arise from that or use a Federation which will at least give a variety of issues. I can think of several different architectures that would provide better response.

That is just a start, but you get the point. There are areas that could use some love. When most of my performance gains come from upgrading the database or the user interface and not the core server, that should tell you something.

Too Many Add-Ons

Here is a common scenario…EMC hypes a new feature for the Content Server. It is presented as part of the core architecture and looks like a great next-step in the evolution of Documentum. There is only one problem…

It requires an additional license!

Excuse me?

So your telling me that if I want to add content or work differently with content, I have to pay more? How about the additional client licenses that I may add as well? Can’t you get my money there? How about when you sell me all the new storage I will require?

This has happened with High Volume Server and Documentum Foundation Services (though I think DFS is changing). XML Store is also licensed separately.

High Performance Server is a great boost to help with massive amounts of content. Why is it licensed separately? Why not say Hey look! Our Content Server scales better now than it did when we released 4i 10 years ago! Why not bundle it? Why not bundle the XML store? Why do I have to pay for the Documentum Administrator web interface?

The following should be included with the core purchase of Documentum Content Server. That itself should be for X users or X CPUs. I prefer CPUs at higher levels and users at lower. Maybe do a sliding scale. Users up to 250 at which point you switch to CPU. Do the math and figure it out. What matters is that the following is included.

Documentum Foundation Classes (DFC): This has always bugged me that clients have to pay EMC money to write a custom application using the DFC when they are already per-user for the Content Server.
Documentum Foundation Services (DFS): Same thought as the DFC, but even more-so for the world of SOA.
Content Management Interoperability Services (CMIS): If you charge people extra to make your server the repository of choice for line-of-business applications, it hurts you.
Documentum Administrator (Minimum of 5 licenses or 1 per CPU): Why should anyone have to pay extra to administer their system?
Documentum Search Server (the full-text index engine): The current FAST search is included. Please keep this consistent.
Composer: Can’t believe you licensed its predecessor, Application Builder, SEPARATELY. Criminal to say the least.
XML Store: You sell it as a stand-alone, which is good. You need to market it that way more aggressively. Why not make the Content Server the best of the big players at using XML? Sell the advanced interfaces and the consulting services.
High Performance Server: Really? The first real performance and scaling improvement in 10 years and we have to pay extra?
Webtop OR CenterStage Essentials: Give people a basic interface. It doesn’t have to be fancy as you can sell the fancy one separately.
Integrations into Microsoft Office: Make adoption easy and people want to use your software.
Centera Integration: They’ll have to pay you for the hardware anyway. Why add to the hurdle?
Retention Policy Services (RPS): Everyone has retention requirements. Sell them the full Records Management application if they have full records requirements. Many people will still buy that component. This isn’t part of the core now, but basic retention is so common that it should be there.

From here, clients can buy more specific applications or integrations for their business area. This will take some restructuring, but it will pay off when you can say, Oh, that’s included, in bake-off after bake-off.

Oh and did I mention that this will make pricing simpler for partners and sales reps. I’ve seen this messed up on many occasions.

If you have any other ideas, please add them.