Content Technologies: DAM, CMS and Collections Management Systems – What’s the big dif?

Every time I exchange some educational dialog with someone, it necessitates in me the need to blog. It’s clear there is a TON of confusion out there regarding different tools involved in management of digital/physical collections (i.e. content technologies). Dear museums and archives at the end of the day you’re not that much different than that advertising agency. Yes, some of your collection needs are more complicated (longer asset lifecycles etc). At the end of the day though, you all need to use many of the same technologies, tools and best practices appropriately to get the job done and taking shortcuts (using the wrong solution for the need) and not clearly understanding those technologies is costly.

I think about 90% of those working with cultural institution collections don’t really understand the difference between a digital asset management system (DAM) and a collections management system or even what a content management system is (CMS). Take a look at this chart to understand just how much I am going to simplify the very complex topic of content technologies for your reading enjoyment. I also believe there are people out there that can explain it a lot better than me, but no one really has (yet) in any succinct, oversimplified and layman way. So here I go jumping off into what is really a super, messy, overlapping sea of applications that make up only part of content technologies. I’m going to focus on the difference between a digital asset management system (DAM) and a collections management system, I’ve thrown in content management (CMS), specifically web CMS for good measure. Anytime you try to wrap something up in a tiny package, you are bound to overgeneralize. However, I think the risk of over generalization is worth the price in the hopes that out there to get an inkling of an idea about what makes these systems different. You may also realize after reading this, that what you thought you needed might not be really what you need. You may also realize there are some serious gray areas and some systems overlap in scope and try to be all things to all people. Also, remember content technologies are applications that help you mange information, however if you do not also put the business practices and workflows around those applications to make them successful all you will be managing (or not) is your bottom line. At the end of the day content management is not just installing an application, its something that changes the business practices and workflows of the entire organization for the better (albeit a very painful change to some). Now to the “what’s the big diff?” part of this.

I will first try to explain the difference by using a stimulating example…

Idealized, fantasy-land, super simplified museum example:
For each object you have the object itself and any number of digital representations attached to that object. The Collections Management System (TMS, CollectiveACCESS, eMU) manages information about the “object” and associated metadata (CCO, CDWA, VRA). All of the images that depict this awesome object are stored in the DAM system which gets its own little set of metadata (Dublin Core, XMP/IPTC). This metadata however relates to the digital representation of the object and should be much more minimal than what you are storing in the collections management system. Some of this metadata is shared between both the collections management system and the DAM, but not all of it is in both. Each system has their own specific types of metadata. This sharing can even include the collections management system linking to the images in the DAM and not just data and vice versa (data to the images). Then you have the museum website, which stores all the website content in the content management system (CMS). Drupal is an example of a web CMS*. The CMS system is the back-end to the website it keeps all our information nice and tidy and enable a non-tech savvy person to create and edit content, manage users etc. It also manages the navigation, webpages, content (among lots of other things). For example to display the museum collections online Drupal “talks” to both the DAM (where it gets the object images) and the collections management system (for object data) and displays them online in a very pleasing manner (again, ideally). Through APIs all these disparate systems talk to one another delivering content where needed/requested.

*The CMS system type referenced above is a web focused CMSs – there are other kinds such as enterprise cms systems which focus on documents, details, and records related to the organizational processes of an enterprise. Get it?

Now for the breakdown…

DAM:
Digital asset management is all about the digital. The focus here is on access and retrieval. These systems fit well into busy production environments. The DAM system in a museum for example, would contain both object images as well as administrative images (museum interiors, gallery shots) as well as merchandising assets (product imagery, catalog layouts .indd files). Just in the type of content stored, you see how the DAM differs from a collections management system. The DAM is a hub for all the creatives (designers, photographers) to get to their assets, move them around and work with them. Its a dissemination platform, it gets that file from point A to point B quickly. It’s also the system that is the source for images delivered to the web. The DAM creates a centralized area for users to access assets. The assets that go into the DAM should be assets where the amount of resources required in managing them is equal to the need/demand for them. When low on resources, the assets that make their way into your DAM, should be your Rock Stars. These assets should be ones that are output agonostic (print, web) and the most flexible medium. Sometimes workflow systems are built upon DAM systems, enabling enterprises/institutions to fulfill requests for images in scenarios where the requestee does not have access. This can also include workflow systems that come from the content creators (photography studios and graphic designers) enabling them to get assets into the system efficiently and in a consistent way.

