Does Your CMS vendor Need to Have a Digital Asset Management Solution?
05 Jun 2020
7 min read
This is a question that I’ve been pondering for a while now, to a point where I felt it would be good to write about it. Working for SDL—who doesn’t have a native Digital Asset Management (DAM) solution in its portfolio—you may consider me prejudiced. But I’ll make a conscientious effort to provide a balanced view.
There are clear advantages in using a Digital Asset Management from your Content Management System (CMS) vendor. We’re talking about content here, so there needs to be a close link. With consumers expecting richer and more engaging experiences, rich media (and in particular video) plays an increasingly important role in the digital experience (DX).
Questions to ask yourself—product capabilities
The key question is, of course, whether the CMS vendor has done a good job of integrating DAM capabilities into the CMS. Where some CMS vendors have actually built their DAM from scratch, most CMS vendors have acquired DAM technology from a third party (shareholders appreciate the extra revenue), and then seamlessly added it to their portfolio with varying degrees of success.
- Is searching and browsing digital assets properly embedded in the CMS; can you benefit from single sign-on; and does the CMS treat rich media content as if it was natively stored in the CMS? If all the answers are yes, then this approach provides the benefits of quick and easy access to both traditional text-based content as well as rich media, and it helps you craft engaging digital experiences faster and more effectively.
- Where is the rich media content actually stored, and how does it get delivered to the recipient? You need to ensure that the combined CMS + DAM manages only a single version of your assets. As soon as copying of items is involved, alarm bells should go off since this duplicates storage and typically slows down content delivery substantially. The DAM solution needs to support cloud-based content delivery and the use of a Content Delivery Network (CDN) to ensure fast delivery of digital experiences across the globe. The CMS needs to manage just the reference to the actual content on the pages where it’s used, but never duplicate the asset. If the combined CMS and DAM ticks all these boxes, then users of the system as well as your DX audiences can enjoy the results of this joined up solution.
- Do you just need DAM features within your CMS, or are you looking for a broader set of capabilities that include content ideation, planning, project and resource management and more—as delivered by common Marketing Resource Management (MRM) tools? If so, you can look for a dedicated MRM/DAM vendor, or run with a separate project management tool like Workfront, Wrike or others. If not, then just using a DAM might be the right thing for you.
Beyond the product—differing replacement cycles
We see many organizations struggle even more with their digital assets than with their websites. As a result, quite often a DAM selection is not tied to a CMS replacement. DAM replacement is often urgently needed to improve brand governance and reduce the risk of the wrong assets being used, possibly leading to legal liabilities.
Given these priorities, you can ask yourself what the likelihood is that you’ll end up with a DAM supplied by a CMS provider. It makes more sense to choose a specialized DAM vendor that fits best with your business requirements, regardless of whether that vendor sells a CMS too.
That also minimizes vendor lock-in. By the time your 5-7 year replacement cycle for your CMS lapses, a similar situation can happen where you’re looking for the best CMS to suit your needs, but you have no need to replace your DAM. The rare exception would be when your CMS and DAM replacement cycles coincide, or certain business requirements force you to replace both simultaneously.
Given the usually unconnected replacement cycles, especially in larger enterprises, choosing your CMS and DAM wisely based on their ability to integrate with adjacent technologies can be a more sensible strategy than forcing the two together.
So what do you need to look for when following this approach?
- How much time and effort does it take to establish an integration between the DAM and the CMS? Are there prebuilt connectors available that deliver the required features? To provide some context on how this can differ per vendor, let me elaborate a bit on a real-world example of a connector that was built between Bynder DAM and SDL Tridion. This connector was built in less than 2 weeks. Bynder had attempted to build a similar connector to a competitive CMS product, which—despite all their experience—still took them 3 months. The end result was sub-par to the one built in 2 weeks with SDL Tridion. So a tick in the box on a RFP about a connector doesn’t mean you get what you need.
- How feature rich is the integration, and is it a one-way or two-way integration? This is relevant if for instance you want the DAM to be aware of where an asset is being used. The CMS needs to be able to update such information in the DAM. And the other way round, if the DAM assets are updated is the CMS triggered? Testing some of these things in a proof of concept makes a lot of sense.
- Is there really a difference between going with a CMS vendor that supplies a DAM they have acquired, and going with separate vendors? In both instances technologies that have not been created as a single software product from the outset are connected through integration-glue.