The Characteristics Of DAM Systems
Elizabeth Keathley, author of Digital Asset Management: Content Architectures, Project Management, and Creating Order out of Media Chaos and owner of Atlanta Metadata Authority, has written an article for DAM Foundation, where she discusses The 10 Characteristics of a Digital Asset Management System. She offers the following:
- Unique ID codes
- Workflow
- Version control
- Ability to create metadata fields or categories
- A robust taxonomy
- Advanced search
- Sharing of assets
- Batch actions on groups of assets (like downloading, modifying metadata etc)
- Ability to handle different file types, especially images, audio/video and documents
- Administrative capabilities and multiple user types
The full article is here: http://damfoundation.org/2014/04/what-is-a-dam-the-10-characteristics-of-a-digital-asset-management-system/
Those all appear to be valid items to me and I would not take issue with the inclusion of any of them. In addition to the above, the following are some further suggestions:
- Lightbox/Collection/Shortlist or selection method for building custom lists of assets and the ability to edit and name it (I will accept there is some cross-over with point 7 about sharing given above)
- An API (Applications Programming Interface). A means to allow third party systems to exchange data with the DAM*
- Reporting and features to monitor user behaviour (e.g. downloads, uploads, search queries etc). I maintain an audit trail is an essential core reporting tool for DAM, but not everyone would agree.
- Comprehensive embedded metadata support for at least images – both reading and writing IPTC and XMP (plus any embedded metadata standards for video if applicable to your usage scenario).
* The API suggestion was made on the DAM News LinkedIn Group.
As ever with these exercises, DAM system vendors are keen to talk about a given feature when they have already heavily invested into developing it, but are rather less enthusiastic for those items they do not support as comprehensively as they should. Most DAM vendors who have some experience in the industry instinctively know when there are areas they are weak on and usually get on with the job of addressing any limitations in short order. The larger or less experienced ones try to create some back-story that they hope will obviate the need for a given feature (usually without success). I am not going to get drawn into another row about the value of CXM as the whole subject is a fairly dry one, but Elizabeth’s points about Adobe Experience Manager are instructive in that respect.
One further point to note is that the devil really is in the detail and you need more than a simple yes/no response to validate whether or not a particular functional capability exists in a DAM product or not. For example, on Elizabeth’s list there is “Ability to handle different file types”. In reality, any DAM system that lets you load files ‘supports’ all types of files, a more critical question is whether it can generate a proxy you can view before you download it (and then find that it’s not actually the one you require). There are numerous other similar fine distinctions which need to be carefully checked.
On our DAM Vendor directory, we have a number of questions which cover most of the points on this list (and a few others also) but the limitations of a software-based selection method make it more difficult to drill down to discover to what extent vendor x really does support feature y. One observation we have made is that those who are eager to offer an affirmative response to any given feature but who are then less willing to describe how it actually works are less plausible than those vendors with a lot to say about their application. You can identify the former because they have lots of empty fields in the notes sections and no screen shots for you to validate their interpretation against your own. In a far smaller range of cases, we have also found that some more honest vendors will tell you they do not support a given functional requirement because they are not up to speed with the latest IT fashions or trends and they may have implemented something that is very similar but then used their own terminology to describe it.
These lists are a good starting point, but you cannot use them in a mechanical fashion. Most people grasp this fact, but the pressures to hurry up and choose a product can lead end users to take ill-advised shortcuts. While that is understandable, the typical lifecycle of corporate DAM system is approximately 5-8 years which is a long time to have to live with a hastily made vendor selection decision. There isn’t really any substitute for trying out a given product for at least a week or two before agreeing to make use of it over a longer period – that applies whether it’s a paid for application or a free one you might have obtained without incurring a licence fee (e.g. an open source solution). DAM is about enhancing productivity, if the DAM software isn’t helping you to do that for any reason, it is effectively costing you money rather than saving it.
Share this Article: