Why Do All Cloud DAMs Not Have This Capability?
I have recently contributed a feature article for DAM News entitled A Simple Technique For Cloud DAM Customisation Without Needing For Unique Instances. This is a very quick and easy to implement method which is missing from numerous DAMs I encounter, probably the majority:
“Although the end-user thinks they have their own dedicated DAM, this is an illusion created by the software and the reality is that ‘their DAM’ is shared with all the vendor’s other clients. For this reason, when these all-too-frequent obscure requests come up, many DAM vendors will respond with something like “we can’t do that, this is a SaaS platform we can’t change this just for you” (or words to that effect). To try and work around these problems, modern DAM systems have huge swathes of configuration settings, but even then, they still don’t cover every eventuality, for all the reasons discussed.” [Read More]
The technique described was one myself and my colleagues devised about 12 years ago. The DAMs I was involved with back then were mostly hosted as opposed to multi-tenant Cloud solutions, but the same issue cropped up: how to avoid multiple editions (or ‘forks’) of the core DAM platform just to cope with the unique requirements of a single client. I am no longer involved in the design nor development of DAM systems, but I run into this issue when working with clients who are using a Cloud DAM where vendor is reluctant to customise it (for reasons I fully understand).
If you are not from a hands-on tech background, the summary is that when Cloud vendors tell you their DAM cannot be customised, that isn’t necessarily true and what it actually means is they haven’t implemented their architecture as flexibly as they could have done. As I discuss in the article, this approach offers a lot of benefits for vendors who use partners for implementations as it makes it far easier for them to significantly change the functionality of the DAM to deal with all those square pegs and round wholes which so often characterise enterprise DAM implementation exercises.
From a wider perspective, what I do find a lot when talking with the technical personnel in DAM vendors is that while they often possess a deep level of technical skill and knowledge of modern technologies, there seems to be a level of what can best be described as ‘architectural amnesia’ where problems that got solved years ago seem to keep coming up again and again. I think much of this is probably due to a combination of the fact that many developers are only active between the ages of around 23-40 (after which they usually become project managers, consultants or form their own startups etc.) and also that so much of what happens in tech (in general) is re-invention of the wheel but with completely different technologies. This leads to an effect which is comparable to someone having to translate the same literary work into a seemingly endless number of different languages. So much time gets spent on just getting things to work again in whatever the latest fashionable framework is that making actual progress with solving real problems is stymied and knowledge of some fairly basic techniques is at some risk of getting lost.
This last point in an intriguing one, especially set against the ongoing issue of the relative lack of innovation in DAM. I do have to wonder if the two states of affairs are not related to each other in some way? Irrespective, I welcome a discussion and/or debate about the idea proposed with both vendors and end-users.Share this Article:
One would think that with emerging technology and technological changes happening at a rapid speed, cloud digital asset management systems (DAMS) would be more flexible for their users. Windsor mentions that solutions to issues found when it comes to cloud DAMS have been solved years ago, but developers continue to “reinvent the wheel”. Something that may assist with resolving this issue without reinventing the wheel is for a best practice or governance to be created for all DAM users to follow.