Digital Media applications (sometimes called DAM or MAM) are designed to interact with digital media – video, images, audio – and face a number of challenges where the application architecture plays a significant role.  These challenges come from the nature of the bits themselves (the large number), the number of supporting technologies, and established workflows of which many have evolved over years of managing content, and the rapidly evolving industry.  While this topic could cover volumes, my goal here is to highlight some of the noticeable requirements I have seen recently.

VLF – Very Large Files

Rich media files, be it high-res print ready images or high-def video, are very large in size and often not well suited for direct interaction with end-users.   Considering the master files can be 100s of GB in size, the architecture of the application should support a number of requirements including:

  • Content delivery by separate application to help optimize movement (streaming servers, CDN, storage services)
  • Ensuring operations across process minimize content movement
    • While still supporting that some processes will need to touch/process content
  • The pre-existence of a large “library” of content – see point about minimizing movement

Content Processing Technologies – legacy & emerging

Rich media content processes depend heavily on many 3rd party technologies for everything from transformation, manipulation, delivery, editing, compressing, producing, etc.  The specific technology decision can influenced by factors including legacy implementations, support for specific file types, sometimes even variations of files types generated by a specific program, other integrated technology limitations, etc.    Realizing the application cannot possibly embed all technologies, the architecture should provide for:

  • Practical integration of 3rdparty technologies at key points within workflows. More and more these points are becoming anywhere within the flow.
  • Support for legacy or proprietary technologies still in use today for content processing
    • It may not be possible to force use of content processing technology
  • Ability to integrate with emerging technologies
    • Both as libraries and SaaS model
  • Recognition that 3rd party technologies may not be platform independent
  • Support of atomic transactions across multiple technologies, HW, systems

Workflows – often established and complex

The issues detailed above have led to many creative and often custom solutions.  Given the resulting content often has high value to an organization’s business (recall that rich media often is themonetized product), these processes become established and relied upon across the organizations within a business (ie. creative, legal, distribution, archiving).  In order to best support customers needs, expectations, and initial roll-outs – the system architecture should provide for the following requirements:

  • Support for modeling long established workflows already in operation. This requires high degree of flexibility as legacy workflows may have originated as custom code providing unlimited ability.
  • Ability to incorporate into workflows new “services” coming into market around rich media features – how to leverage.
  • Often multiple “media renditions” exist with different workflow/tool required for delivery
    • For example – FPO in the print world and low-res vs hi-res video proxies

Search is interactive

Originally search was taking a word/phrase and matching to an index for results.  While this works especially well for text based assets, in the media world you are often looking for the emotional connection of “did I find the right asset for the right purpose.”  Finding this right result requires a more interactive process than simply matching a word to an index – it is about the process of searching, understanding and refining a set of results for which I have permissions.  Architecture requirements to support this may include:

  • Low latency on search operations. Often users will need to leverage search as they are working with assets, for example to review changes. In addition they will be using the search process in a very dynamic manner to identify the right asset.
  • Support for dynamic structured metadata – while structure is important, it will change.
  • Relationships are critical – often the find process involves understanding how an asset was previously used and its relationship to other assets.
  • Ability in real-time to interact with your search via concepts such as narrowing, filtering, clustering, etc.
Advertisements