With the recent announcement that the Documentum Developer Edition is being discontinued – Bidding Farewell to Developer Edition, we thought it would be a good time to update our previous post from 2010 in regards to development differences between Documentum and Alfresco. This post will compare and contrast development environments and philosophy with both Alfresco and Documentum.
Documentum Development Roots
When originally founded in the 1990’s by John Newton (current Alfresco CEO) and Howard Shao, Documentum was really just an object orientated layer on top of a database. When we would discuss it with clients, the “database for documents” was a common description of how a layer for security and object model abstraction would lay on top of the database (usually Oracle back then although Sybase was supported as well). Documentum had an API layer (C Code), DMAPI that was the only way to access the repository along with the still popular query language, the Documentum Query Language (DQL) to access and manipulate the repository. Originally the DMAPI had both a client and server component with an embedded remote procedure call (RPC) since Documentum was developed pre-web.
Original developers were encouraged to use the API or, as of Documentum 4i, the DFC to enhance or extend Documentum (Workspace, RightSite, Webtop/WDK, xCP and others). Pricing options originally not only included CPU-based but also concurrent users (something that quickly faded) so development wasn’t limited to single interfaces. Documentum has evolved to a web services API access with DFS although it did take some time as pointed out in one of our old posts. The developer edition was announced in 2009:
From the press release:
“This expanded investment in developer resources demonstrates our continued commitment in making Documentum the premier platform on which developers can build their content-enabled applications rapidly while keeping their costs of implementation and support low,” said Whitney Tidmarsh, Chief Marketing Officer, Content Management and Archiving Division at EMC. “Through our various online communities, developers can take full advantage of free tools and content as well as work together and foster the growth of the Documentum community.”
Contrasting that with the farewell post:
“With the latest releases of xCP and D2, we now have best of breed products for building ECM solutions with a minimum of code. We continue to support the classical development tools and APIs (and will for some time), but most new applications are being built with these new techniques that are faster to deploy and much cheaper to maintain. Developers are now much more interested in learning these products than the tools available in the Developer Edition……Finally, we’ve shifted our strategy to be more focused on delivering solutions, rather than just a platform for building them. In the past couple of years we’ve greatly expanded the number of solutions available from ourselves and our partners.”
As Documentum has evolved, a number of changes have occurred that have affected the Documentum development philosophy including:
- Pricing – We would argue that the biggest impact to pricing has been the pricing construct of named user and per application pricing. While it has evolved in the last two years to include one server side price and a small per application price per named user, the pricing of a custom application costing more than $400 per named user discouraged custom development or access from other environments.
- Anti-Customization Movement – As Documentum gained more success, some of the competitors would attack it as “too expensive” because it “required customization”. As pointed out in a previous post, not all customizations are bad. Most of the issues regarding customization came not because the customizations were bad but that Documentum didn’t support them during an upgrade, particularly on Webtop, and would require a rewrite to the new proprietary interface for the upgrade. OpenText, in competing against Documentum, even had a campaign as the “consultantless solution”. This philosophy can be seen with the recent D2 and Mobile environments and the quote above where “you can’t customize it”, almost to prevent users from doing what Documentum perceives they shouldn’t be doing.
- Professional Services from EMC – A couple of clients have pointed out that D2 and other environments can be customized but “only by EMC”. We see this as a dangerous trend in that development environments exist (SharePoint Development Framework for example) but are only available to internal professional services from EMC.
As demonstrated by the discontinuing of the developer edition, the overall trend from Documentum is moving away from development options for clients in favor of configurable but proprietary only environments.
Alfresco Development Roots
Alfresco, a company founded after the internet bubble, was built as a web/Java open source evolution of a content management system. While many of the same principles exist (API access to back-end layer on top of a database), Alfresco choose to implement with a web-based API focus from the beginning, focusing on open standards geared for developers. Alfresco promotes open development in a number of ways:
- The Community Edition of Alfresco is available free of charge.
- Alfresco is setup to be easily customizable. There are many integration points for adding customizations, and you can even wire in code with Spring to access lower level APIs.
- Alfresco has a well-documented API that is geared for developers wishing to customize and add on to Alfresco.
- As you would expect with open source software, you can access all of the source code for Alfresco. This is very helpful since developers can load the code into an IDE and see exactly what Alfresco code is doing, and can even step through it in a debugger.
- Alfresco actively promotes CMIS as a standard for accessing the repository.
- Alfresco’s main interface, Share, is written using the Spring Surf framework. Alfresco developed Surf and then donated it to the SpringSource community.
To contrast Alfresco with the issues discussed above with Documentum:
- Pricing – Alfresco only has a CPU level maintenance/support that is lower than Documentum’s maintenance pricing (see related post – add link). For Developers, CPU pricing gives them the flexibility to develop small, focused applications for any type of user without worrying about licensing impacts.
- Customization – Alfresco has never had the perception of being “over customized” due to their client base. Also, the focus on the developer has made the bulk of the customizations easily upgradable.
- Professional Services – Consistent with a partner focus versus a consulting solution, Alfresco doesn’t offer professional services and releases all updates to the entire installation base rather than positioning additional technology as a solution or consulting only solution.
Summary – Sales Culture versus Engineering Culture
With all of the posts around Alfresco and Documentum, the development philosophy clearly illustrates the cultural differences and contrasts between the two companies.
As pointed out in an earlier post, EMC has a sales driven culture. By understanding how sales goals drive decisions, you can see how the movement to add internal solutions and products while moving away from open development tools benefits Documentum sales. Readers should also understand that Documentum has been unfairly characterized as “requiring customizations” and has reacted by releasing products that can’t be customized.
Alfresco has an engineering driven culture. With the community edition, pricing and a variety of development approaches, Alfresco embraces the power and innovation of the open source movement and standards to create solutions and other approaches. Every piece of Alfresco is available to developers to create innovative and cost-effective solutions.
For further insight in the cultures, as pointed out in our earlier post, Documentum’s user conference is called Momentum and features suits/ties and non-technical presentations about solutions. Alfresco’s user conference is called DevCon and is focused on engineers and developers.
If you have any thoughts, please add below.
Ed Steenhoek says
At some points, the information about Documentum is incomplete.
If you read carefully, the farewell announcement hints at the cloud being a better platform to deliver ‘developer’ needs. This was hinted at during Momentum Vienna as well. It shouldn’t be a surprise if a cloud-based alternative becomes available for clients and partners.
Working for a C3P partner, I can confirm that it is possible to deliver SDF through certified partners in stead of EMC Professional Services. The exclusivity to EMC Professional Services is not the case. What you should however understand is that as of today, SDF is not (yet) a product but a Professional Services offering.
Furthermore you tie the choice between development and customisation to a culture between companies which I believe is not the case.
It’s not between just these companies. It’s not an ECM only debate. It is a generic application debate heavily influenced by both cloud and economic drivers.
On the economics side: Does the customisation justify the price? Isn’t 80% of the functionality at 20% of the cost (Pareto’s Principle) enough? Questions to be answered for all enterprise applications.
On the cloud side: with a release cycle of 60 days that is beyond your control you must understand the impact of change to both configuration and customisations added to the solution. The nature of configuration wins it hands down from customisations. You do see this with EMC On Demand but also with Office 365 / SharePoint On-line.
If you want to put Alfresco and EMC apart, then the conscious decision to let cloud be the norm and on-premise the exception (like Microsoft does with SharePoint) is the divider you should be looking for. Cloud is driving economics and comes with restrictions.
TSG Dave says
Thanks for your reply. Some of my thoughts on your points are presented below.
In regards to the cloud, I didn’t include that in my post as I thought it was just fluff. I kept the link so readers can make their own interpretation. Referencing back to the initial press release, Whitney’s comment was that the developer release was to allow developers build their own applications. I read that as developers could use the development edition to access and build on the API. I have a hard time seeing the cloud version allowing developers to leverage the API.
In regards to SDF, I was sharing insights from EMC World in May 2012 where SDF was only accessible via professional services. Link is here. From EMC World, the point was that, while 80 clients have deployed SDF, it is still not a product and requires an EMC professional services arrangement. My point was that Documentum releases My Documentum for SharePoint, says it is non-customizable unless you leverage professional services and the SDF, the concern for clients is lock-in.
In regards to customization, I tried to present the point that, while configuration is mostly good, not all customization is bad. I do think Documentum has been unfairly attacked by competitors as requiring customization when that is not the case. We have plenty of “out of the box” clients. In doing big and innovative things with Documentum, some customization for business reasons is better than trying to change the business. The customization our clients have struggled with has been following Documentum’s guidelines and building customizations to tools like Webtop. When these changes aren’t supported in the newer releases and need to be redone, clients are not happy. For Documentum users, the customizations don’t get the blame, Documentum does for not consistently supporting the customizations between releases.
Last point would be in regards to the cloud. I still see it as awhile before it is the “norm” in ECM so I struggle with your point in regards to customization, particularly when it comes to managing records, something clients still like behind the firewall. We do SalesForce work so I understand the cloud and how clients are implementing for CRM. The interface SalesForce presents (and the tools to customize it, particularly Force.com) are very different than D2 or XCP or anything Documentum is currently offering.
Thanks again for your post – happy to continue the discussion if you have any thoughts on my replies.
I thought that all Non-Production environments for Documentum did not incur any additional cost – provided you have proudction licenses.
Does that remain unchanged?
Is your post pertaining to a different development use-case – where by any independant development organisation could access Documentum’s Developer Edition at no cost to develop custom client applications and solutions?
TSG Dave says
You would have to check licensing but I have heard from multiple clients that server components (example Trusted Content Services) require BOTH Production and Development Licenses.
In regards to development use-cases, independant development organization would need to buy their own version of Documentum.