FOLIO: mediaPRO

Magazine & eMedia Publishing Professional & Social Network

Sachin Ghodke

What best DAM (Digital Asset Management System) would you recommend to be used?

What is the difference between server and client based DAMs?
Which DAMs are the best to use as server based and why?

I am asking these questions because the company I work for is planning on installing one and I would need your expert advice on it.

Tags: asset, client, digital, managment, server, systems, web

Share

Reply to This

Replies to This Discussion

Hi Sachin,

I hope the following answer will shed some light on the DAM issue. Again - disclaimer - I work for a company that has a DAM product in its portfolio, so I might have some bias towards the featureset we have. I will try to be as open as possible with it though.

First I would like to start with a definition of what DAM stands for: Digital Asset Manager.
Many companies on the market, as well as many users consider DAM as a central repository for media assets like pictures, videos, etc.

I prefer taking a much higher-level view on this problem. DAM should not be just another database where your stuff is stored. Here at Nstein we see it as a centralized and only point where your assets are.
Logically, DAM system has to have perfect connectivity with all of your existing systems (editorial, InDesign/Layout, CMS, video-server, picture management software, syndication/aggregation, arhival systems, etc.).

DAM should be that uniting piece that interconnects all of your existing systems, thus being a centralized content router. Let's say you are replacing one CMS with a newer one. Instead of rebuilding new CMS's connectors with your editorial system, your picture desk, your video server etc. you build only one connector to the DAM and that's it - everything else (since all of our assets are in the DAM in a neutral XML format) is already taken care of.

Thus having easy to use, open APIs is absolutely vital for ANY DAM system.

Secondly, the architecture of DAM plays very important role. Newer technologies like XML allow you to keep every asset within the DAM, while maintaining large amount of classification information about the asset - metadata.
Through using XML repository DAM systems like Nstein's one reach not only speed and limitless possibilities of regular XML systems like MarkLogic, but also allow you to treat every piece/type of your content the same - as a business object.

This leads us to a notion of ingestion - DAM system has to be able to ingest assets in any form and from any source - wire feeds, editorial systems, copy/paste, RSS feeds, UGC coming from the CMS system, etc.
Logically all the assets have to be normalized to standard XML form at the point of ingestion.
Ideally either your editors or DAM system itself through, for example Nstein's Text Mining engine in Nstein's case, tags all the incoming assets live, thus generating all the extra metadata that will let you find, classify, reuse and repurpose assets inside the DAM later on.

Next logical feature is syndication. Of course - you might say DAM is an internal system that lets different offices/pubs/divisions share and repurpose content, thus increasing its ROI (making money indirectly). But DAMs can create revenue flows as well - think SYNDICATION.

A good DAM system should be able to transform your assets into the form that your syndication partner wants it in (for example wire services need to transform their news into Bloomberg compatible format, or XBRL for financial info, etc.) before they send it out. Why should humans do this manually if DAM can do it in a completely automated fashion?

The last several vital DAM features should be workflow controls, automatic ingestion (watch folders for example), Digital Rights Management (DRM). I think these are self explanatory but VERY IMPORTANT in any content-driven environment.

Attached image is a schematic diagram of how we see DAM as a central point of any company's digital strategy


Among the biggest players of the DAM market - there are not many. I ran into MediaBeacon several times. Artesia, Northplains and of course Nstein's DAM are in this field. There are couple open-source projects, but I have never seen them being used in serious corporate environments (Drupal story does not work here I guess).
Attachments:

Reply to This

Difference between server and client based DAM? What do you mean by this? Hosted/SaaS DAM vs. in-house hosted?
web based interfaces vs. client-machine-installed ones?

If you are asking about SaaS vs hosted - do you really want to send all of your company's most important assets - content - to some third party to host it in the middle of nowhere. I believe media companies should keep their content as close to themselves as possible. Giving up that control might seem to make sense financially... but yeah- one day you might wake up and all of your content is gone :)

If you are asking about web interface vs. installed software clients for the DAM - today's web technologies allow you to have the same functionality as desktop clients but without Windows Vista ctrl-alt-del every 10 minutes or so and headaches from losing your work. Also I believe web interfaces could be very useful as well - many of today's systems have great interfaces powered by flash, ajax, etc. - that are very easy to use even for non-web-savvy users

I hope this answers some of your questions.

Reply to This

This month's FOLIO: magazine has an article on called "Building The DAM", hopefully it's of some help to you...

http://www.foliomag.com/2008/building-dam

Reply to This

RSS

Sign in

E-mail

Password

Latest Activity

Hi Nanci, Absolutely! Welcome to the group!
6 minutes ago
martyweil and Kylie Gonzales are now friends
2 hours ago
4 hours ago
Marquita Harris updated their profile
11 hours ago

Groups

Help Us Grow

Please Invite your co-workers & friends to join your network. They'll automatically be added to your Friends List. Click Now

Member Search

Search member profiles by keyword, company & more  

Ex: Chicago, "Penton Media"
Advanced Search

Badge

Loading…
Commercial Use Limitations: Use of any content features (blogs, forums, messaging, etc) for direct self-promotion, spamming, etc. will result in account termination. Profiles are for individuals only at this time, not companies. Profile headshots should not include company logos. Publishing/Media companies (non vendors) may create groups for their employees. Vendors see this post for more information.

© 2009   Created by FOLIO MediaPRO Team

Badges  |  Report an Issue  |  Privacy  |  Terms of Service