Intro to Digital Asset Management: Just what is a DAM?

Magan Arthur

If you have been around the content management field for some time you might have read attempts from various writers to define and clarify the difference among solutions described by the those innumerable industry acronyms: DM, DAM, WCM, KM, DRM, etc.

Unfortunately significant confusion still exists, particularly about the role of Digital Asset Management (DAM) systems. After all, aren’t «assets» really just files? So couldn’t we use the same Document Management (DM) system that we use to manage all our other files? Well, the marketplace has spoken and its answer is, «no.» It turns out that managing digital assets — while in some ways similar to managing documents — constitutes a specific business problem that requires specialized software.

This article will contrast DAM systems with DM systems. Along the way, you should learn what content management skills and knowledge you could transfer between DM and DAM projects, as well as what is truly unique about managing rich media assets as opposed to text or imaged documents.

Which DAM?

To begin with, one thing that DAM and DM systems have in common are the different variants you find within each category. These variants are mostly creations of marketing minds and more often than not used to build a new independent «category» so the given marketing department can claim it is «The world leader in […].» Then other vendors picked up the terms because they saw a marketing advantage in doing so. As a result, one category like DAM — which ironically is not a large market segment compared to DM — can have many subcategories like Media Asset Management (MAM), Brand Resource Management (BRM), Entertainment Media Asset Management (EMAM), Marketing Content Management (MCM), and so forth, which are all too close to clearly differentiate in my view.

Products that claim a stake in one or some of these acronym-rich sub-segments are by no means identical in functionality and do not adhere to any common standard. In fact, one DAM system can be quite different from the next. This article will look simply at DAM in the abstract as a system that focuses on visually-rich media types

Below I will contrast DM and DAM systems through the lenses of:

● Tools and Processes

● File and Content Types

● Business Use

Tools and Processes

The heart of DAM and DM systems is a very similar set of core content management functionalities (some native, some perhaps from 3rd parties).

The repository
This very core of any system builds a representation of the content utilizing a relational database or file system, or some combination. This includes basic repository services, such as version control, categorization, upload, and download.

The metadata index
This includes descriptors, administrative data as well as versions, and other hierarchical, peer to peer, parent child or lineage relationships.

The search engine
To perform searches against the above-defined index and repository.

The access and rights subsystem
Privileges and permissions that define who can see and do what with which objects.

The workflow or collaboration engine
Scheduling and definition of tasks in serial or parallel progression.

These similarities would seem to encourage using a DM to manage rich media (or a DAM to support documents). However, part of what distinguishes a DAM from a DM system are the peripheral tools and processes built around these back end elements. The table below contrasts the typical tools and processes for DAM and DM (though of course, not every system has each feature):

File and Content Types

The set of tools described above are built to manage specific file types. Therefore another way to distinguish a DAM from a DM system is by looking that the different file types that are typically managed with the system.

Some DAM systems will manage text based documents like MS Word or PDF and some DM systems are also able to store rich media files such as images or even short videos (usually as generic binary files, albeit with categorization). However, it is important to understand that simply storing a file in a repository is not sufficient for handling most business use cases for rich-media asset management.

Business Use

Given the right tools set a DAM or DM system can be used to address specific business cases. This typically involves the automation of processes. DM and DAM solutions are used for the collaboration during the creation, review and approval process and for the distribution of different business content. The table below lists a few common examples:

In summary, you can distinguish DAM and DM products and vendors by the combination of file types; related tools sets; and also the expertise concerning the processes around creation, collaboration and distribution of these files or assets. In many cases it can make sense to have both a DAM and DM system managing elements of your business separately. Many marketing organizations have looked to DAM systems to cut costs by improving efficiencies. The combination of e-commerce and DAM can be a powerful revenue source independent of any other system (Apple iTunes is the most prominent example). However, a more long-term content management strategy will at least consider the integration of both text based and rich media content management systems.

Integrating DAM into your broader CM Framework

Stand alone content management systems have served many purposes with varying degrees of success. At the same time organizations are starting to realize that digital content represents an increasingly important element of their business. For many companies the intellectual property (IP) that represents the core knowledge of an organization is its most valuable asset. That IP is captured in digital files of various types: product manufacturing processes, instructions, training, research, brand equity and more. Creating a comprehensive and all inclusive roadmap for managing this value is becoming a strategic goal for those companies that are able to plan long-term.

Managing the text-based content and rich-media assets efficiently therefore requires more integrated content management systems. Many web content management (WCM) packages are beginning to add some lightweight DAM capabilities to assist marketing departments with image handling, but often, something deeper is required.

The «ECM» moniker is now often used to describe various combinations of digital content management systems. However, you cannot find ECM systems that deliver all in one out of the box. Only in the past two years have DAM, DM and WCM systems been identified as the combined core to any unified content strategy. You will find that for many larger interconnected systems you will need to duplicate the core functionalities (such as repository services) in order to obtain the peripherals (such as video processing) that you need.

When that CM company bought the DAM vendor, for example, they most likely ended up with two totally different approaches and potentially very different technologies, which they now struggle to integrate into their «Unified Technology Platform.».

The good news is that vendors are slowly recognizing the need for more modular products to reach a broader acceptance with larger clients and integrators. It has become fashionable in our industry to speak about «open architecture, » «open standards, ” and also Services Oriented Architecture (SOA).

However, in order to look behind the marketing message you will need to dig also into the separation of the functional services from the core logic. A sample modularity test could be: Can you swap out the text or video indexing tool with a tool of your choice or can only the vendor make such a change?

The degree of separation is especially important for the interface or presentation layer. A good and publicly available example is the «Multimedia Gallery» on DuPont’s public website. Look at the navigation frame on top and you will see the HTML output from a CMS. But in the lower frame you have access to a repository of images retrieved from a separate DAM system via SOAP calls in the template. This integration was engineered in a surprisingly short time frame due to the clean separation of the UI layer from the core logic of the DAM system.

In fairness it has to be mentioned that even this example was build by a vendor’s services team. Like all integrations, it requires skilled developers and more involved project planning, but it is a step in the right direction. If you are like most large enterprises, you will end up with (or already operate) separate DM, DAM, and WCM systems. Starting with such relatively simple integrations can help you establish a strategy for integrated solutions across the enterprise.