The simple promise of any Digital Asset Management (DAM) system is that it makes it easier to find and use the assets (digital files) you have in your collection.
In order to fulfill that promise however, you will need more than just a software solution. A well developed DAM system is just that, a “system.” This means that all of the other parts of a good library/information science system need to be covered so that you have the process, procedures and policies of the entire workflow documented. Digital Asset Management software may enable a number of these steps in the workflow, but these image database, cataloging applications, or browsers are typically only a portion of the whole DAM equation.
There are fundamentals, building blocks if you will — that you should understand if you are attempting to launch or refine an existing DAM system. At their core, DAM systems are all about organization, because people can’t use what they can’t find.
One of the first things to understand is, “what the goal is of your particular DAM?” It’s important for those who create and maintain the DAM system know both what it is, as well as what it is not. There should be a primary goal, which should be obvious to both the users as well as those creating the system. If, for exampe, the goal is store all of the digital images in use by the marketing department for the company over the LAN (local area network), then those are the types of digital files that should be in that DAM. If there are requests to add images that are used for other purposes — like legal compliance, engineering, building schematics, etc. — then it’s easy to know that those do not belong. Or if others in the company now want to include video, audio and company logos files; this is likely to create problems if the DAM was only set up to deal with photographs. As a case in point, what happens if the underlying software doesn’t have the means to import or read in the metadata associated with Video files or display them? If the users will not be able to locate or view that type of asset later, then why even consider adding it in the first place?
Likewise, if the system is built with the purpose of providing assets to employees at a given location over a LAN; what happens when you need to provide access to others outside elsewhere in the state, country or world? If this is something that is needed, it should be one of the original goals of the system. Otherwise, trying to provide this type of access later may not be possible without significant effort, or without creating potential security risks — possibly even making the system vulnerable to outside attacks.
The most basic processes common to most DAM software include the ability:
- To create a record in a database for a each asset (or digital file “container”) provided.
- To create a pictorial representation of that asset (typically referred to as a thumbnail).
- To note the location of the file at the time it was recorded in the database (some systems may move the asset to a location of its choosing and then record the path to that location).
- To read all or specific metadata values that are embedded in the asset and copy those values to it’s internal database.
- To allow users the option to enter, replace, or append new metadata values to fields within the database.
- To allow users to perform searches; using general or specific values; and display those assets (often by showing the thumbnail) that match the search criteria.
Most DAM software will provide support for one or more industry standards used by the specific file formats; allowing information to be shared with others using different software applications. For example, those DAM software offerings that focus on digital photos, will generally support information embedded using IPTC or XMP standards; while audio files will provide support for the ID3, or Broadcast Wave (BEXT) standards.
It is best to not assume — without first researching — that your DAM software will take care of any of the following:
- Tell you what types of files should or should not be added to the DAM.
- Read and import every type of format-specific metadata extracted from an asset.
- Tell you what you can or can’t do with the asset (i.e. “Rights Management”)
- Prevent the overwriting of a file by verifying that the filename for each asset is unique.
- Keep track of the file if it is moved or deleted from the original location by external programs.
- Know whether there are duplicate files, or derivatives of an existing file within it’s database.
- Know which image is the best from a given set, or may have been used previously.
- Know whether the data values entered for each asset are current, correct or even valid.
- Be able to create additional versions of an asset via internal processing (some image databases may be able to create a different sized “preview” image, but it’s best not to assume your DAM can create a web playable mpeg video file from a High resolution MOV without testing).
- Properly understand and deal with ICC Color Profiles or color space conversions.
- Write back metadata values edited inside the DAM to the associated or original file so that those values remain with the file when distributed.
- Verify that the original file has not been modified or tampered with (for example, by validating the file using its checksum).
Some DAM software (or services) may have the provision to limit what each user can do. These are generally referred to as “permissions” and it’s up to those managing the system to set these by individual or class of user. For example, will the DAM be open to the public, or does each user need a username and password to access the database? Based on a username, is it possible to limit what types or sizes of files a user can copy from the database? Or can you limit who can modify the data fields associated with any given asset?
If your organization hasn’t started implementing a DAM system, don’t be in a rush. In fact, you could be time and money ahead by slowing down and doing your homework first. According to David Diamond, a marketing manager who has worked for several DAM vendors, “…the average sales cycle for DAM software is six months to two years-and that’s just for the software alone! Doing DAM right takes time, and it’s time you can’t afford to skip.”
So before you even begin thinking about adding database records to a DAM, it is probably best to back up and investigate some other aspects that are often overlooked; Take the time to outline your goals; document your collection management policies; spell out how files should be named (and how to be sure that names are unique); determine which file types to store; and much, much more.
Few individuals or organizations understand the real costs of not having a DAM system in place. Principally this is because few organizations take much time to assess their current situation before implementing a DAM. Here are a few questions to think about to get you started.
- What would it cost (in staff hours) to recreate files that were lost or accidentally deleted?
- Has anyone calculated the staff hours to create presentations that were given previously – but can’t now be located?
- Has anyone tracked down the number of times an asset was purchased (licensed) again because Department X didn’t know that Department Y had already purchased a royalty free license for the same image?
In upcoming articles, I will try to address these different aspect in the process of building a DAM system/initiative. So check back, and in the interim, let me know what issues you are specifically interested in by using the Comments section below, or by sending messages to the DAM Coalition Twitter or Facebook accounts.
Read part 2, DAM Building Blocks: Filenaming