Consolidating Existing Archives into a Unified DAM
Following up on the last post "Introduction to my Blog" that took a high level look at DAM as an archive of reusable assets this post will take a more detailed look of what companies can do to consolidate existing digital content repositories and allow users a single view of all available digital content.
I want to share some technology architecture approaches that
have made it easier to achieve such a consolidated view and also
point to some process changes that have proven essential to the
success of a larger interconnected content management infrastructure.
When we speak of Enterprise DAM or when we look at larger digital content management systems of any kind we look not at one application but we look at a system that consists of multiple applications and tools that are hopefully connected in a scalable and flexible manner. This topic was discussed in the last post "Introduction to my Blog".
What is interesting to note is that in many organizations we have not only one DAM application but many DAM tools from multiple vendors as well as content that could fall into the DAM category but that lives in other systems such CMS, or local storage systems spread around the country or globe. These various applications and tools are used to drive specific workflows and services that were not designed as one big enterprise environment but that grew organically or were inherited in M&A activity. (See Figure 1 for an example of a marketing DAM environment - click on the image to enlarge)
The resulting business challenge is that this content is hard to find and even harder to manage well Therefore organizations have started to look at options to consolidate the various digital media content applications into one system. In the marketing example used above the ideal envisioned environment is one DAM system (Figure 2) that drives various creative and distribution workflows and tools.
However, while this vision looks clean on paper it has been proven almost impossible to achieve. This is due to the fact that the various DAM systems as depicted in Figure 1 have become integral to many workflows in creation and distribution. Eliminating or changing these tools is complex since mapping the organically grown workflows into the new tool is not easy. No application is good at everything. In many cases people have for a few years come up with creative solutions for integration and automation of the existing tools that may simply not work with the new proposed system. Therefore the corporate mandate to consolidate, which may require significant time from departmental staff to redesign processes and workflows, may clash violently with the daily departmental routine of creating high end content on tight deadlines with limited staff. There is simply no incentive for the departments or line of business owner to support the high flying dreams of the corporate guys (often represented by the IT team). Thus we have the typical IT versus business chasm that has killed many a good idea in large scale content management.
What has changed that dynamic somewhat is the advances in "Enterprise Search" technology. What companies like Fast, Convera, Google and the like provide today is much more than "search the web" technology. These tools can index existing metadata tables and consolidate these records into highly flexible searchable structures. That allows users to search and browse across multiple repositories without the need to change the legacy applications. Files can be identified and viewed independent of their location. Business rules and security can be applied so that not all assets are accessible by all people. The search interfaces are much smarter than most straight DAM application's search. Advanced search engines can understand context searches, relevance rankings, they can correct spelling errors or even translate search terms. However, there is a limit to this approach as well. Many core DAM functions are not part of search engines (i.e. complex transformations and ingestion processes may have to be performed locally) and moving large high res files across networks is still an issue if a user needs access to that content in real time.
Therefore a hybrid model will be the best solution in many cases. Some assets are duplicated or moved into a central DAM system while most assets can stay right were they are today.
Because search engines can be implemented quickly (building on the taxonomies and metadata that exists already) the business owners and departments see a quick improvement to their work without much interruption. This good will is key in winning them over when the topic of retiring legacy systems is put on the table. And naturally that topic will surface because in a hybrid system we would expect a very modern and flexible "core DAM" application to start taking over at least some of the legacy work over time.
Table 1 summarizes the pros and cons of the approaches outlined in the post. In Figure 3 we see the result for the marketing example used in the earlier Figures.
What should be mentioned is that these architectural models for system design do not address all aspects of the system planning and change management that has to accompany the technology implementation. I captured these aspects in a white paper that I wrote with some of my colleagues at Infosys a while ago. The paper is tilted "Digital Asset Management Strategy"





Comments