Digital Asset Management Systems vs Drupal. What's the DAM difference?

Remy Denton // December 2012

More than once we’ve had clients who, in trying to work out just what they want their web project to do, have asked us to give them an idea of what’s even possible with Drupal.  As one of them put it, “I want an idea of where the ceiling is.”  The answer, of course, is that that’s a bad way to think about it, mostly because the ceiling is pretty darn high.  If you can find an example of what you want—in most cases, if you can even conceive of it—chances are good that we can build it with Drupal

Then again, it’s easy to take this kind of approach a bit too far.  Recently, we’ve been working with several library clients to set up what are known as Digital Asset Management systems (DAMs) built on Fedora.  For those keeping track, that’s in distinct contrast to Drupal, which is a Content Management System(CMS).  If you’re not familiar with the difference—and perhaps felt your eyes start to glaze over with the mention of “management systems” and three-letter acronyms—you’re not alone.  In fact, my own first response to Fedora was this: what’s the point?  Or, more specifically, why can’t we just build this in Drupal and avoid an entirely separate system for managing the assets?

Can a DAM be a website?

At its core, a CMS like Drupal, Joomla, or Wordpress is fundamentally concerned with managing stuff (“content”) that’s going to be shown on the web.  In fact, a CMS doesn’t just manage the content— like text, images, or videos—for your website.  It is your website.  Try to take away the Drupal part of a Drupal site and you’ll be left with nothing: no styling, no layout, no URLs, and, of course, no content.

A DAM like Fedora, on the other hand, is used for managing stuff (“digital assets”) that could have no relation to the website at all.  It could, for example, contain high resolution images from an advertising photo shoot.  Alongside these, it could have cropped versions of the images to be used for printed brochures, and it could also hold Adobe Illustrator files with designs for these brochures.  At its most basic, you could think of it as a very well organized file server—something along the lines of Google Drive, if you will.

Of course, alongside the full resolution images, a DAM might also hold lower resolution images created specifically for use on the web.  But here’s the catch: a DAM does not create a website!  While it is possible to view a DAM’s digital assets in a web browser (again, think Google Drive), the interface is a far cry from something you’d ever want a normal web user to see (think Windows ‘95).  Instead, you have to build a separate website to act as the “front end” or, in DAM lingo, the “discovery layer.”  You could use plain HTML for this if you prefer, or, alternatively, a CMS.  Like Drupal.

The thing is, while a DAM really can’t be a website, it seems like a CMS can actually do a pretty respectable job of managing digital assets.  Drupal, for instance, allows administrators to upload a large image, which it can then use to create smaller images for use throughout the site (using Imagecache).  It can also categorize content (using Taxonomy) and relate different pieces of content to one another (using a contributed module like References).  Sure, you’d probably need to do some tweaking if you wanted it to hold print assets or Adobe Illustrator files.  But if your main goal is displaying stuff on the web—if, for instance, you’re a library that’s digitizing physical historical records like yearbooks or genealogical records so that patrons will be able to view them in their browsers—why bother with the DAM at all?

What a DAM offers that a CMS doesn’t

Truth be told, I’ve set up a straw man here.  Anyone who’s spent much time with Drupal knows that media management may well be one of its weakest areas.  It’s long been a sore point that even Wordpress, the do-it-yourself platform for bloggers, has a far better media library than Drupal’s own notoriously buggy and slow-to-progress Media module. 

But more importantly, here’s the logical flaw in my argument: a library’s digital assets are not created solely for the purpose of displaying them on the current website.  Sure, that’s probably the primary place they’ll be seen.  But what if a historian needs to inspect something closer than the resolution of the web image will allow?  Or, what if 10 years on—an unthinkable amount of time for the web, but a veritable blink of an eye in the historical, archival world—it’s clear the website needs to be rebuilt?  If all the assets are within the website itself, it can be migrated, though that’s not without its pitfalls.  If the assets are instead stored in a DAM, it’s simply a matter of building a new discovery layer; the assets themselves don’t change at all.

A quick look at the Fedora documentation shows that this is possibly its biggest selling point.   It describes itself as a “stable, persistent digital archive” used for “ensuring long-term durability of information.”  It stores data in what it calls “a neutral manner using open standards, ” something that’s obviously helpful if you need to support websites built on all kinds of technologies, some of which have yet to be invented. 

Perhaps most telling of all, Fedora describes the people who use it as “stewards” of digital data.  That’s not a word I’ve ever heard used to describe someone in the web world; most web projects, afterall, are lucky to make it past their fifth birthday.   But a librarian?  Or better yet, an archivist?  They’re stewards almost by definition, and their use cases are precisely the ones that a DAM like Fedora is for. Alas, there are times when Drupal can’t—or at least shouldn’t—do it all.

Filed under: