A Simple Technique For Cloud DAM Customisation Without The Need For Unique Instances

This feature article has been contributed by Ralph Windsor, Editor of DAM News and Project Director of DAM Consultants, Daydream.


Recently I have been working with clients who have started using Cloud/SaaS DAMs (or plan to).  All of them are migrations away from older product platforms, some that were more conventionally hosted as single instance solutions and others that were on-premise.  The cloud vendors who are replacing their legacy counterparts are a mix of mid-range and higher-end DAM systems (as measured by price points).

One issue which comes up a lot is a need to customise product because it lacks some key element of functionality or has a user interface issue which will pose a problem (for one reason or another).  To an extent, it may be the case that DAM users who are motivated to call in consultants like myself to assist them have obscure or unusual requirements, but in my experience, this happens with all DAM initiatives.  I have about 25 years experience of implementing DAM solutions and I can’t recall ever having a client who did not need something that no one else had asked for previously.  Digital Asset Management is an abstract activity which is highly conceptual in-nature.  There isn’t very much tangible that users get at the end, in contrast to something like Web Content Management where the output is something visible (web pages etc.).  ‘Organised assets’ is self-evidently a highly subjective description.  As such, even if the vendors were exceptionally skilled when it comes to application architectural design there will always be something missing.

The way this problem often used to get solved in the old days was for either a custom edition to be created or (if feasible) some complex configuration to force the DAM app to deliver the required behaviour.  As David Diamond talked about in his DAM News interview last year, with on-premise DAMs this wasn’t so difficult to deal with as the customer could decline the upgrade or defer it until any issues or conflicts with their partially customised edition were resolved.  With Cloud/SaaS DAM this isn’t an option.  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.  End-users are often forced to just wait and hope the vendor’s roadmap catches up with what they need their DAM to do.

As regular readers will know, at one time, I used to be in the DAM systems business (and even further back I used to develop them too).  About 11-12 years ago, when my employer was still offering product we were running into this problem even back then, it is not a new one.  Ideally, we wanted to have just one platform that could be used by everyone rather than maintaining many different editions (while still having the flexibility to apply customisation which was ring-fenced from the rest of the core DAM).  In this way, we could upgrade everyone but the custom functionality would be unaffected – which is an identical problem to what vendors and their users have now.  As is so often the case in DAM, the actors and scenery may change, but the underlying plot remains the same.

We devised a very simple technique which enabled us to do that and this will work equally well with Cloud DAMs also.  I have seen something like it on a very small number of DAM systems, but too many that don’t, or if they do, the vendors have made it unnecessarily over-complicated.  I shall describe how this works in the remainder of this article.  I will endeavour to keep the descriptions as simple as possible but this is somewhat low level and technical in-nature.

Firstly, this depends on having a DAM with an API (and ideally a comprehensive and fully featured one).  An API-First DAM is perfect for this and there are numerous reasons why these platforms are preferable to those that are not, but even a conventional DAM with an API that has been retro-fitted this can still work, albeit with less flexibility in terms of what can be achieved.

Fairly early on into the development of our web-based DAM, we worked out that we needed to keep the branding element of each instance separate from the core of the application so it was easier to add in custom graphics, change stylesheets etc. to cope with the demands of the corporate marketers and brand managers we were increasingly encountering.  We kept a folder called ‘brand’ where all this stuff could get stored.  When a general upgrade was deployed, the ‘brand’ folder got left alone and was not touched so the branding of each edition did not get overwritten.  Our solution to allowing customisation for each client was to add an empty file which got ‘included’ in every page of the DAM application.  This was stored in the ‘brand’ folder.  If a client needed custom functionality, it was implemented client-side using a combination of the API and JavaScript/JQuery, which allows the layout and presentation of web pages to be manipulated after they have been loaded.  I gather there are a few alternative options available these days and JQuery is not quite as ubiquitous as it once was, however, the basic principles are the same irrespective of what library gets used.