CMS
CMS covers a lot of territory so we going to speak in terms of a web CMS. A web CMS, enables the management of different types of web content. It basically helps users with no technical knowledge to easily create and edit content that is delivered onto the web. Examples of popular web CMS systems include: Drupal, Joomla and WordPress. Wikipedia explains it pretty succinctly here, so I’m not going to waste too much space on it. Now, Enterprise CMS is a bit different. Again, Wikipedia does a good job at explaining that as well here.
There is a world of CMS systems to navigate through, its pretty impossible to be an expert in them all.

Collections Management Systems:
As stated above, the Collections Management System (TMS, CollectiveACCESS, eMU) manages information about the “object” and associated metadata (CCO, CDWA, VRA). Interestingly enough, even Wikipedia doesn’t want to touch this application type by providing us with a nice definition. Objects/artifacts can be anything tangible 3D, 2D or born digital objects(!). Notice the different use of the words “object” and “assets”. When we talk collections management we are talking about “objects”. When we talk about DAM we are talking about “assets”. You would store information about objects in a collections management system when you need to record information about the original object itself such as: provenance, bibliographic references, constituents and conservation information. Basically, lots of complex and extensive data about an object goes into a collections management system and a DAM is where you place information specific to a digital asset. Hopefully, you are starting to understand that a collections management system is really good at storing text based information about “objects”. Now, sometimes you can *use* a DAM as a collections management system. However, I will warn you that this really just muddles the waters between information about the digital asset and object information. This is explained in more detail in the next section.

DAMs and Collections Management Systems:
Why even separate the two, you might ask? Well, in the case where you have extensive amounts object information (i.e museums/archives). You do not want to store this same information with every single instance of the digital asset and vice-versa. Mainly because that digital asset itself has all kinds of its own metadata (technical and administrative) associated with it such as: how the digital image was captured, who did the capturing, usage parameters, rights etc. Digital assets also have life-cycles and a DAM makes this process more efficient. You can setup triggers to retire certain images when usage rights run out or when an asset has ceased from popular use. Information about the digital asset is specific to the asset. So in short, you want one container to manage everything about the object. While you use the other (DAM) to keep track of all the digital representations and their complicated life-cycles.

What about “Born-Digital” for cultural instituions?
Yes, things can get even more complicated. In other industries most of your content is “born-digital” (advertising design, web design etc) as these materials began as digital files. For cultural institutions however, born digital is where it gets interesting/complicated (warning: gray area). The “object” information approach can apply to born digital items when you need to store more information about the item that would be outside the scope of a DAM or when it would require the replication of too much data associated with each individual object. In other words you could treat the born-digital like an “object”. I would use the DAM to manage the original digital file without trying to duplicate to much “object” specific information, as that’s the duty of the collections management system. Just enough to make it findable in the DAM. All this while trying to keep the types of information/metadata stored specific to the application solution. Metadata about the born-digital object itself in the collections management system and asset specific metadata in the DAM (where it belongs). Sometimes if your a purely digital archive/collection, you might be able to skip the collections management solution, provided your not going to wind up with 400 metadata fields attached to one asset with lots of duplication of the same information across namespaces.

In reality, there are a ton of gray areas and endless ways to marry these systems together and some systems even overlap. This is hard, complex stuff and people spend a lot of time trying to figure it all out. Consultants get paid lots of money to provide solutions to all complexities involved with collections/content management. Its hard to wrap-it up in a tiny nutshell without going off on a tangent about one particular aspect or changing my mind all together in the middle of the thought (post). The important part is understanding what your REAL needs are and which system will allow you meet these needs in the most pragmatic, efficient, cost-effective way possible.

Here’s some more where that came from:

DAM vs. WCM – do you really understand the difference?
DAM Talk: Scott Seebass CEO Xinet Webnative DAM
What’s the DAM Difference?: Content Management’s Best Tool is Digital Asset Management