You are here: Home » Special Features » Devising Strategies For Consolidating DAM Solutions Using A Service Oriented Model

Devising Strategies For Consolidating DAM Solutions Using A Service Oriented Model

This special feature was written by DAM News Editor, Ralph Windsor

The topic of consolidating DAM solutions seems to come up a lot in Digital Asset Management implementations currently, usually when end users become aware that their use of DAM (both prospective and current) is wider than they initially thought.   This article is intended to help readers assess their DAM requirements and consider them from a service-oriented perspective which I believe offers many of the benefits of consolidation but also minimises the risks.

What Is Meant By DAM Consolidation?

DAM consolidation means taking a range of solutions that provide different facets of Digital Asset Management functionality and replacing them with a single solution (or at least less of them).  As I will describe, while consolidation makes solving the DAM problem in your organisation appear conceptually simpler, the consequences might not always be desirable and it can have the opposite of the intended effect and create even more fragmentation.  These issues can be avoided if you anticipate the pressures that lead to them and devise plans that can adapt to the needs of different groups of stakeholders.

Why Do Organisations Consolidate DAM?
These are a number of reasons why consolidation is contemplated, here are a few common ones:

  • Aggregate assets into one location
  • Replace unsupported or legacy applications
  • Remove duplicated costs
  • Enhance asset re-usability
  • Simplify application support procedures
  • Reduce procurement complexity

Aggregate Assets Into One Location
This is one of the better reasons for merging repositories together. It is typically easier for users to find assets if they can go to one source to locate them. A number of the benefits of this approach relate more to the internal communications effort required to just make users aware of the existence of a solution. For global firms with many employees spread across hundreds of offices, this can be comparable to the effort required for external marketing exercises.

Replace Unsupported Or Legacy Applications
IT systems, especially those that fulfil some niche function often persist far longer than anyone ever thought they might when first commissioned. If the applications in question are not supported by their developers or use very old technologies that are becoming harder to maintain then consolidating what they offer into a replacement DAM can be a reasonable objective.

Remove Duplicated Costs
If there is a lot of overlap between systems in terms of the type of assets they hold and the functionality then consolidation can offer potential for removal of duplicated cost. As I will describe, however, with DAM functionality especially, you need to be confident that what appears to be similar features, really is. This is a more risky as an ROI enhancing strategy than it might first appear.

Enhance Asset Re-Usability
One benefit of having assets in a single system is that there should theoretically be a higher chance of them getting discovered and then re-used, lowering the average cost per asset and increasing ROI. As with the previous example, however, putting everything into one repository, does not (of itself) always enhance re-use.

Simplify Application Support Procedures
This is popular with IT departments, especially those who choose to host their DAM in-house on their own network. Having less systems and vendors to worry about makes their task easier. In addition, training should be less expensive since knowledge and expertise is more likely to circulate across a wider range of personnel if there are fewer systems that require it.

Reduced Procurement Complexity
Purchasing departments generally have a back-log of contracts to review and any opportunity to reduce that and limit the number of different vendors to manage etc is well received. There is an obvious cost-saving in terms of procurement budgets by consolidating contractual agreements. The inverse of this is whether the cost saved on procurement bureaucracy is adequately offset by the other benefits that fewer DAM systems will offer.

Risks Of Consolidating DAMs
All of the above have risks, which I have alluded to briefly in the above analysis. I will now consider each of those risks in more depth.

Losing Assets That Once Could Be Found
This is the potential disadvantage of aggregating everything into one system. Formerly, the users of a given solution had accumulated a lot of knowledge about where to find everything within their smaller repository. With a new combined solution, the items they want are included along with a lot of other stuff they don’t. While true that there are tools like advanced search and permissions to restrict what is shown, these need to be configured as well as users potentially educated about them, so there is a productivity risk from aggregating assets which has to be mitigated as part of any plan to consolidate DAM.

Inadequate Change Management Planning
When working with clients who have legacy applications, I always try to make the case that these should be available (in a limited form) for an extended period and not just switched off the day after the new DAM is rolled out. As discussed in another DAM News article recently, legacy metadata is becoming an increasingly complex topic and data migration rarely a simple undertaking. I can understand the risk that users won’t move to the new DAM if they carry on being allowed into the old one, but these can be minimised with a proper change management process. Eventually, access to it can be disabled, but I can count numerous occasions where data gets destroyed on the basis that it won’t ever be needed, only for someone to subsequently discover that actually it will.

Smooth transitions rarely happen at high speed and the costs/benefits of hastening the change need to be carefully monitored and risks continuously assessed. Change management is one of these terms which people prefer to mention more often in passing than they are prepared to properly contemplate what is required to put it into effect.

