Although digital asset management has arguably been around since at least the 1990s, the virtual explosion of multimedia has catapulted it near the top of the stack for many organizations. Despite its middle age, DAM is often presented like a new answer to the growing reliance on multimedia digital content and delivery.
There is a debate between: a. Those who see DAM as sufficiently different from other content management challenges and their solutions that it needs new strategies and new computer systems designed specifically with DAM in mind. And b. Others who see DAM as just a unique form of enterprise content management (ECM) for which today’s ECM systems, with a little tweaking, can do just fine.
DAM or No DAM, Why Should We Care?
While the DAM-ECM debate may not be keeping you awake at night, if your organization finds itself dealing with today’s multimedia explosion, it may have a major impact on your automation and financial future.
I would suggest the following approach to guide your decision-making.
First, understand what the terms mean:
- Enterprise Content Management (ECM) is an extension of “Content Management” intended to suggest that a single strategy (and repository?) can manage all the content for an “enterprise” (whatever that is). Software industry hype notwithstanding, ECM is a set of functions that make appropriate versions of content findable and available when and where needed.
- Digital Asset Management (DAM) by most definitions is a series of management functions designed to deal effectively with content from pictures to audio to video and other forms of media outside the classical page-component model. Descriptions of DAM often also include functions like collaboration, content ownership and rights, preview and translations, etc., that are probably not specifically management.
To Use It, You Must Find It
Discussions of DAM usually include a description of metadata’s importance to effective use of multimedia assets. You can’t use a digital asset if you can’t find it and easily determine its format, resolution and duration. Multimedia assets usually require external data to make them fully usable -- think the library card catalog that helped you identify and find a book or item and summarized it without repeating its entire contents. Much of today’s metadata strategy is founded on this same approach: the creation of external data items stored in and searched via the relational database software that underlies most modern ECM (and DAM) systems or by search engines.
So metadata is critical to effective DAM and must be part of the conversation. The need for finding and descriptive aids is universal, so the development of metadata must be based on some standard forms capable of use by a wide range of systems lest we end up with “islands of access” across which little integration is practical.
Unlike libraries of old where Dewey and LC cataloging covered most everything, the digital assets world appears to believe that each area of interest should be free to develop its own metadata strategy and implementations, creating a long list of candidate metadata structures we must support to cover any significant part of the content asset world. This must condense somewhat before even the best DAM approach and technology will achieve its full potential.
When is DAM DAM or ECM Plus?
This may seem like an academic question … until you have to buy something.
A good starting point might be to ask: can my current or candidate ECM systems do an acceptable job of managing my digital (multimedia) assets? The general consensus (outside ECM vendors themselves) is that most currently don’t. If true, this is probably more a function of their design focus than limitations of the technology itself. DAM just hasn’t been enough of a household word, so vendors didn’t put it on their product development calendars.
The next step in this chain might be: if our current or candidate ECM systems won’t do DAM well, do we need an entirely separate system designed specifically for DAM functions? That’s where the question becomes important. Buying and supporting a totally different DAM software environment is expensive, complex and labor intensive, but sticking with an ECM approach that doesn’t do the job is perhaps equally dangerous.
The answer will vary depending on the particular situation but in all cases must be based on a clear understanding of how modern data management systems are built. Any data management system worth its salt is designed and built in layers:
The infrastructure layer: The very bottom of the stack. How the system relates to the underlying computer and communication environment in place. Every system must start with this.
The storage layer: once you have data content, how is it stored? This can be file system, databases of various kinds or proprietary technology. Most current systems use a relational database (RDBMS) as their storage layer.
The access layer: once you load and store your data content, how do you find it and get it from the storage layer? This is where things can get complicated depending on how complex the data is and how many different modes are involved in locating it. Any strategy you use to locate your data must include a step to make sure that the appropriate finding information is available to the system, either by extracting or inferring it from the data itself or by its insertion as metadata in a cataloging step.
The application layer: once you find and access some data, what do you want done with it? This layer can include all manner of processes, both in-house and external, to manipulate your content. All of this must be sufficiently integrated to function both accurately and efficiently. Most management systems offer a range of applications, and it is usually here that their ability to fully support DAM is determined. While some organizations can bind applications to their ECM environment, most can’t, making their provision as part of the basic vendor system an important factor in what system will work best.
The interface layer: Because most of the layers above applications operate under the control of a human user, the visual and functional interfaces must be designed to present what the user needs to see in a way he or she can understand and act on at the appropriate time and with the appropriate “next step” functions displayed.
Once we can see how the management stack is designed, we can see where changes must be introduced to make the whole thing work more effectively. For example:
A storage layer based on RDBMS technology has the ability to store any type of content -- multimedia or otherwise -- and to link content objects to one another through table functions. Even for content so large it doesn’t fit within the limits of a database, the file system can be the storage medium and a token describing it and its location can be stored and processed by the database.
RDBMS-based systems are also good at handling versioning, master-copy relationships, transaction history, provenance (original source) and other multimedia related management functions.
If you want to do DAM with a RDBMS-based system, you probably don’t need a system with a fundamentally different storage layer.
Then there’s the access layer. Again, a RDBMS-based system is pretty good at searching its contents and can be extended by exporting those contents to a search engine. In the case of content, including multimedia, for which a metadata element represents each content file in the DBMS, the same process works reasonably well if the metadata is properly planned and captured.
Again, you probably don’t need an entirely new system to manage digital assets.
The application layer is where applications are written to accept your content and do stuff you want, in some cases modifying it and reinserting in into the system. In this case the ECM world, less through lack of capability than mere neglect, has failed to design and include the kind of functionality needed for effective DAM.
If you aren’t prepared to build your application environment yourself, an ECM that doesn’t offer what you need probably won’t meet your DAM needs, and this is where the vendor must do its job if you are to use its system for both ECM and DAM.
Talking DAM to the Vendors
Vendors must be made aware that, acronyms aside, software systems designed to manage digital assets for an enterprise or some subset of it must be capable of providing all the necessary tools and techniques to do it effectively, for all types of content, multimedia or not. Just adding the term “Digital Asset Management” to their marketing literature won’t do it.
It’s here that users, prospects and customers can make a difference.
With a reasonable effort and investment most vendors can do it, and they must come to understand that their products will become less and less salable if they do not. Some have appeared to get the message and are adding DAM-related functions to their ECM products.
The ECM world should be encouraged to continue and to extend their support for DAM functionality … probably best communicated by prospective DAM customers saying, in effect, “no DAM, no buy!”