Archive

Archive for the ‘ROI’ Category

Distributed Setup in Documentum: The Verdict

January 15th, 2009
Comments
In my last few posts, we discussed installation and configuration of a distributed docbase. It might have seemed a bit complicated to the untrained eye, but it is a really simple process - you setup your primary site first, identify and define network locations, create filestores and then finally associate these store with network locations. The primary reason we setup a docbase with distributed filestores is to improve performance when accessing documents from remote locations and branch offices. To ensure that this setup actually works, I finally set out to test my configuration. And the results were indeed quite astounding.
Before I discuss the result, I would like to point out a few things. The installation was done one two sites - the primary site being where I work (with full content server) and a branch office located some 500 KMs down south, connected by a 1 Mbps link. The test machines on both the sites were exactly similar. The test process was fairly simple - I did two set of measurements for each central and distributed model. One from local head office to access local documents and one from remote site. The measurement was a simple one - for storing documents, I measured how long it takes to get back to main webtop screen AFTER I press OK on document properties popup dialog that comes after dropping a file in webtop. For retrieving documents, it was simple. Double click on a file and measure how long does it take to open. I repeated the tests atleast 5 times to average out values and get a better estimate.
Local (Normal) denotes time for accessing a local document under a normal central setup while Remote (Normal) denotes time for accessing a document from regional office under the same central setup. Local (Distributed) setup denotes the timing for accessing a document locally (head office where content server is installed) and Remote (Distributed) denotes time for accessing a document from the regional office where only a file store is installed. And here are the results

Results for storing a document:

File Size Local (Normal) Remote (Normal) Local (Distributed) Remote (Distributed)
50 1.6 Sec 2.5 Sec. 1.5 1.5
50-100 Kb 1.3 Sec 2.5 Sec. 1.3 1.3
100-300 Kb 1.7 Sec 3.7 Sec. 1.7 1.7
300-500 Kb 1.9 Sec 6 Sec. 1.9 1.9
.5 - 1 MB 2.2 Sec 12 Sec. 2.2 2.1
1-2 MB 2.3 Sec 20 Sec. 2.3 2.3
2-4 MB 2.9 Sec +30 Sec. 2.9 2.9
>4 MB 2.9 Sec +50 Sec. 2.9 2.9


Results for retrieving a document:

File Size Local (Normal) Remote (Normal) Local (Distributed) Remote (Distributed)
50 1.7 Sec 4.5 Sec. 1.7 1.9
50-100 Kb 1.6 Sec 4.5 Sec. 1.6 1.9
100-300 Kb 1.6 Sec 5.5 Sec. 1.6 2
300-500 Kb 2 Sec 6.8 Sec. 2 1.9
.5 - 1 MB 1.5 Sec 11 Sec. 1.5 2.4
1-2 MB 1.6 Sec 27 Sec. 1.6 2.1
2-4 MB 2 Sec +35 Sec. 2 2.4
>4 MB 3 Sec +55 Sec. 2 4.7
Verdict? I guess you are smart enough to figure out. However, there are a few things that you must keep in mind before adopting an enterprise wide distributed model. First, you can NOT revert a distributed store back to a central model, without sacrificing your Christmas vacations - Official documentation says it is impossible. And second, this model is suitable only where you have different regions accessing not only same documents, but also same applications and it makes sense to actually have a single repository. For example, if I want to setup up a distributed storage for all our offices in South Africa, I’d rather setup a distributed file store at each regional office than a new docbase at each regional office (Federation). I would consider a federation only if I consider overseas offices - cause logically they represent different units altogether (region/locale/document types/compliance issues etc).

[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

cucumberboy Distributed Setup, Documentum, ROI, Remote Content File Server, performance improvement, results, single repository distributed storage , , , , , , , , ,

Documentum Licensing Blues!

November 13th, 2008
Comments

I have been working with Documentum for about a year now and every few months I discover something much more annoying and frustrating than ever before. And its only now that I’m realizing why Documentum experts are so much in demand and hard to find.
As part of my current assignment for a bank, we were evaluating writing a custom web front end for Documentum. We believed we had many reason to do so - a simpler API for customizations and addons, access to complete source and ability fix bugs ourselves, a richer UI and more control over everything. We even started researching possible implementation alternatives and flex did seem like a good choice. Above all, we thought we might just be able to get around Documentum’s per seat licensing model and could use only a single license for all enterprise users.
The whole idea was to use documentum like a database - the way your web application uses a single user to cater multiple user accounts. You dont really create a database user for each new user of your web application. That simply doesnt make sense. We thought of doing something similar with Documentum - a single user proxies for all application users and with some hacks, the entire system still works the way it was meant to.
And mind you, the official license agreement with EMC does not mention anything about such an approach. All it says is that if you create an account in docbase - be it for application users direclty or for other automated systems or webservices, you gotta pay for it. And it aint cheap either. Infact, it is one of the most expensive products out there. No wonder they are loosing ground fast. My last client decided to move away from Documentum and scrapped 2 of their projects almost after 2 years of investments. My current client is also reconsidering their decision to stick with Documentum.
The reasons are obvious. When many open source, free and cheap alternatives, why would any one want to keep a white elephant. And yes, then there is the support which would become and indespensible part of your life when you buy Documentum. My personal experience hasnt been too good. There are things and features that you can not simply do with a support account. EMC forums are much more useful than the bundled documentation and trust me, you cannot live with Documentum without support. The support aint very good either.
After considering all our options, we decided to speak to EMC about licensing and we were not very happy with the response. The guys said it would be a breach of license agreement if we used a proxy user to connect to Documentum and even if we write a complete new web front end, we’d still have to pay “WEB TOP’s” per seat licensing fee. Would you believe that?
That is the most ridiculous licensing policy I’ve ever come across my life. I mean, why the hell would you want me to pay for a webtop license, when we are not using webtop at all? That makes the whole idea of a custom client worthless. First you pay a licensing fee for a product that you dont use, and then you spend more on developing your own stuff.
I’m no legal expert but this definitely sounds like a perfect candidate for an Antitrust lawsuit.
A. you make a buggy product so that users cant do without support.
B. You sell it at a premium price
C. If the business doesnt wanna use the product, they still pay the licensing cost no matter what they use.

Doesnt that sound more like a “Monopolistic” licensing than competitive licensing? Once a business buy Documentum, they’re locked in.
EMC may have enjoyed exclusive status over last few years, but I think the space is heating up rapidly with new vendors like Microsoft catching up. Interestingly, Microsoft adopted a totally new approach with its Sharepoint server. Instead of cashing in on large cows, they commoditized the whole thing with their extremely low cost and awefully simple licensing terms. No wonder business adopted Sharepoint without much hestitation.
I think its high time that EMC rethinks its licencing model if it still wants to maintain its niche position in the market and stay ahead of competition.

[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

cucumberboy Documentum, EMC, Licensing, ROI, Sharepoint, Support , , , , , , , , ,