"Frankly, my dear, I don't give a DAM!" Yes, Rhett would, for Digital Asset Management - Enterprise Networking

Computer Technology Review, March, 2002 by Christine Chudnow

Reporters love to go for bad puns around the acronym for Digital Asset Management. Take a moment ... yes, you guessed it. I will try to avoid the puns but make no promises. There are other terms meaning much the same thing as DAM, including RMAM (Rich Media Asset Management), MAM (Media Asset Management), and DMM (Digital Media Management). But DAM is becoming the most common term, no doubt because the press thinks it's funny.

DAM was born of the need to control and leverage critical digital media that was spiraling past manageable levels. According to market researcher IDC, DAM is a process that enables an organization to collect, access, utilize, and reuse rich media assets. These assets may include text but are primarily digital works consisting of images or sound. To further complicate the matter, these files are often interrelated. Although document management (DM) for text-based files is already complicated enough, DAM is an even more challenging prospect, impacting projects such as web publishing, internal production processes, multi-channel marketing, knowledge management, ad-hoc research, and downstream system integration.

Digital material includes any data you could put on a computer system, such as unstructured documents and database files, music, e-books, video, audio, software, presentations, photographs, pictures, and archive material web pages. The word "assets" reminds everyone that these files are intellectual property with a monetary value beyond the content, sometimes a considerable one. For example, Coca-Cola--no slouch when it comes to marketing materials--recently contracted with IBM to corral its runaway digital advertising materials into a central repository, where Coca-Cola employees could download myriad rich media files from decades of print, radio, television, and Web advertising.

DAM and Content Management (CM) are not the same technology, but they are moving towards convergence. KPMG defines them and DCM (Digital Content Management) as:

* DAM applications are automated systems and associated processes to digitize, catalog, search, and retrieve digital assets.

* CM systems facilitate digital media creation such as Web pages, books, and magazines, and manage their components using automated workflows.

* DCM is the universe of all DAM and CM systems, including their secure delivery over the Internet and networks.

According to consultant Teri Ross, DAM applications generally fall into two broad categories: media catalogs and asset repositories. Media catalogs utilize proxies such as thumbnails in indexed databases that users can search by keyword. The actual source files are not in the database, and remain under the control of the operating system. The low cost and simple management of media catalogs make them very useful for departments or small workgroups. However, since media catalogs do not actually manage the content itself, they often lack control features such as check-in/check-out, rights management, and automatic versioning that are necessary for enterprise use. Large and distributed media catalogs can also increase response time.

In asset repositories the content itself is physically stored inside a secure database. This allows for security levels, replication, referential integrity, and centralized data management, as well as hierarchical storage management (HSM) and healthy disaster recovery. Asset repository models are ideal at studios with industrial workflow, global rights and permissions management systems, and the enterprise. Centralizing asset management is a good deal more expensive than using media catalogs, requiring significantly more capitalization and ongoing administration costs.

These types of DAM systems usually operate using business rules and processes to manage digital assets, including acquiring, storing, indexing, searching, and exporting them and their metadata. (Metadata is detailed information about an asset, holding such information as creation data, creator, other versions, related files, and copyrights.) In addition to the database, many DAM systems use coding and middleware technologies such as HTML, XML, Java, and CORBA. Artesia Software, for example, builds its Teams application on Oracle 8i as its digital media repository. Business logic services use CORBA to broker requests between the client and database, and XML to exchange content with its metadata to other applications along the asset chain. Java Beans underlies the application logic layer. IBM is very active in this field as well. It uses digital-friendly Informix database features in DB2, and has blurred the line between DAM and CM by including extensive digital asset management features in its Content Manager suite. Content management company Documentum recently acquired Bulldog's digital asset management technology, and Microsoft and CA are also in on the DAM action.

DAM Storage

Since smaller scale media catalogs hold proxies of the actual files, administrators handle file backup along with regular system backup procedures. But since enterprise DAM databases house the actual files, they require significant storage capacity, fault tolerance, and high availability. (That means a lot of expensive RAID arrays.) To help manage backup and capacity procedures, many DAM systems have policy-driven HSM and backup features, or hook into applications that do. For example, an IT administrator may set a fill point of 60% on a disk. Once the fill point is reached, the policy migrates inactive database objects into cache, less expensive disk, or tape libraries. In a manufacturing design environment such as General Motors, designers would keep their high-resolution images in a fast RAID environment. Less active files that should remain accessible can migrate from the expensive RAID subsystems to an inexpensive server node or near-line storage, and from there to tape. Throughout the migration the DAM application preserves the relationships between rich media files and their original locations, so if needed the system may activate an inactive file and transparently return it to the requestor.