Below is a conceptual diagram of how all this worked:

With the above model, we could neatly separate the custom part for an individual client from the rest of the application and update the latter without affecting the former.

This technique proved to be incredibly useful and allowed not only ourselves to cope with a lot of different client requirements without customising the core DAM, but also gave our more tech-savvy clients access to a lot more flexibility also.  For example, we had a design agency who had in-house client-side developers, they built a corporate style guide for on top of the DAM and it carried on working with no issues, even though we upgraded them to a new edition numerous times.  They didn’t need to wait for us to add corporate style guide functionality to the DAM.  More or less every custom requirement where it would have been impractical (or impossible) to modify the core platform we were able to work around using this technique.  This included everything from user interface changes to complex integration tasks where data had to be fetched from third party systems and dynamically inserted into the DAM user interface.

As is to be expected, there were still issues to contend with.  One client was a museum who were using our DAM as a Collections Management System with a lot of third party integration and there were some upgrades that caused these to break, but compared to the pain of an entirely custom solution, these were manageable.  The other issue was security and accessing the API, but we were able to successfully solve this without exposing clients to unnecessary risks.  Our API used a temporary session token which would work for a set period of time before the user had to get a new one.  We bound the session token into each page (server-side) and added a client-side JavaScript function call which could be used to retrieve it.  This avoided the need to store passwords and persistent tokens in the client-side page code (which would have compromised security).

This was functionality developed over a decade ago (circa 2008-09) in an era of files and FTP clients.  There is no reason why with a modern SaaS/Cloud DAM these ‘include’ files could not simply be fields in a database (with a unique one for each client instance).  Administrator-level users (or any other specified user type) could then modify these areas by simply copying and pasting their code into text area fields and saving them.

I don’t have an exact recollection of the development time required to build this feature, but it was of the order of about a day, including testing.  For those DAM vendors who make extensive use of implementation partners, this method offers considerable potential to allow their products to be modified, but in a fairly low-impact and straightforward manner.  Even for those that do not, rather than having to tell clients “no we can’t do that, we’re a Cloud platform’, this offers a fairly simple workaround and potentially permits the client to organise these customisations themselves, which is simply not feasible currently with many Cloud DAMs.

I have seen some far more advanced and complex methods of achieving the same outcome as I describe above and to be fair they offer a range of other capabilities that this very basic technique does not, however, as a baseline that could be implemented by virtually every actively maintained web-based DAM system currently available, I believe it offers some compelling benefits.

If any vendors would like to talk further about this, either leave a comment below or get in touch with me.

