LearningAPI has moved to a new blog!

The learningapi blog has moved to a new URL. These posts will remain here, but all new content has moved to learningAPI.com: Digital Media, Streaming Video & Educational Technology. You may also subscrdibe to the RSS feed for the new learningAPI.com blog.

Digital Asset Management - Some Advice

In preparation for my conference session today at the DAM (Digital Asset Management) Symposium, I was asked to summarize my thoughts on what's most important for people who are implementing a content management system to know.  

My personal experience in DAM is mostly centered around building systems for managing streaming media content (search, delivery management, metadata extraction, etc) and other kinds of multimedia materials.  Having done several generations of  a video content management system, as well as several multimedia authoring and asset management systems, here are a few points I think are important:

1. Buy vs. Build --
   
1. Realistically, it's not build vs. buy, it's "build" vs. "buy & build".  These implementations take a great deal of analysis of your business problem, copious customization, and require a strong internal team.  You cannot outsource success.
   
2. Integration of a vendor solution can take as long as a custom build.  Be sure your vendor's direction and your implementation will let you take advantage of the vendor's upgrade path, otherwise you may have been better off building.
   
2. Plan for change - Don't expect to get everything right in the specification stage.  When you define your business problem and its solution, find the right balance between up-front analysis/specification and leaving room for the system to evolve as its users begin using it.  Follow a path-based development model in which you break the big problem into a bunch of small ones and tackle each incrementally; because;
   
3. "If a project team can eat more than two pizzas, it's too large."  This week's Baseline Magazine profiles Amazon.com CTO Verner Vogels and his approach to running Amazon's software development operation.  Small problems are easier to grasp, examine, and solve than big ones.  Small solutions are easier to explain, understand, test, and implement.  Small teams need less process, have few communications challenges, and lower overhead than larger ones.  Small teams can get real work done while large ones are still trying to find common understanding about the problem. 
   
4. Retain internal development capacity -- in order to have the system evolve, you need to have internal expertise in modifying it.  
5. Be ruthless about insisting on the use of open, flexible standards and APIs - Using a system based on open interfaces and standards gives you flexibility to create new things you didn't even dream of when you began.  Information "stovepipes" can be OK...as long as there are simple hooks between them.

More info can be found in the slides from my Gilbane Conference Presentation on content management systems for video and multimedia.