Many of the more popular posts over the years have been surrounding Migrating from Documentum to Alfresco and other comparison posts. While some of the differences are obvious (Big Public Company/Division of EMC versus Private Company, 20+ Years old versus 10 Years Old…..), for this post, we thought we would summarize some of the not so obvious differences for clients considering migrating from Documentum to Alfresco from both a technology and culture perspective.
Difference 1 – Technology Stack
Very simply, Documentum was created in the 1990s based on work John Newton and others did back at Xerox. Alfresco was created in 2005 by John Newton and others with newer technologies based on lessons learned from Documentum. It is worth a reminder that the browser and whole Java infrastructure was created in 1995 or so. Those of us that worked with Documentum back in the 1990’s were implementing client/server systems and Documentum’s API was mostly C with remote procedure calls (RPC) and a funky third party component that initiated the RPC from the PC to the server. While most of modern day Documentum is Java based, it is important to understand that some of the underlying components of Documentum still rely on that John Newton vintage API from the 1990’s. See what happened when Documentum tried to build a new Java only based DFS.
When compared to Documentum’s technology stack, Alfresco’s newer environment is easier to maintain, scales and manages memory better, and can be maintained/enhanced by their current engineers. Unlike Documentum Content Server, an Alfresco repository runs within a Java web container (Tomcat, JBoss, etc.), making it compatible with most any operating system. Alfresco has embraced standards (ex: CMIS) and open source (Lucene/Solr) significantly quicker due to their engineers and technology stack. Alfresco’s open source and community offering allows for enhancements to flow from the community of developers rather than just their internal team.
See additional details in Documentum to Alfresco Migration – Maturity of the platforms.
Difference 2 – Development Environments
Documentum focuses on proprietary development environment (D2, xCP, WDK) rather than open standards like CMIS and non-proprietary environments providing their interface, Share, as open source. We were involved way back when with the late and great Dave Ross in 1999 when the WDK was being developed. Rather than an API with examples, even back then the powers that be at Documentum wanted more of a lock-in in regards to development environment. Experienced developers have struggled with WDK, RightSite, CenterStage, xCP, D2…..and struggled with learning the new environments. Clients have struggled with finding developers familiar with the different environments and Documentum itself.
Alfresco’s open source roots allow for better support of open rather than proprietary development and include a community edition to allow non-customers or non-partners to develop solutions on Alfresco. Alfresco is also better positioned as a content management platform that can be easily integrated with other systems and interfaces via a robust API and other protocols (CMIS, WebDAV, SharePoint protocol, etc.) Alfresco offers the Share interface as an out-of-the-box solution, but the core repository was built with integration in mind, making Alfresco a smarter choice for customers looking to wrap ECM functionality into a larger overall system.
See related post on development differences and Documentum Developer Edition released in 2009, only to be discontinued in 2012. Documentum Discontinues Developer Edition – Alfresco versus Documentum Development.
Difference 3 – Consistency of Technical Resources – San Francisco versus London
Inc. just had an article about best places for a start-up. As usual, technology start-ups and San Francisco go hand-in-hand as the number of programmers and the amount of start-up capital and culture are the best in the United States. That said, as a technology company matures, the company’s ability to hold on to technical resources can be impaired as good programmers will always have an option to jump to the next hot start-up. Documentum (San Francisco) has evolved to the third (or forth) generation of engineers and product managers as their founders and second generation have long ago left for other companies, while Alfresco (London) has been consistent with its engineering team.
TSG used to have an ex-Documentum product manager working with us who gave us an inside look into product development at Documentum. Turnover of the development staff, executive staff and a buy versus build mentality have resulted in inconsistent product development and frustration for users, particularly surrounding upgrades. Some obvious examples:
- Webtop 5.2.5 not compatible with Webtop 5.3
- Webtop 5.3 not compatible with Webtop 6.X
- CenterStage will replace eRoom and eventually Webtop – EMC 2011
- Unified Web Client (UWC) will replace CenterStage and Webtop in 2012 – EMC World 2011
- Documentum Licensing D2 – EMC 2012 – UWC discontinued – Webtop continued support – EMC World 2012
- DCM – FirstDocs – D2…..See Documentum Webtop Migration – xCP, D2 and other thoughts
- xCP 2.0 not compatible with xCP 1.0 – EMC World 2014
Alfresco has had a lot of consistency in regards to key developers on Newton’s team and product direction.
Difference 4 – Sales Culture versus Engineering Culture
We touched on this back in our Documentum to Alfresco Migration – Why Now article, but we have always felt that Documentum’s culture under EMC had moved to more of a sales culture versus a software engineering focus like Alfresco. Often times it seems like Documentum product development is less about improving the product and more about “what more can I sell to my clients”. Some examples:
- D2 License – As we said in our initial D2 review back in 2012, we felt strongly that purchasing D2 was a way to add a new item to the price list, since many clients had already purchased Webtop. D2 is mostly a Webtop replacement but users don’t get credit for any license (and still pay maintenance).
- Software Audits – While the practice has lessened, lots of bad blood still exists from Aggressive Software Audits performed by EMC that seemed very sales driven.
- Consulting – More and more “products” are only available with Documentum consulting and additional sales. See our thoughts on Documentum Consulting – Understanding the Basics.
See more regarding our thoughts on culture in – Documentum to Alfresco Migration – Comparing Company Visions
Difference 5 – Partner Network
As many of the Alfresco partners are either current or ex-Documentum partners, it is pretty simple to understand the differences between the Alfresco partner community and the Documentum partner community. As mentioned in Sales Culture above, often times Documentum sales reps, in looking for “what more can I sell the client”, land on additional consulting resources. Documentum has built a much bigger professional services practice, where Alfresco continues to be focused on software.
Rather than purchasing consulting firms as EMC Documentum did with Sitrof in 2013 and Trinity in 2012, Alfresco has leveraged their partners for innovative and industry vertical solutions. In the Documentum space, partners are often competing with Documentum consulting itself.
- Proprietary Software and Solutions that only Documentum Consulting can implement and maintain – see examples of DEMA, DFS and others from EMC World 2012.
- Subcontracting Relationship Programs – where partners are strong-armed into subcontracting to Documentum. See Documentum Consulting – Understanding the Basics.
- Growing List of Ex-Documentum Partners – probably too many to mention but see our post from EMC World 2011.
- Quota Credit for Sales Reps to Sell Services – see related post on Financial Results from 2013 where services made up all of Documentum’s growth and over two thirds of revenue.
There are major differences between Alfresco and Documentum, not only in the capabilities and culture of the companies, but also how both companies will continue to evolve in the future. As we mentioned in a previous post, the toughest part of any product of vendor evaluation is focus on “what the product does now” versus “where will the product be going in the future”. Too often we see clients struggle with a checklist approach of “this feature versus that feature” to try to turn the vendor evaluation into a math exercise. As many clients have found out over time, a checkbox evaluation can miss critical success components over the long term. Futures can be difficult to evaluate as, during a sales discussion the answer of “we are planning to do….” doesn’t always set a clear roadmap. Some points to consider:
- Client Relationships – What is the vendor relationship like? Is the ECM vendor a true partner where they are working to shape the product(s) to better meet our needs after we have purchased, or do they tend to always be just selling us more? Software vendors tend to struggle as they always can be looking for growth areas (what more can I sell?) rather than focusing on their current clients.
- Innovation – How quickly does the vendor adopt new standards and technologies? As an example of Documentum versus Alfresco, Alfresco’s leadership with CMIS and Lucene/Solr integration was years ahead of Documentum.
- Product Development Consistency – One issue of particular concern for Documentum clients has been consistency in regards to client software. Clients purchase and pay maintenance for licenses of products that don’t evolve. For our Pharma clients, products that haven’t been maintained or improved over time have included DCM, Webtop and FirstDocs as Documentum moves to D2 and xCP. Clients should look for a history of consistency in licensing and product development.
- Partner Relationships – What is the relationship between the vendor and its partners? Does the firm compete against its partners for consulting services?
All of the above are great evaluation points when considering both ECM vendors and are key differences between Documentum and Alfresco. Let me know your thoughts on other points to consider below.