Removing Non-Duplicated Value
Although rich media is different to text-based data, there are not always many common characteristics that make it suitable to be grouped together in the same location. For example, a database might contain records with phone numbers, account balances and notes (narrative). Should all these items be stored together? At first glance, you might say they should, however, if the phone numbers are of your customers, the account balances for suppliers and notes are records of employee written warnings then keeping them all together in the same place seems like a bad idea and potentially risky since they are not directly related to each other.

While you might want to have a selective level of interoperability to link data together, that needs to be carefully controlled and most people would understand that keeping these items of data separate makes more sense. The key point is the purpose of the data you are storing, that should determine whether consolidation is appropriate, not some abstract distinction like the type of data.

When assessing whether a cost is genuinely duplicated with DAM, you need to examine usage patterns, i.e. what users do with their assets. I am a strong supporter of the need to collect user auditing data and obtaining regular feedback about systems (through focus groups, narrative feedback etc). Both quantitative and qualitative data is vital. That will give you a better idea about whether a function is duplicated across solutions or if the use case is more unique than first appeared. If it transpires the old or alternative edition was better, steps should be taken to ensure that the replacement is, at least, as good as the one to be scrapped.

Second System Risks
An issue with the apparently logical policy described previously, however, is the increased complexity and level of engineering required. This is apparent from many DAM solutions now as they become over-burdened with features and variations on interfaces to support diverging user needs. I am seeing many organisations who have implemented DAM once already coming to the understanding they will need to do it again to correct issues from earlier attempts. They often want to use this as an opportunity consolidate their requirements so they can avoid further initiatives for a longer period of time – to get it all out of the way, in other words. This is despite the fact that they have only just begun to more comprehensively understand the scale and true extent of their digital asset management needs. In modern DAM implementations, there is an increasing and tangible danger of second system effect to use the term from the classic Fred Brooks’ book, The Mythical Man Month.

Post-Consolidation Fragmentation
When DAM solutions get consolidated together, if the requirements of users have not been considered and the process managed with extreme care, a potential side-effect is fragmentation of DAM provisions within organisations. This is usually precisely what those who pursue this strategy want to avoid. Worse still, it is not centrally planned and happens because of resentment from users who want their old systems back again, or alternatively, to introduce other products and vendors who are prepared to be more sensitive to their needs because they are eager to win and keep the business. Large sections of the DAM vendor market are currently financially supported by these ad-hoc requirements that only exist because a corporate DAM isn’t satisfactory and no plans were made to accommodate functional diversity or to offer an integrated alternative which they could utilise instead.

Alternatives To Consolidation – Dissecting DAM Strategies
As should be clear from the analysis of the risks, while there might be strong motivation towards DAM consolidation, this is (in part) because it suits the agenda of some stakeholders who might not be especially active DAM users themselves. That is not to say it is always a bad idea, but it is more finely balanced between the positive and negative factors than an initial analysis implies.

There is an alternative way to approach this subject and that is to dissect your DAM strategy and analyse it less as a product and more a series of integrated services that might get utilised in different ways, but with some shared characteristics.

Most DAM experts acknowledge that DAM is all about establishing digital supply chains. That should offer the clue that this is more dynamic than buying one product and then trying to force everyone to use it. Out of necessity and the limitations of the process used, many DAM selection exercises end up biased towards monolithic solutions that will cover ‘the majority’ of requirements. There is strong pressure towards buying something, even though many involved suspect what finally gets picked might not be entirely suitable. What managers perceive as ‘the majority’ often turns out to be a far smaller number of users and they are those that might visit the DAM less than ten times a year (so light users). They fail to account for Digital Asset Managers and those who need to work with many assets and who may work with rich media data. This is how organisations end up with many DAM solutions, because there isn’t just one type of rich media management problem that can realistically get solved by one product. The fact that they all store images or video etc is more of a data type-coincidence, just as systems that store text-based data don’t get grouped together solely for that reason either.

It is still possible to offer a DAM interface which the majority can use to satisfy the need for a more straightforward solution to locating common digital assets, but you need to be able to combine that with integrated specialist DAM tools as well. In essence, you need a Digital Asset infrastructure which you can run different kinds of services upon that are tailored to individual needs, rather than picking what you think is the largest group and trying to base DAM strategies on them alone.

