Documentum to Alfresco Migration – Maturity of the platforms

This is the second post in our series discussing why clients are migrating or considering migrating to Alfresco from Documentum.

In our first post on Migration from Documentum to Alfresco – Why Now, we had a comment posted that Documentum was more mature than Alfresco implying that Documentum was a better choice for enterprise solutions.  This post will focus on examining the underlying components of Alfresco and Documentum to really consider the maturity of each solutions and whether it should be a deciding factor for client’s decisions.

Mature and the sales process 

During a software sales process, sales reps will often refer to their product as “mature” hinting that their competitor, while newer, is somehow “immature”.  This is a common tactic in the software sales process for discounting new competitors.  Implied points for mature software could include:

  • Performance
  • No bugs
  • Scalability
  • Stability
  • Number of Implementations
  • Company Long Term Viability

While it makes sense that new software can have issues associated with a smaller deployment base, when does time and wider deployment make a software product mature?  Based on our client experience, we would propose that Alfresco is a mature company.

  • Better Performance than Documentum (will be addressed in a later post).
  • No Stability Issues
  • Scales for our enterprise customers (will be addressed in a later post)
  • Numerous large implementations and large clients
  • Company has been around for 6 years – very profitable and viable

One significant strength of Alfresco is the Open Source approach with Alfresco Community.  The community addition allows a free download and install.  Community Users can track down bugs and even review the code to send code updates to Alfresco themselves.  While Documentum has an early adopter program, it does not stress test the products to the level of quality of Alfresco’s open source community.

Maturity and Pricing Model

Older companies, as they have grown, tend to look for additional revenue to continue growing.  Companies, like Documentum, that have reached a wide market will look to their existing customers for additional revenue.  In regards to new versus older companies and pricing:

  • New companies are looking for traction and market share so they don’t have large overhead and can price aggressively.
  • Older companies can add more products (suites) and, as competitors are removed from the market, have the flexibility to increase prices.
  • Once software reaches a certain penetration at a company, it can be expensive to remove and again allows the flexibility to increase prices and maintenance costs due to “lock in” at the client.

We have pricing sheets from 1990’s where Documentum was priced significantly lower than today.   As pointed out in previous articles, Documentum needs to continue to grow revenue to keep up with the rapid growth of EMC overall.  One example of additional revenue growth due to customer lock-in would be the increase in maintenance pricing, as pointed out in this post.

Alfresco, being a newer company, has the flexibility to price lower and still show growth.   We will post on the pricing model differences in a later post.  For customers considering a migration, Alfresco’s subscription model (no purchase price) and CPU license approach will typically cost-justify itself over Documentum’s named user purchase, suite, and maintenance pricing.

Maturity and Back-end Technology

Clients understand that not all of the age associated components of software development are good things.  There is a subtle line between a product being mature versus just plain old.

Documentum, initially developed in the 1990’s is very different than Alfresco developed in the 2000’s.  Technology differences include:

  • Client Server versus Web – When Documentum was first developed, there were no browser based systems.  Components of Documentum infrastructure were developed for client server deployment (remember Workspace).  As such, the components of the Documentum infrastructure had to have client and server components as well as RPC mechanisms to communicate between the platforms embedded in the DMAPI.   Alfresco was developed for web based deployment without the client server components.
  • C versus Java – In the 1990’s, pre-Java, all of the underlying components of the DMAPI and later the DFC were developed in C.  For those of us developing Web based applications on the DMAPI or DFC pre Documentum 6.5, we struggled with memory leaks and threading issues with the DFC based on the C infrastructure.  We have never experienced those issues with Alfresco as it was written in Java from the beginning.

With Documentum 6.5, the DFC is now all Java but is not a web services layer.    Documentum Foundation Services (DFS) was a new Java only offering to address web services introduced in 2007.  Like any immature software, DFS had significant early issues as addressed in this post.   One difficult part in regards of adoption of DFS was that the DFC as an alternative was mature and stable.  While we applaud Documentum for removing the last of the old architecture, the early adopters of the DFS had to struggle with an immature software.  Unlike the DFC, the DFS was not embedded in core software interfaces (Webtop is on DFC) having hundreds of users testing it, but rather relied on users implementing custom development efforts.  Newer interfaces (D2 and XCP) are being built on the DFS.

Alfresco has offered CMIS interfaces from the beginning and all of their interfaces support their service oriented offering.   The core API of Alfresco has always been exposed using REST, SOAP and CMIS SOA.  Alfresco’s out of the box interfaces, including Explorer and Share, use the SOA to communicate with the repository.  Custom interfaces can be built using the same SOA, which is easily extended.

Maturity and Interfaces

In regards to interfaces, clients should consider the relatively risk of new releases and new products.  Documentum has recently released D2 4.0 .  While we applaud Documentum’s effort to offer new interfaces, we cautioned clients to review the tool as any other new product as mentioned in this post.

TSG has been providing open source interfaces for both Documentum and Alfresco for over 7 years.   Over the years, the code has been incrementally improved as it has matured.  Since it is provided as open source, both our Documentum and Alfresco customers have access to the code to suggest improvements similar to Alfresco’s community.

Summary

Those evaluating a migration from Documentum to Alfresco should consider both companies to be mature and evaluate the companies on differences in pricing, performance and other long-term criteria rather than be swayed by the FUD (fear, uncertainty, and doubt) used by older companies to label newer companies immature during the sales process.  Rather than tagging Documentum as more mature than Alfresco, smart clients will look to understand the underlying components when comparing the two products to make their own informed decision.

3 thoughts on “Documentum to Alfresco Migration – Maturity of the platforms

  1. Hi Dave,
    How can you justify the phrase “While Documentum has an early adopter program, it does not stress test the products to the level of quality of Alfresco’s open source community.”. I disagree with this, open source community doesn’t have the resources to perform wide-open and big scale stress tests. These are normally being made by big corporations not open source community. I recall an article published by Documentum where they tested the product on Microsoft’s Labs. With billions of objects and transactions.

    Are you sure about this?

  2. Jorge,

    Thanks for the note. In regards to the quote about stress testing the products, Alfresco has thousands of users using the community addition for production systems. The use of code in production is the point about the stress testing of the applications for bugs. Often times the early adopter programs require users to divert testers to the program as Documentum doesn’t allow you to use the alpha/beta code in production. Also, I haven’t seen big clients in the early adopter program do the stress tests you mention. More just kick the tire of the new interfaces.

    I think the comment is really to explain that users in production put more detailed stress and testing on software than users that are testing. We see better quality software released and quicker releases with Alfresco than Documentum.

    Dave

Comments are closed.