In a world where users are demanding constantly improved digital presence, and consistency of message and content across all media and message components, organizations of every kind are scrambling for tools and techniques to meet those demands.
While some organizations are prepared to manage this kind of presence, many — if not most — find themselves playing catch up in the face of a rapidly changing landscape.
In the search for tools, many organizations have turned to Digital Asset Management, or DAM, for help.
Read the marketing hype for DAM and definitions from places like Wikipedia and you might be forgiven for thinking that virtually every kind of content you have qualifies as a digital asset and that a DAM system is all you need to control your digital destiny.
Not quite.
DAM: A Powerful Tool (in the Right Circumstances)
DAM systems play a role in delivering consistent digital experiences, but only as one of many critical pieces.
DAM systems work best with digital assets that are relatively fixed and ready for access by authorized users.
Even where the asset is a database or other account or its contents, DAM looks upon it as a static asset to use in whatever form it happens to be at the moment of access.
In a dynamic web presence, this definition has broadened considerably. Engineering, operations and other parts of the organization are constantly generating changes in the content to be delivered and must be reflected in what your audience sees.
So while a DAM system can catalog the nature, location and ownership of assets to deliver, it generally isn’t sensitive out of the box to changes in the source data on which those assets are built.
The Birth and Parallel Paths of 2 Disciplines
The split between digital assets and corporate data assets has been part of the automation landscape since DAM was first described as a formal discipline by the International Press Telecommunications Council (IPTC) in 1965 aimed at the management of photographic assets.
At the same time, corporate data processing was also undergoing major evolutionary changes with the development of database management systems.
Despite this common start, the two disciplines took different paths, developed different techniques and attracted different vendors, vocabularies and constituencies. Where the two had to interoperate, it was accomplished either manually or with custom application development.
This parallel existence (kind of) worked until the rise of a digital world that demanded interaction across all components of organizations in near real time.
Suddenly digital assets and corporate IT had to interact at a level neither was used to nor prepared for — and neither saw much benefit in being the first to jump in.
While some types of deliverable assets pose few challenges, primarily those in which the content to be delivered contains a direct image of the contents of a particular source file. “Your previous orders” for example, where the customer history file may merely be queried and the results plugged into a web template for browser display.
In other content deliverables, however, especially those where source data is used as the basis for a creative deliverable — user instructions, product specifications and troubleshooting would qualify here — the direct link/query is usually not workable.
Instead, the author/s of the impacted deliverables must be notified that a change to source material has occurred and what that change involves so the deliverable content may be manually revised.
Most DAM systems, without significant customization, don’t view this upstream activity as part of their bailiwick.
And it is that logical disconnect between deliverable assets and the internal processes that impact them that makes maintaining a consistent and accurate web presence difficult.
Learning Opportunities
DAM as Just One Part of the Solution
Viewed this way, the ideal role for DAM is knowing where to deliver digital assets and who is responsible for those assets, while upstream systems handle the task of identifying when changes to content must be processed and included in the deliverable asset.
This isn’t rocket science, but it takes some work on the part of the software user. The extent of that work is determined by the flexibility of the APIs included in the DAM and other systems involved.
The most challenging part of this scenario is usually the upstream systems responsible for maintenance and processing of the source data: engineering, product configuration, troubleshooting, technical descriptions, pricing, history and the like.
In many cases, these systems were not designed or configured to notify outside actors when changes are made and require configuration (or customization) to do so.
Another potentially thorny issue exists in disparities between the level at which source systems and delivery systems view data and products.
An engineering and product life-cycle management (PLM) system, for example, normally sees a product as a collection of individual parts, assemblies and product components while the deliverables for web users are presented at a product level often significantly above the engineering level. Without the necessary configuration on either or both sides of this flow, potentially important changes can be missed because they don’t relate to their resulting deliverable assets.
Where DAM Fits in Consistent Experience Delivery
If your organization already uses a DAM system, the answer of where DAM fits is straightforward: use the DAM system to “know” as much as possible about the digital assets you acquire or create for delivery.
Knowing where, how and under whose direction an asset is to be delivered is an important part of making the total web presence consistent.
Next, if you haven’t already done it, explore how to make your deliverable assets sensitive to any activity in upstream systems that determine their nature and content. If your DAM system offers that capability out of the box, by all means use it. If it doesn’t, and most don’t, look closely at its ability to customize its operation to accomplish that sensitivity.
Finally, develop a close working relationship across those responsible for the systems that contain source data and deliverable assets.
Some will resonate immediately with your need for closer interaction. Others — engineering often falls into this category — do not, sometimes seeing little reason to change their operation to meet your needs, especially if it requires changes to their systems.
Overcoming this reticence may take time, but it is critical to the maintenance of the web presence you seek.
Today’s world is calling on organizations and their individual components to function in integrated, mutually supportive ways.
Whatever the cost and complexity of this evolution, it can’t come too soon. Organizations that can accomplish it will find themselves winners in the new digital world, and DAM, properly understood and used, can play an important part of that success.
Learn how you can join our contributor community.