I think it's folly to impose a monolithic solution to cover the entire Digital Asset Management needs of an enterprise. An integrated, best of breed approach is more likely to succeed.
DAM Is Already More Widely in Use than You Think
When I make first contact with clients planning new enterprise-wide solutions, many are either replacing a single existing platform or are of the opinion that there are no other existing DAM solutions. I usually recommend carrying out a comprehensive audit of all existing repositories of assets, whether held in a system or not. As well as obvious sources like external hard drives, DVDs, memory sticks, etc., an audit usually yields a range of hitherto unknown software applications which the original stakeholders had not been fully aware of, including departmental DAM systems, desktop applications (both custom built or off-the-shelf) and in some cases, SaaS DAM subscriptions. In organizations with more than 1000 employees, it is common to find multiple DAM systems being actively used well before anyone decides to implement an enterprise-wide one.
This revelation can cause some disappointment for the stakeholders of the planned enterprise DAM since it appears to add to the complexity of the task. The benefit is a more realistic assessment of the full scope of any planned enterprise-wide DAM can be carried out with some real examples and usage scenarios.
I also have clients who have either skipped this discovery stage or chose to ignore the existence of other solutions until post-implementation, when they find end users refuse to abandon their existing tools to migrate to the shiny new ones.
Failure to differentiate between heavy asset and typical DAM users is the main issue when auditing existing asset repositories. The former may be net suppliers of assets (i.e. they upload more than they download when measured by unique assets alone). The light users usually will not have any existing files because their own personal media management needs are limited. There is often an incorrect assumption that everyone across the business will behave like a typical end user and have a relatively small collection of media assets which they have never properly attempted to organize before.
Many will be shocked that there have been DAM systems in existence for around 25 years now, separate from any semi-manual methods (using spreadsheets, etc.). While the interfaces of older DAM systems are leagues behind their more modern counterparts in terms of visual sophistication, some older application's metadata features can be as advanced (and a few specialist ones exceed them). Older niche systems usually benefit from both a far tighter scope and years of refinement and feedback from more engaged users.
While this scenario will not be the case for every organization, it is important to come to terms with the fact that many of your former and existing colleagues have thought about this problem before you did. DAM is not new, only your appreciation of the need for it.
The Challenges of Defining DAM Characteristics
Elizabeth Keathley wrote an article for DAM Foundation last month: "What Is A DAM? The 10 Characteristics Of A Digital Asset Management System." Elizabeth gave 10 key criteria which she considered essential for a DAM system to be considered worthy of the name. I would agree with her list, however, one major caveat is that the interpretation of what they mean in practical terms can have significant implications for the resulting DAM solution.
An example: point two is "workflow":
The ability to construct, monitor, and provide metrics on workflows are inherent to all DAMs; in fact, may people consider this function to be the very point of DAM systems."
An interpretation of workflow in DAM is for approvals purposes (to authorize ingestion or usage) and some defined process that may involve one or more people making decisions which are tracked in the system. Another definition of "workflow" is as it applies to every process in the DAM, whether it involves human beings or otherwise. In some systems these are given more technical descriptions like "triggers" or "events." Lastly -- as Elizabeth alludes -- some refer to the entire DAM itself as "the workflow system."
From just one point in the defining characteristics of DAM systems, a wide range of potential interpretations is possible. Which one is right? They all can be, until you can define and agree with every single user exactly what is meant by each major feature. The more users who disagree with your interpretation, the less people will want to use your DAM and the lower the ROI from it.
The point is to highlight the potential for disputes about how a given feature should operate. This seems particularly problematic with DAM. An image editing tool like Photoshop, for example, has a clear end-product which everyone can understand, i.e. a bitmap image file. Even Web Content Management Systems have an easily understood ultimate goal -- to generate web pages. DAM has little in the way of a tangible output or product. What you get when you use a DAM system is some "organized" assets, but even that is qualitative in nature.
Typical Problems with Monolithic DAM Strategies
Two key points emerge from the previous sections:
- Digital Asset Management has probably already been attempted at least once before (although it might not have been called by that name)
- There are a wide range of interpretations about what DAM means.
These provide the keys to understanding why a single DAM solution to be used across the business stands a limited chance of long-term success. I have read phrases from those organizations that try to impose enterprise DAM solutions like "stamping out" alternatives -- as though they are some kind of rebel insurrection. There are a number of reasons why users reject enterprise DAM solutions in favor of alternatives:
- They did not know one existed.
- The system fails to answer all of their needs.
- They do not like the way the system requires them to work (i.e., it create productivity problems).
- They have an existing system which they do not wish to migrate away from.
The first point is quite common, but is at least conceptually quite easy to resolve with internal communications programs. The others are all related to the themes discussed. Many of the styles of interaction that support the core characteristics of DAM are open to interpretation, first by the vendor, then the purchasing team involved in selecting a given product. This means that by the time the system is actively used, it will have been through at least two major interpretive stages. There are focus groups, requirements documents, etc., which can configure the solution, but it is almost impossible to avoid some elements of compromise which will sow the seeds for end user dissatisfaction.
The situation with enterprise DAM now is very much like ECM solutions that attempted to address user's DAM requirements a decade ago. The problems of each group of users are too diverse for one single solution to be able to answer them all. What invariably happens is either the software becomes bloated and buggy as conflicting needs clash with each other and the developers try to resolve them with numerous options and settings which in turn require skilled engineers to alter, or requests to make amendments are ignored as not being sufficiently important to justify the hassle and cost.
The Advantages of Multiple Targeted DAM Solutions
An alternative to the top-down methods I have described is a best of breed approach to DAM. This uses multiple, more specialized solutions in a tactical fashion to address well-defined requirements. The scope can be reduced and users segmented according to their functional needs. This makes it easier to offer what each want and increases chances of getting agreement to adhere to enterprise-wide interoperability standards.
There are two ways to achieve this:
- The enterprise DAM provides some core services but acts as a host for other applications which can be implemented on a case-by-case basis
- Rather than enterprise software, the organization implements enterprise interoperability standards which all applications are required to comply with.
Either approach offers a more federated approach to DAM rather than a top-down imperialistic method where the rebel DAM implementations need to be deposed and then publicly executed to set an example to anyone else who might dare to do the same. Different groups of stakeholders are given the freedom to establish DAM solutions that target their needs, but on condition that they agree to collaborate and integrate with a wider series of standards.
Future of DAM
I accept that in some situations, using a single centralized DAM solution can be more effective. Some examples might include:
- A enterprise product has already assimilated all the required features of a specialist legacy alternative and the users of it are willing to migrate.
- A legacy or proposed specialist solution cannot be integrated with any other systems so the application is at risk of becoming isolated.
- There are so many alternative DAM solutions that the maintenance costs of integrating them all make the case for rationalization a commercially compelling one.
In the final case, I would still avoid the typical reductionist IT tendency to over-rationalize and generate numerous unplanned productivity problems just because it seems like a neat and tidy thing to do. That might still mean multiple solutions, just less of them.
I believe all organizations of a significant size will eventually need to implement DAM, and most will find one single platform does not fully answer all their needs. The modular best of breed approach has the momentum of historical precedent behind it since end user needs will constantly diversify and refine based on actual use. Rather than Enterprise DAM products, you may find more useful an integrated Enterprise DAM strategy that can adapt and anticipate user needs in a faster and more flexible manner.