Not so DAMned DAM support

Published on October 14, 2014 by Jan Haderka

Those of you who have used Magnolia for a while know that it has come with its own Document Management System (DMS) module for years.

The purpose of the module was to allow you to manage documents within your CMS. While the module was used extensively by everyone as a common storage of digital assets (images, videos, and other media), it never quite picked up as a traditional DMS. The module itself also had a few architectural compromises in order to let it function as a DMS, and as such was not very extensible. So with Magnolia 5, we finally bit the bullet and outphased the DMS in favour of a new D-module - the Digital Asset Management (DAM) module. And with new module, we also applied lessons we learned with the old one.


Following the Open Suite approach for DAM, too

Rather than providing one all encompassing store for your digital assets, with some edit functionality on top, we looked around and noticed that there is a plethora of DAM implementations that we could never compete with. So in typical Magnolia fashion, rather than fighting them, we decided to join forces with them: we made sure that the interfaces and APIs of our DAM implementation allow the exchange of underlying DAM implementations for far more sophisticated ones than we could implement - while still providing a reasonably good default implementation to those who can’t or won’t integrate and use multiple systems.


The perfect DAM integration opportunity

Magnolia’s DAM comes with a configurable AssetProvider that gives you the chance to use external assets with Magnolia as easily as internal ones. All of that happened 18 months ago, when we released the then-new Magnolia 5. Until today, I’ve been waiting to be able to exercise the proof of functionality of those interfaces to connect an external DAM platform to Magnolia and show the power of DAM integration to our editors. Now, the perfect opportunity has finally arrived - with Canto’s Cumulus platform, we share the same technology stack, the same customer base and many other common points of interest. Among them is the passion for integrating CMS and DAM solutions into one system for the benefit of users of both.

With the new Cumulus DAM integration, editors are able to select and use assets in Cumulus like native assets in Magnolia. When choosing an asset, they can pick between assets from Magnolia’s internal storage or those coming out of Cumulus. Other than that, everything remains the same. 


Seamless connection, no user worries

Editors don’t have to care about the implications of using an external asset - Magnolia does that for them. It will notify Cumulus that an asset is being used, as well as where and when page was published or unpublished. Magnolia will also make sure that all the variations and links to such external assets are generated as appropriate. Template developers as well as editors don’t need to care or know about the difference. The whole integration is designed to be seamless, fluent and fully transparent. Everyone is free to focus on their work and just reap the benefits of the integration. 


Speeding up the workflow

Another benefit results in more efficiency and collaboration - editors might still need to ping their buddy in the design department to provide a new graphic for the campaign page, but due to the integration, the colleague can just save their work in Photoshop or InDesign, in the storage connected to Cumulus: the asset will then instantly appear in Magnolia’s Asset app. 

In another use case, imagine all protected assets you need to use in your page. Did you have to keep in mind when your usage rights will expire or in what regions assets can be used? With this integration, you select an asset to be used in a page and rely on the integration and the underlying systems to downgrade gracefully when your usage rights expire or when a user from a certain region who is not covered by your license accesses your content. Can it be any simpler than that?


Future-proof decisions

With this integration, we have been able to proof that our design choices were good choices. At the same time, we discovered even more ways to make such work easier, and ways to bring different systems closer together - all the while delivering more value to customers of both systems. So stay tuned, as this is not last post on the topic. In a couple weeks, I’ll publish another piece for our technical audience, explaining all the challenges faced during this integration, as well as techniques used to solve them.


{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Jan Haderka

Jan is Magnolia's Chief Technology Officer. He has been developing software since 1995. On this blog, he'll write about Magnolia's connectors, integrations and coding ...with the odd Magnolia usability and development tip thrown in for good measure. He lives in the Czech Republic with his wife and three children. Follow him on Twitter @rah003.

See all posts on Jan Haderka