End Users As DAM Developers
One theme which often seems to emerge when I am asked to examine DAM requirements is how closely the end users’ behaviour seem to track that of vendors. Many of the trends in DAM software have been towards giving users more control over metadata, presentation, usability and scalability. The interest in interoperability is being driven by the need for organisations to connect their DAM more widely with their other systems and to not have go through numerous rounds of special professional services projects to do it. Most end users don’t fully understand the nature of their DAM requirements, so what many would prefer is that they could design their own, but without the technical complexity of actually implementing it. This is why DAM RFPs tend to contain numerous requirements, all of them graded with ‘must have’ score ratings. Wanting your own fully customisable software system, but without any of the headaches of coding and maintaining it is obviously not a feasible proposition, but the trends towards more sophisticated configuration point towards the balance of control shifting from vendors to users in terms of ongoing application management.

It is instructive to look at how very large non-specialist vendors have approached the Digital Asset Management problem and how this contrasts with DAM operators who might regard this as their core  business.  Recently, I came across this ‘how to’ article for Google Compute Engine (GCE) Digital Media Asset Management And Sharing.  The article references a fictional company ‘Photofeed’ and how they used GCE to develop an DAM solution. This reads like a blueprint inviting developers to build systems like this themselves. Similar examples have been offered by Amazon for their Cloud platform too in the past.

One question that comes up a lot from new DAM users is why Google, Amazon, Microsoft etc have not yet built their own DAM platform. The reason seems straightforward enough to me, they have realised that DAM is like some endless fractal-pattern which will get more complex and detailed the deeper you go into it. It is more cost-effective for them to provide some base-level components and then ‘suggest’ business opportunities for niche vendors to carry out the implementation for them, deal with all the issues of customising for different groups of users and take care of the not inconsiderable support effort involved. Although I would not want to bet a lot of money on this as a wager (since big tech firms notoriously change direction with alarming frequency) I suspect you might not see ‘Google DAM’ as a tab next to GMail, Drive, Calendar etc for quite a while – and maybe never.

Google, Amazon etc have grasped what a number of DAM users and vendors have yet to. DAM is not ‘a thing’, it is a description of a lose set of techniques and models, some of which you can apply to your situation to help you manage your digital assets. When organisations decide to shoe-horn everyone into the same container, it rarely works because the range of requirements keeps expanding and the vessel rapidly loses structural integrity. Organisations are going to be constantly adjusting and modifying their DAM provisions continuously over an indefinite period to cope with ever-changing requirements. There are going to be exponentially more digital assets and each new wave will be different to the last one and DAM users will still have many legacy assets from earlier periods to maintain also. If your DAM provision is not flexible enough, it will cease to become relevant and people will stop using it. To put it more simply: consolidated DAM solutions are likely to start falling apart as soon as they have been built.

Those that wish to consolidate their DAM provision are better advised to plan for it using a pyramid-shaped model. At the lower levels are core systems which provide services that those above can make use of. They are service-oriented, loose coupled and abstract in nature to allow them to be flexibly adapted to different needs. The upper tiers are more specialist and tailored for the needs of different stakeholders. The investment in the core services reduces the costs and allows services to be re-used. Some of the middle-tiers might exist solely for interoperability services and connecting applications together.



By having a multiplicity of DAMs, built on a core infrastructure, organisations can avoid having to take wholesale gambles on solution providers (or adoption strategies for that matter). This enables them to hedge their ROI positions more precisely than just buying lots of systems: core services can be aggregated to reduce cost, the applications that use them can be more diverse and adaptable to user needs. Further, where one repository has handled a given issue more effectively than others, it is more feasible to copy it in others where there might be a benefit. This encourages competition and reduces the inertia risks that often accompany ‘framework’ procurement agreements where one firm is effectively given the keys to a section of the corporate technology budget and left to get on with spending it.

In September, I wrote about DAM departments and whether these were a good idea or not. If you agree with the idea that DAM requirements are more diverse and cross-functional than they are given currently credit for (a fact most professional Digital Asset Managers will be aware of) then a DAM department seems like the ideal place to manage all this burgeoning activity. As well as metadata experts, librarians and others on the cataloguing side, DAM-oriented technologists can be employed to take a more holistic view of the organisation’s digital asset needs and the selection of providers who will run services across it. The need for marketing technologists is generally understood now, it seems like the same will become more widely acknowledged for DAM specifically too next.

To aggregate DAM solutions and gain the perceived advantages of them. it is necessary for managers to adapt their model and worldview of DAM so it is more realistic and responsive. You are not implementing a single system, but a service that will support a range of different DAM requirements which will only expand in scope and sophistication. If you plan for this in advance and architect accordingly, there is an opportunity to significantly enhance user adoption and ROI along with it.

{ 2 comments… read them below or add one }

E Keathley November 11, 2014 at 7:32 pm

This is a really good article.

Ralph Windsor November 11, 2014 at 8:09 pm

Glad you like it Elizabeth!

Leave a Comment