One the core values of a Digital Asset Management system is, of course, the concept of connecting people to shared data (video/images/graphics/metadata) in a fast and easy way. It is important to think further about the idea of sharing data, and realize that no matter how thorough your DAM might be in ingesting, archiving and delivering material, at some point the content inside of a DAM has to connect with a system outside if itself.

This is important to think about BEFORE you buy or create your very first DAM, MAM or BAM. Your system may be the most robust and scalable system in the world, but it is not (and probably should not) try to accomplish everything related to running your business.

For example, is your MAM going to store all information about the various rights associated with your stored item? Is it going to store all information about delivery requirements or locations? Perhaps publish directly to website(s)? How about invoicing for payment or notifications about changes in rights status?

I imagine that most people could say they expect their DAM or MAM to push core content to one or more places, but it’s probably not cost effective to have your asset manager take over the jobs done by website CMS systems, metadata publishing systems, or accounting software. Thus, you need to figure out how your asset management system will communicate with systems that do other jobs.

There are primarily two concepts to think through.

• One, what language of communication will be your base communication language? Will you require all of your systems to talk to each other in a common programming language, or will you expect information to trade with other systems via XML or API(s)? There are obviously costs associated with these choices, but almost more importantly to determine – which choice leaves you with the most options for making important expansions or functionality changes in 2 years or 5 years or more?
• Two, where does “asset management stop”, and the system with which it is communicating take over responsibility? This is critical to get right from the start of your project, but even more important to keep clear as people start to use your DAM and have ideas on how it can do even more work. The more familiar you are with all users’ day-to-day workflow from the beginning, the better you will be able to draw a good clear line in the sand between systems’ responsibilities.

If a lot of time has passed since you did the job(s) your DAM is to help address, or you have never actually done the work of the folks who will be dependent upon your DAM, then I strongly suggest you make time to have those that do the work today show you their current workflow related to the tasks the DAM will touch. After they show you what they currently do, walk them through the process you envision when the DAM is in place. Listen carefully to what these folks tell you about how other workflows and vendors will be affected by these plans. Details matter! Talk to any vendors that are mentioned and find a Project Manager or software engineer with those companies to continue to touch base with as your DAM project evolves.

Do you have questions or observations you would like to share about your (current or potential) DAM development? Use the comments section below or email your question to ckingDAM(at)hotmail.com and I will address those questions here in coming blog articles.