Share this Article:


  • For vendors, the issue isn’t so much the ability to partition customizations (since as you point out, in many cases it’s trivially accomplished on the client side), it’s the ability to *support* so many customizations, especially through continuous upgrade cycles. Every product UI upgrade would have to be tested against every single client’s custom code to avoid breakage. In a multi-tenant SaaS application with many customers, this presents serious overhead, and customers are unlikely to pay for ongoing support of those customizations across upgrades.

    There are technical solutions to this as well, but those have non-trivial engineering costs and reduce the ability to innovate.

  • Hi Ralph, thanks for sharing this!
    This is indeed a very simple and powerful customization technique.
    I see two obstacles:
    1) Vendors` fear that if embedded custom code slows down or breaks the UI, complaints will reach them (it might not always be obvious that it’s the customer’s fault), put a burden on their support channels and reflect badly upon their product.
    2) The difficulty of providing a frontend API: Modern UIs are very complex. Customers would need documentation, and they would expect that the frontend structures (CSS, JavaScript) their customization depends upon remain compatible. They’d need a “frontend API” that the vendor supports. Which is additional work for the vendor, and might be hard for them to maintain if the UI is built on top of a framework like Angular where each release might change everything.

  • Josh,

    You raise some valid points in your comment, but I’ll make a few observations:

    Although this is theoretically a trivial for vendors to provide, they often do not, even as ‘hidden’ features they don’t tell end users about.

    I’ve been working with several clients who have customisations that they desperately need or the DAM will not be fully usable for them. In two cases, the vendor either showed beta functionality during the selection phase, or in other, they essentially lied about having it and are now unable/unwilling to deliver it (I was not involved with the client at the point this occurred) . The client is being forced to either wait and hope the functionality is introduced or initiate legal proceedings to withdraw from the contract and have to find another supplier. This is distressing for everyone. While an option to introduce client-side customisation has drawbacks (all the reasons you mention) compared with the alternatives, it is definitely the preferable one. To your point, both the clients in-question would definitely pay to get out of this situation.

    These sort of facilities are best suited to vendors who have partner networks who do implementations (and personally I think all vendors should use this strategy). If there are no VARs/partners, at least the vendor should separate their core product and PS/implementation teams. I think it’s a given that if these kind of features get used, they aren’t included in the standard support and whoever has utilised them will assume responsibility for support. I mentioned in the article that there are situations where breakage will happen, but they’re actually not that common and as long as everyone goes into this with open eyes, the benefits outweigh the disadvantages,

    As an analogy, if you buy a piece of consumer electronics, there is a warning that you aren’t supposed to open the thing up or you invalidate the warranty. That’s not to say you can’t do that, just that you assume responsibility for anything that might go wrong if you do.

  • Hi Tim,

    I think I’ve covered a lot of what you mention in my response to Josh. This is really a fall-back option for when the built-in configuration capabilities are insufficient. As I said to Josh, I’d see this working best with vendor partners. In this case, the support would go through the partner first who would then escalate to the vendor if the customisations were not an issue.

    I take your point about this potentially having issues with framework updates, but I think it comes down to the fact this kind of facility is deemed forbidden, even with a warning that you run the risk of it breaking after an update.

    As a side point, one other observation about SaaS/Cloud DAM is how few vendors provide some kind of testing/staging/sandbox edition which resembles the client’s current configuration. In ‘the old days’ this stuff used to be as-standard and the recommendation to clients would be to use the staging edition to try out anything potentially risky so it wouldn’t disturb the live system. I’ve seen a bunch of enterprise DAM vendors who now want clients to pay for this like its another instance. Given the costs of DAM systems and the fact the marginal cost of a test version is virtually nothing to the vendor, this seems grossly unfair and encourages clients to engage less with the DAM in case they break something.

    I think the real problem here is the dichotomy facing the DAM industry, especially towards the higher cost end of the market. On the one hand vendors want their systems to be generic and more or less identical between different clients (apart from some essential custom config like metadata) but on the other hand, too many would like to claim they have enterprise credentials and charge a fee which is commensurate with that. If it’s the latter, it should be the vendor, not the client who has to change and adapt. At the very least, they should be willing to provide some facilities to enable their products to be adaptable (of the type I describe).

    This latter problem is not going away for the industry, it will become more of an issue. Even if vendors embrace the idea of using partners for implementations, it will be that group who start asking for this sort of flexibility so they can meet their own client obligations.

  • Hi Ralph – thanks for the article – really interesting.
    I think it helps to distinguish between multi-tenanted SaaS applications and single-tenanted. The latter is fully composable.
    For a truly API-first application, we talk about “configuration” as opposed to “customisation” The difference being that that there are a number of applications that can be turned on or off without affecting other clients. And other applications can also be integrated. This is only possible with a cloud-native API.
    One of the biggest advantages is the UI – at the end of the day, it is just an application itself that can be configured for industry verticals and specific clients.
    In my experience, solutions that are not fully composable tend to be legacy systems that were lifted and shifted to the cloud – why else would anyone build a monolith?
    Anyhow – I enjoy your content and discussions… I should engage more!

Leave a Reply

Your email address will not be published. Required fields are marked *